На выставке VMworld компания VMware анонсировала (http://www.vmware.com/company/news/releases/vmw-vfabric-data...) выход на новый рынок - рынок "облачных" СУБД (DaaS - база данных как сервис). Новый продукт - vFabric Data Director представляет собой виртуализированный сервер баз данных, работающий в стеке vSphere 5.0 (http://www.vmware.com/company/news/releases/vmw-vsphere-ga-0...). Формально, ни к одной из популярных СУБД он не привязан, однако пока что он может работать только с vFabric Postgres, который базируется на СУБД PostgreSQL 9. Облачная версия PostgreSQL поддерживается собственными силами компании VMware.
Наблюдатели отмечают (http://www.theregister.co.uk/2011/08/29/vmware_vfabric_data_.../), что подобным шагом VMware выходит на прямую конкуренцию с компанией EnterpriseDB, которая является основным спонсором развития PostgreSQL. EnterpriseDB в данный момент активно занимается разработкой именно облачных продуктов, среди них ...URL: http://www.theregister.co.uk/2011/08/29/vmware_vfabric_data_.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=31631
Хорошая новость, рад за PostgreSQL. Чем больше её будут использовать компании типа VMware и Apple, тем популярнее она будет среди it-сообщества
главное чтобы делились патчами в основную ветку и спонсировали разработки. От дополнительного айти сообщества пользы уже не так много
Ну и конечно же эппл и вмварь будут делиться своими изменениями. Агащаз. И какая нам радость с наличия у вмвари и аппла каких-то супер-версий, которых у нас не будет иди будут только на весьма банальных условиях за круглую сумму и уж разумеется без сырцов? Чему тут радоваться? Букве "р" в слове "колбаса"?
> Ну и конечно же эппл и вмварь будут делиться своими изменениями. Агащаз.
> И какая нам радость с наличия у вмвари и аппла каких-тоВи-таки ни поняли!? "Чем больше [их] будут использовать", тем большье они будут радоваться!
> тут радоваться? Букве "р" в слове "колбаса"?
Букве же BDSM в слове BSDL!?
> Букве же BDSM в слове BSDL!?) По-любому с GPL этот фокус не прошел бы.)
> Ну и конечно же эппл и вмварь будут делиться своими изменениями. Агащаз.Корпорациям выгодно передавать улучшения в upstream, так как на поддержку набора внешних примочек своими силами уходит слишком много ресурсов. Почему все стремятся добиться включения своего кода в ядро Linux ? Потому что иначе повеситься можно адаптируя к каждой новой версии свой набор патчей с повторением каждый раз полного цикла тестирования. Для Linux тоже есть вполне легальный и доступный метод поставки проприетарных дополнение - модули ядра (GPL-обвязка для линковки + проприетарный блоб).
>> Ну и конечно же эппл и вмварь будут делиться своими изменениями. Агащаз.
> Корпорациям выгодно передавать улучшения в upstream...Ты это Juniper (и Cisco?) скажи.:) А то они, бедные, столько лет продают свои железки с начинкой и сами все поддерживают ответвления ядра BSD.) А тем временем от самой BSD кое-кто уже на серверах даже начинает отказываться.
> Корпорациям выгодно передавать улучшения в upstream,Да, наверное именно поэтому линукс и обошел бзди на повороте, хотя те на 10 лет старше.
> так как на поддержку набора внешних примочек своими силами уходит слишком
> много ресурсов.Да, но появляется весомый аргумент за: ведь можно не делиться, так что конкуренты не получат то что разработано в стенах компании. Зачастую жаба перевешивает здравый смысл.Ну вон пачка проприетарных форков бсди и попередохла, например. А кому они нужны то? Вот и драпают вендоры на линукс.
> Почему все стремятся добиться включения своего кода в ядро Linux ? Потому что
> иначе повеситься можно адаптируя к каждой новой версии свой набор патчей с
> повторением каждый раз полного цикла тестирования.Ну спасибо вам Капитан.
> Для Linux тоже есть вполне легальный
> и доступный метод поставки проприетарных дополнение - модули ядра (GPL-обвязка
> для линковки + проприетарный блоб).Да понятно что если сильно хочется - можно и гланды через задний проход автогеном удалить, только это неудобно уж очень.
Бедняги, аж сердце разрывается глядя на вас. Мало того. что вас постоянно жаба давит в вашей gpl'ой песочнице, так вас еще и bsd'шная давит тут.Шли бы вы к себе на lor, а то еще пара новостей про продукты под bsdl и у вас окончательно крыша съедет от тщетных попыток осознать, что кому-то может быть не жалко делиться своим трудом.
Читая такое порой даже закрадывается мысль, что такие, с позволения сказать, комментаторы пытаются пинать bsdl потому, как подспудно осознают, что cвобода gpl это ложь и совсем не свобода. На фоне bsdl слишком сильно заметно, поэтому и брызжут слюнями некоторые тут...
Но слава богу это всё же банальная человеческая зависть и нетерпимость. Не было бы gpl и bsdl, эти господа устроили бы свару по какому-нибудь другому поводу.
offtop off...
Очень интересная ситуация. Думаю VMWare под давлением RedHat'овского решения таки будет вынуждена открыть сырцы. RedHat как никто другой умеет использовать открытую модель разработки, и со своей коммюнити (а это между прочим не только разработчики, но и потребители) быстро займет большую часть рынка, если vmware будет щелкать клювом.
Похоже будет серьезное рубилово за рынок. На фоне конкуренции будет взрывное развитие наработок и функционала PostgreSQL как "облачной" RDBMS. И на этом похоже PostgreSQL окончательно обойдет "пучок" gpl'ных rdbms, оставшихся после развала MySQL.
<< камень в огород gpl'щиков. Даю им возможность поупражняться тут... )) >>
Факт что, для облачных вычислений ее (PostgreSQL) предпочитают другим продуктам, уже о чем то говорит. Да а кто у нас из РСУБД уже на рынке то?
> Факт что, для облачных вычислений ее (PostgreSQL) предпочитают другим продуктам, уже о чем то говорит. Да а кто у нас из РСУБД уже на рынке то?Выбор не удивителен потому что собственно других открытых вариантов как бы и нет. MySQL? У него за спиной стоит и тяжело дышит Оракла. Не думаю, что кто-то в здравом уме и трезвой памяти будет базировать на нем собственные ответвления. А в общем то и все.
Выбор неудивителен, потому что подобным товарищам очень уж удобна BSD-лицензия. И получается, что можно предлагать клиентам свою версию Postgres, которая "поддерживается собственными силами компании VMware", но исходный код доработок не открывать.
Был бы GPL ситуация никак бы не изменилась, т.к. продукт не покидает серверов компании.
> Был бы GPL ситуация никак бы не изменилась, т.к. продукт не покидает
> серверов компании.В случает PostgreSQL под GPL ее бы не развивали (меньше развивали) корпорации для своих нужд. А значит и тех возможностей, что есть сейчас, pg достиг за намного большее время или вообще стопорнулся бы. БЫ.
Но pg развивается и это хорошо.
> В случает PostgreSQL под GPL ее бы не развивали (меньше развивали) корпорации для своих нужд. А значит и тех возможностей, что есть сейчас, pg достиг за намного большее время или вообще стопорнулся бы. БЫ.... Именно об этом нам говорит нынешнее состояние *BSD и Linux!
Бредятина, короче.
> Но pg развивается и это хорошо.
А вот с этим спорить не буду.
А Linux вон отлично развивается под GPL, в отличие от умирающей фри. Скорее наоборот - у постгре нет сравнимого конкурента под GPL (мускуль явно слабее) - а тут уж дешевле и быстрее в одно рыло тянуть свои модификации существующего кода, чем создавать новую базу и совместно с другими её разрабатывать.
Linux это ядро и платформа, деньги зарабатывают создавая нечто поверх этой платформы.
PostgreSQL это готовое приложение. на нем самом денег много не заработаешь.Linux под GPL не мешает писать проприетарные приложения. В отличии от этого СУБД лицензированное под GPL БЕЗ ИСКЛЮЧЕНИЙ (включая драйвер) не позволяет его использовать в проприетарном приложении. Нужно ЛИБО исключение на СУБД или его драйвер ЛИБО СУБД лицензировать под более либеральной лицензией - BSD.
PS GPL СУБД тоже может развиваться, но на текущий момент вряд ли хоть одна сравнится с PG.
> PS GPL СУБД тоже может развиваться, но на текущий момент вряд ли
> хоть одна сравнится с PG.Я тебе больше скажу, ни одна СУБД под BSDL не сравнится с PG. И что??
...
но многие сравнивают PG с проприертарными СУБД. То есть вывод какой? Что пропиертарные лицензии рулят, и BSDL сливает??Чего ещё было ждать, двигаясь месте с BSDL. В сторону проприертарщины.
А давайти сменим лицензию на GPL 3.0 чтоб никто нисмог своровать код. Можно же качнуть и перепесать файл с лицензией, пусть все на GPL будет
> Я тебе больше скажу, ни одна СУБД под BSDL не сравнится с PG. И что??Как - что? Если факты не подтверждают теорию, от них надо избавиться! Так этим наивным лолкам и передайте :)
> Linux под GPL не мешает писать проприетарные приложения.СУБД под GPL не мешает точно это же делать с приложениями под СУБД. Есть различные PL языки, есть закрытые ком. решения на их основе. Есть, в конце концов, просто само приложение для СУБД.
Разница именно в качестве СУБД и берут PG не потому что оно BSD, а потому что всё остальное гогно.
> Linux это ядро и платформа, деньги зарабатывают создавая нечто поверх этой платформы.
> PostgreSQL это готовое приложение. на нем самом денег много не заработаешь.
> Linux под GPL не мешает писать проприетарные приложения. В отличии от этого
> СУБД лицензированное под GPL БЕЗ ИСКЛЮЧЕНИЙ (включая драйвер) не позволяет его
> использовать в проприетарном приложении. Нужно ЛИБО исключение на СУБД или его
> драйвер ЛИБО СУБД лицензировать под более либеральной лицензией - BSD.
> PS GPL СУБД тоже может развиваться, но на текущий момент вряд ли
> хоть одна сравнится с PG.Может, что-то в этом и есть, но у меня есть возражения. По каким-то параметрам MySQL обходит Postgres - это раз. Имхо, то, что де Linux - платформа, а Postgres - законченное приложение, тоже неочевидно. Сколько всего приделывают с MS SQL(тоже БД)? Систему репортинга, какие-то там коннекторы, что-то еще, чего я не знаю. Именно потому, что Postgres 8 еще не была готова, все так радовались Postgres 9. И что Postgres 9 - это конец? Да нет же... Точно также можно и на его основе делать "законченные" спец.решения через какие-нибудь плагины-вставки-линковки.
> А Linux вон отлично развивается под GPL,Linux сейчас — это застой, ожирение и прострация. Никакого развития нет, только деградация и BUG#12309, который всеми силами хотят портировать на FreeBSD.
> в отличие от умирающей фри.
Она всё умирает и умирает, в ней всё появляются новые фичи и драйвера, ядро вычищается от спинлоков и ненужного поллинга, а умереть не может. Чудо же!
> Скорее наоборот - у постгре нет сравнимого конкурента под GPL (мускуль
> явно слабее) - а тут уж дешевле и быстрее в одно
> рыло тянуть свои модификации существующего кода, чем создавать новую базу и
> совместно с другими её разрабатывать.Код под BSDL легче поддерживать, так как он не завязан на ключевого разработчика (какого-нибудь Oracle) с его жёсткой политикой в отношении распространения и принятия нового кода в основную ветку, а также с подавлением альтернативных, несогласующихся с генеральной линией партии, идей. Эволюционные изменения обычны для кода под BSDL, так как эти изменения синергетичны. Для кода под GPL, чтобы пропихнуть важную идею в основную ветку, нужна очередная революция, распад команды и очередной форк.
> Linux сейчас — это застой, ожирение и прострация.Никакого развития нет,Ну если с такими ченжлогами это застой, то я сообщаю что будучи в здравом уме и твердой памяти я согласен жить в таком застое. Кстати, Sandy Bridge вам тут привет передавали. Вместе с Sandy Trolls :)). Кстати, они били себя дубинкой в грудь и ругались что графика - не работает.
> только деградация
Капитан подсказывает: если читать только багтрекеры, а ченжлоги упорно игорировать - тогда любая программа будет выглядеть как один сплошной регресс :)))
> и BUG#12309, который всеми силами хотят портировать на FreeBSD.
Требуй ухода разработчиков в отставку! Ведь если они перестанут писать код - то и новых багов не будет! Правда вот и старые тогда никуда не денутся.
> Она всё умирает и умирает, в ней всё появляются новые фичи и драйвера,
> ядро вычищается от спинлоков и ненужного поллинга, а умереть не может. Чудо же!Sandy-тролли с sandy-дубинками из-под sandy bridge тут повылезли из-под моста и интересовались чем-то таким про видео. Наверное к дождю.
> Код под BSDL легче поддерживать,
А еще волосы на ж... становятся мягкими и шелковистыми!
> так как он не завязан на ключевого разработчика (какого-нибудь Oracle)
Интересно, а как лицензия связана с тем кто и как поддерживает код? Ну вот например нжинкс - он точно совсем уж не завязан на ключевого разработчика Сысоева? :)
> с его жёсткой политикой в отношении распространения и принятия нового кода в
> основную ветку, а также с подавлением альтернативных, несогласующихся
> с генеральной линией партии, идей.Они так жестоко их всех давят, что аж развели у себя целую стопку персональных git-репов у себя на kernel.org, на все случаи жизни. И как-бы git сильно удобнее для независимой работы над своей версией проекта при периодическом перекидывании какими-то кусками с другими, в отличие от некрофильского SVN, где этот сценарий больше напоминает хождение по мукам.
> Эволюционные изменения обычны для кода под BSDL, так как эти изменения синергетичны.
Ты выучил новое слово?! Такая заумная фраза, а смысла все-равно ноль.
> Для кода под GPL, чтобы пропихнуть важную идею в основную ветку, нужна
> очередная революция, распад команды и очередной форк.Проверял?
> Код под BSDL легче поддерживать, так как он не завязан на ключевого
> разработчика (какого-нибудь Oracle) с его жёсткой политикой в отношении распространения
> и принятия нового кода в основную ветку, а также с подавлением
> альтернативных, несогласующихся с генеральной линией партии, идей. Эволюционные изменения
> обычны для кода под BSDL, так как эти изменения синергетичны.Позволь узнать, какой код под BSDL поддердживаешь лично ты? А то что-то у меня совершенно другие сведения о том,какой из них легче/тяжелее сопровождать. Да, я разрабатываю и сопровождаю
> Для кода под GPL, чтобы пропихнуть важную идею в основную ветку, нужна очередная революция, распад команды и очередной форк.
Ога, вон Мэттью Диллон хотел кардинально изменить ядро в FreeBSD, пойти в сторону гибридности. И где теперь его идея? Правильно - в Стрекозе, форке FreeBSD.
> В случает PostgreSQL под GPL ее бы не развивали (меньше развивали) корпорации
> для своих нужд.Как это согласуется с ломовым допиливанием линукса?
"Если факты не подтверждают теорию, от них надо избавиться!" (законы Мерфи)
Хм, там смотреть надо, но если это именно развёртывание и предоставление клиенту окружения с настроенным Postgre - то вопрос интересный. Вполне возможно, что именно надо было бы предоставлять исходники.
*Р*субд для облачных вычислений не подходят ну никак. ACID мешает. потому их припиливают к облакам через различные костыли =)
> *Р*субд для облачных вычислений не подходят ну никак. ACID мешает. потому их
> припиливают к облакам через различные костыли =)Облако - это слишком размытое понятие. Если речь об PaaS - соглашусь, если IaaS, где инстансы явным образом создаются и конфигурируются - всё там подходит.
>> *Р*субд для облачных вычислений не подходят ну никак. ACID мешает. потому их
>> припиливают к облакам через различные костыли =)
> Облако - это слишком размытое понятие. Если речь об PaaS - соглашусь,
> если IaaS, где инстансы явным образом создаются и конфигурируются - всё
> там подходит.Amazon это IaaS, при этом для нормального масштабирования приложения нужно пользоваться их движком БД. Хотя конечно можно повтакать в каждую ноду по СУБД, но в таком режиме облако работает в качестве фермы виртуалок. Не более того.
Так основной смысл IaaS - хорошо (в т.ч. - с автоматизацией) управляемая ферма виртуалок. Для кучи задач это очень даже подходит. И, кстати, есть масса случаев, когда необъодимость в масштабировании базу много меньше необходимости масштабироания нодов с бизнес-логикой. Предельный пример - разнообразные проекты распределённых вычислений, более близкое к бизнесу - разнообразный machine learning, где основная нагрузка - на вычислительные ресурсы, а от базы требуется скорее мощь выборки. Ну а если хочется совсем автоматического масштабирования (и, соответственно, подразумевается, что у вас "типичное" IO-bound приложение) - welcome to PaaS. Лично я, правда, держался бы подальше - там же что ни облако - то свой велосипед, не слезешь если что.
для облака подходит что угодно, что можно поставить, клонировать, размножить .... N тыс. раз.
> для облака подходит что угодно, что можно поставить, клонировать, размножить .... N
> тыс. раз.а как ты будешь синхронизировать данные в БД между нодами? и как будешь обеспечивать непротиворечивость данных в разных БД?
основной бонус облака в том, что ОДНО приложение работающее с ОДНИМ набором данных может почти линейно масштабироваться. ваш подход это просто ферма виртуалок.
Оно будет работать, только нафига вместо фермы VM городить облака? ;)
>> для облака подходит что угодно, что можно поставить, клонировать, размножить .... N
>> тыс. раз.
> а как ты будешь синхронизировать данные в БД между нодами? и как
> будешь обеспечивать непротиворечивость данных в разных БД?
> основной бонус облака в том, что ОДНО приложение работающее с ОДНИМ набором
> данных может почти линейно масштабироваться. ваш подход это просто ферма виртуалок.
> Оно будет работать, только нафига вместо фермы VM городить облака? ;)Линукс же поддерживает кластер через drbd можна просто паставить и все.
> Линукс же поддерживает кластер через drbd можна просто паставить и все.насколько хорошо будет работать ваш drbd когда количество нод хотя бы 10 и ВСЕ master, т.е. все пишушие данные? :)))
СУБД поверх drbd живут только если один master, а остальные - slave. иначе порушите файлы данных. Oracle живет в виде RAC аш до ЧЕТЫРЕХ! нод причем они шарят файлы данных. Выше 4 нод ставить не рекомендует сам производитель.
облачные СУБД изначально multi-master с почти линейным масштабированием. почитайте про принципы работы Amazon Dynamo.
Что и все? Какая польза от клона БД, если ее нельзя использовать одновременно с основной?
> а как ты будешь синхронизировать данные в БД между нодами? и как будешь обеспечивать непротиворечивость данных в разных БД?Это делается на уровне приложения, есть различные частные решения для PG (и вообще SQLных СУБД). Но кто тебе сказал что облако подразумевает решение этих проблем?
> основной бонус облака в том, что ОДНО приложение работающее с ОДНИМ набором данных может почти линейно масштабироваться.
это бонус не облака, кластера. Никакое приложение в облаке не может так просто масштабироваться.
бонус облака - пришёл на всё готовое, поюзал сервис и ушёл.
>> а как ты будешь синхронизировать данные в БД между нодами? и как будешь обеспечивать непротиворечивость данных в разных БД?
> Это делается на уровне приложения, есть различные частные решения для PG (и
> вообще SQLных СУБД). Но кто тебе сказал что облако подразумевает решение
> этих проблем?а нафига тогда облако? достаточно поднять кластер или пачку виртуалок =)))
>> основной бонус облака в том, что ОДНО приложение работающее с ОДНИМ набором данных может почти линейно масштабироваться.
> это бонус не облака, кластера. Никакое приложение в облаке не может так
> просто масштабироваться.Кластера из СУБД довольно плохо масштабируются - утыкаются в ACID и абзац. получается разделение ЛИБО транзакции на всю БД и непротиворечивость, но тогда нужен ЕДИНЫЙ центр (это не объект, а ресурс) контроля за ними и скорость упирается в его пропускную способность. ЛИБО отказаться от ACID в сторону более мягких требований и распределить транзакции по всем нодам кластера - Amazon Dynamo, Google BigTable, Apache Cassandra.
> бонус облака - пришёл на всё готовое, поюзал сервис и ушёл.
это один из бонусов )))