Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Революция в мире баз данных

Как-то занимаясь разработкой ТЗ для одного заказчика столкнулся в очередной раз с проблемой хранения/выборки данных в кластере — как уже надоело препарировать проекты под NoSQL базы ! И тут как будто кто решил разом прекратить все эти мучения и уткнул меня носом прямо в NuoDB. «Это что-то !», как любят говорить герои в буржуйских фильмах. NuoDB — это новое слово в технологиях баз данных от самого Джима Старки ! Да, того самого Старки, который в свое время придумал многоверсионные базы и тип BLOB, создал Interbase, участвовал в разработке FireBird и MySQL. А в 2008 году он перешел из MySQL в стартап Nimbus чтобы плотно заняться разработками в области облачных баз данных. Проект NuoDB (переименнованный из NimbusDB) — это без сомнения то, чего уже много лет ждали многие разработчики, пользователи и просто бизнесмены. И теперь с уверенностью можно сказать что они таки-да, дождались ;) Менеджмент компании NuoDB любезно разрешил мне перевести и опубликовать документ «Introduction to NuoDB» с целью поближе познакомить русскоязычное комьюнити с этим необыкновенным продуктом. Как говорят — «совершенная технология неотличима от магии», чего же больше в
NuoDB первого или второго, ее будущим пользователям вскоре предстоит узнать самим.
Итак, встречайте — NuoDB !

sfinx.od.ua/...олюция-в-мире-баз-данных

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

участвовал в разработке FireBird и MySQL.

MySQL? Мда.... После такой рекламы этой поделокой уж точно пользоваться не захочется.

Ув. аффтор, не понятно зачем вы запостили данный пост, на сайте нуоДБ сплошная вода да и в гугле тоже, да и вы прикрываетесь ДНА и на любой практический вопрос льете ту же воду. Мне как программисту данный пост дал 0 информации. К примеру если захочу узнать как реализуютса индексы в оракле, это легко найти, та даже не составляет труда узнать из чего состоит блок и более низкоуровневые вещи. Но на сайте нуоДБ помоему пока что только сказки, например говорится что БД основана по принципу битторента — данные выдаются\синхронизируются на основе пир-ту-пир, но как? какая реализация? какая структура дата файлов тогда? какие бенчмаки такой вот ондемант синхронизации? — информации 0. Я лично вернусь к этой базе, тогда и только тогда когда будет возможность хотябы поверхностно понять что это, а не тупо верить в сказки.

Нет смысла искать что-то свое заумно-программистское в introductory документе, да и тема вполне определенно указана с моем блог-сообщении — познакомить. Кому надо — тот просто возьмет и попробует. По крайней мере у себя в городе мне известны люди, которые ее спокойно тестируют без лишнего «шуму и пыли».

Нужно вернуться к данной БД через год-два, тогда можно будет о чем-то говорить. А именно, не умерла, живо поддерживается, стоит не как оракл и т.п. До этого юзать где-то, а тем более в продакшене, очень стремно. Хотя кластерная, балансирующая нагрузку из коробки БД это гуд.

А в 2008 году он перешел из MySQL

Судя по тому что он делал в MySQL и к что его дела дали на выходе, я не стану тратить время на изучение возможностей NuoDB (ну может пока не услышу хороший фидбек из авторитетного источника, что меня сильно удивит).

ЧСВ, однако — я думаю Джим этого даже не заметит ;)

При чем здесь моя важность? Просто житейский опыт, который обоснованно дает оценку топику (который к тому же бета-качества). Кстати не подскажете ответ на следующие вопросы:
1. Есть ли (планируется ли) открытая база багов? Сколько в ней открытых\закрытых багов сейчас?

2. в каком году вышла Бета 1 (мой гугл не ценит мое ЧСВ и не дает мне результатов)

3. когда планируется Продакшн релиз?

Опыт и важность суть разные вещи — выглядят и звучат они по разному. Багов не заметил, третья (последняя или предпоследняя) бета выйдет на днях. Насчет релиза точно не скажу, но в этом году точно. Задержки связаны с тем что они заявили 100% поддержку SQL99 — приходится много чего писать, параллельно прогоняя тесты исходя из стандарта.

А денег сколько будет стоить, известно?

Пока нет, есть правда слабый шанс что будет опенсорс — самому интересно

Будем надеятся что они пойдут типичным для таких проектов путем — gpl community версия с базовой функциональностью что бы завоевать популярность, и enterprise платная версия со всякими плюшками вроде продвинутого администрирования и мониторинга.

Ок, хоть на один вопрос из трех более или менее вразумительный ответ.
Если честно я не понимаю как задержки могут быть связаны с тем что они решили поддерживать стандарт SQL. Что, до этого планировали стандарт С++? Или без стандарта вообще?

Ну то такое, я ж не спорю что за эластичными ДБ — будущее, вопрос кто первый даст вразумительную реализацию. Я не против если это таки будет НуоДБ, просто честно не верю в революционность проекта со столькилетней историей (сколько кстати лет оно разрабатывается?)

Ни одна elastic база не поддерживает SQL99 полностью — только susbset. Попробуйте реализовать для начала парсер SQL99 и соответствующие заглушки и посчитайте время. Верить или не верить ваше неотьемлемое право — я предпочитаю применять или не применять/применять другое решение — это более практично.

Вообще то vertica и terradata думаю поддерживают, но ты наверное имел в виду олтп базы.

С каких это пор commit и rollback не часть стандарта ?

Вижу гуголь ты трудом освоил, полу-теоретик.

Ну подождем релиза, посмотрим какой там скл99 получится, и посмотрим кто из нас теоретик, а кто балабол сказочник.

Угм, а от тебя ждем отчетов по практическому использованию баз, которые ты с трудом нагуглил

С какого перепугу? Я тебе что-то обещал?

Ну ты заявил что «эта может и эта может и эта» — за свои слова как-бы нужно отвечать, если ты конечно не просто гугль-балаболка и можешь подкрепить слова делом.

Заявил что и где? Про скл99, я согласен, что они наверняка его полностью не поддерживают, но не из-за того что сложно команду комит или ролбэк заимплементить, а потому что у них другое предназначение. Я просто не ожидал от тебя такой буквальности.

“Кстати вот еще парочка для изучения: Clustrix, GenieDB, ScalArc, Schooner,
ScaleDB, Akiban, CodeFutures, ScaleBase, Translattice, MySQL Cluster with

NDB,JustOne DB”

“Та мне всеравно, я просто к тому что таких баз великое множество.”

“Например voltdb, memsql это те кто sql умеют, в этой области счас проспектов

хватает.”

“А погуглить?
VoltDB is very scalable; it should scale to 120 partitions, 39 servers, and
1.6 million complex transactions per second at over 300 CPU cores, on the
benchmarked configuration, with the recommended level of redundancy for HA.
www.mysqlperformanceblog.com/....-as-they-claim
Linear VoltDB Scalability on a 30-node SGI® Rackable™ C1001-TY3 Cluster
www.sgi.com/pdfs/4238.pdf

и т.д.

И что конкретно я тут нафантазировал?

Видишь-ли, мне не интересно/жаль своего времени обсуждать тут твои гугло-фантазии — мне интересен обмен опытом как минимум. А опыта-то пока не наблюдается, приходи когда он появится в разрезе данной темы.

Понятно, за базар сам-то не отвечаешь.

Ни одна elastic база не поддерживает SQL99 полностью — только susbset. Попробуйте реализовать для начала парсер SQL99 и соответствующие заглушки и посчитайте время. Верить или не верить ваше неотьемлемое право — я предпочитаю не применять или применять другое решение — это более практично.

Причем здесь другие БД? Вы сказали что _задержки_ из-за того что они _заявили_ поддежку стандарта.

Это как сказать что строители задерживают сдачу дома, так как они заявили что собираются строить фундамент в соответствии с ГОСТ.

Неверно, если применять аналогию со строителями, то жители хотят иметь системы типа «умный дом» в каждой квартире. После возведения дома на это требуется время — что тут непонятного ?

Задержки связаны с тем что они заявили 100% поддержку SQL99

«Требуется время» и «задержки» это разные вещи. Вот что Ушаков говрит:

ЗАДЕ́РЖКА, задержки, ·жен. Промедление, приостановка (вследствие какого-нибудь препятствия).

За сим откланиваюсь, тема исчерпала себя после первых нескольких ответов.

Никто вот эту штуку в облаках не пробовал?

scalr.net

я думаю что у большинства здесь нету нормального опыта с облаками,
поэтому не понимают фигли это нужно.
думаю, не будет новостью сказать что, к примеру, Zinga в облаках работает.

и куча других известных проектов

Слышал звон да не знаешь где он. Облака ортогональны топику.

А есть какие-то whitepapers, отзывы реальных клиентов, которые это внедрили или еще что-нибудь? Я понимаю, что там используются жутко секретные технологии, которые являются интеллектуальной собственностью, но фразы об использовании P2P не достаточно, чтобы доказать, что создатели этого продукта смогли обеспечить все три элемента CAP теоремы одновременно.

Есть, для этого нужно дождаться релиза или стать участником программы бета-тестирования.

shit, очередной “silver bullet” :-)

Не победить всем этим *DB вечно цветущий Оракл.

Я его не пользую, но интересно было бы услышать про опыт масштабирования и какой кровью, так сказать, это обходится, если конечно такое они могут без sharding, partitioning, и т.д. ?

К сожалению, имел опыт со скалабилити только на одном проекте ито на старой версии 8и, но если интересно можете почитать — lmgtfy.com/...11g scalability
Но имелось ввиду, судя по тенденциям, оракл купит сей новый продукт если он выростит в действительно что то конкурентно способное.

Типичный оракл энтерпрайз это когда данные лежат на SAN-e подключенном по fiber channel, и уже там происходит и шардинг и партиционирование данных.

Oracle продаёт серебрянные пули, дорого, для состоятельных господ.

Oracle RAC это то, что каждый первый стартап строит на второй год из 2+ MySQL серверов. Очень старый проект. SQL совместимый. Дорого как по лицензии так и по железу. Зато делать ничего не надо. Research In Motion (RIM) купил HP Super Dome для BB Messenger — насколько я помню это самое производительное железо на котором ещё может работать Oracle RAC. Если вам не хватает производительности и с ним, а риму не хватало, то выхода никакого нет.

Oracle coherence это то, что строит каждая компания, когда аудитория 10M+, а по запросам 5000 req/s — это in-memory data grid для отдачи контента. Казалось бы, чот там сложного поднял 30 мемкешей(mongoDB,couchDB, etc) и всё, а на самом деле проблемы только начинаются.

Если вам не хватает производительности и с ним, а риму не хватало, то выхода никакого нет.

Выход — нанять пару правильных чуваков из гугла или фейсбука, и они напишут Ц++ инмеморы апликуху которая будет делать тоже самое только на в 5-10 раз более слабом железе.

Я вот тут на досуге пытаюсь читать умную книжку.

Самый главный вывод — либо ACID никакого (что нужно учитывать в приложении), либо довольно большие трудозатраты на реализацию (несовместимые со скоростью появления новых БД на рынке, что как бы говорит о качестве). То, что работает в гугле, совершенно не будет работать в банке, например. А сейчас появляются необходимость масштабировать и такое.

Отказ от ACID, учет partial или eventual consistency в приложениях — эквивалентен переносу трудозатрат от разработки БД в разработку приложений. Именно поэтому мы видим очень хорошо масштабируемые решения у тех же больших контор типа гугла и фейсбука (которые сумели к этому привлечь кучу ресурсов), и дефицит повторно используемых «кирпичиков», которые бы обеспечивали сравнительно легкую и дешевую разработку, как с традиционными СУБД, хотя ситуация потихоньки исправляется.

Во первых речь шла о мессенджере, и выбор оракла, супердом2, и еще наверняка .нет/дж2ее — очевидный диагноз энтерпрaиза головного мозга.
Во вторых в куче случаев достаточно правильной стратегии организации данных и atomic compare on swap что бы обеспечить транзакционную целостность, без всяких mvcc, locks, undo/redo logs, и прочего оверхеда, а работать оно будет в разы быстрее.
В третьих есть куча факторов тюнинга системы которые с ораклом заюзать проблематично: optimistic vs pessimistic locking, columns vs rows oriented db, fsync on commit vs cluster redundency, как ты уже заметил eventual vs strong consistency, sync vs async db queries, shared nothing vs shared everything, все это может make difference на порядки.

Как уже заметили — оракл это прeтензия на серебрянную пулю, типа нагнать индусов, что бы они нагенерили кода, а потом другие индусы это гужевым способом нафиксили и это как то работало, но это все накапливает значительный оверхед.

Точно! надо позвонить пацанам, сказать.

Позвони позвони, пока не поздно,а то конторка видимо скоро окончательно загнется под бременем индийского капрокода.

Интересует, в общих словах, как происходит процесс масштабирования решения с применением оракла — вручную с применением там каких-то partitioning тулзов или прозрачно, простым наращиванием нодов ? Так же интересно можно ли вынести часть их кластера в другой датацентр — это значит что эта часть будет работать на серверах с другой производительностью и иметь неравномерный доступ по сети. Как это повлияет на его работу ?

токмо недавно видел статью что стартапы перестали юзать оракл

думаю, что Oracle и Cloud понятия тугосовместимые.

учитывая что сейчас все в облака уходят. сам подсел...

Oracle Exalogic Elastic Cloud — все buzz words присутствуют
www.oracle.com/...view/index.html

что сейчас все в облака уходят. сам подсел...
Да, мы слышали историю как ты прикупил впсик на линоде и беспокоился что злые накручивальщики тебе трафик скушают

Ok, попробую получить там account ;)

тяжело им будет пробиться , сейчас даже между опенсоурсовыми базами конкуренция.

Хотя Interbase\Firebird был хорош, жалко что они опаздали на веб ... теперь приходится мучаться с мускулем :)

Кхм ... тут как бы речь о elastic базах — mysql тут рядом не стоял

слова «elastic», «облака» из маркетинга.
в реальности — еще одна кластерная дб, нет ?

Слово elastic из жизни, а облако — краткий синоним длинного понятия «многофункциональный high availability multi-tenant кластер с централизованной системой управления». А эта DB не только кластерная — вот у меня на одной тестовой машинке крутится два NuoDB SQL сервера с десятком баз, и при необходимости я могу их растянуть, к примеру, на 200 машин не останавливая работу приложений с этими базами. Какая «еще одна» база такое может ?

Какая «еще одна» база такое может ?

Например voltdb, memsql это те кто sql умеют, в этой области счас проспектов хватает.

есть мнение что voltb плохо масштабируется (на сетапах в > 10 нодов), про memsql ничего не скажу, так как о такой даже не слышал

А погуглить?
VoltDB is very scalable; it should scale to 120 partitions, 39 servers, and 1.6 million complex transactions per second at over 300 CPU cores, on the benchmarked configuration, with the recommended level of redundancy for HA.

www.mysqlperformanceblog.com/...-as-they-claim

Linear VoltDB Scalability on a 30-node SGI® Rackable™ C1001-TY3 Cluster

www.sgi.com/pdfs/4238.pdf

А есть ли бенчмарки для нуоДБ?

Тут ключевое слово «should». Я конечно уважаю Стонебрейкера, но VoltDB это уже вчерашний день. Бенчмарки есть, но я под NDA ;)

Тут ключевое слово «should».

А почитать? Там же живой бенчмарк есть на котором это мнение базируется.

но VoltDB это уже вчерашний день.

Обоснуешь?

В этом бенчмарке четко видно что база уходит в штопор при масштабировании. При реальных проектах все наступает намного раньше чем в том красивом бенчмарке. Сюда следует добавить проблемы с гео-распределенностью, администрированием и поддержки ограниченного подмножества SQL — и это только навскидку.

В этом бенчмарке четко видно что база уходит в штопор при масштабировании

Есть подозрение что производительность упирается в сеть

При реальных проектах все наступает намного раньше чем в том красивом бенчмарке.

Есть конкретный опыт? Помоему все сильно зависит от паттернов использования.

Сюда следует добавить проблемы с гео-распределенностью,

datacenter awareness или его отсутствие это один из компромиссов CAP теоремы, а конкретно strong consistency vs partitioning resistense.

администрированием

что не так?

поддержки ограниченного подмножества SQL

Ой, никогда не поверю в поддержку полноценного sql джойнами, группировками и вложенными запросам в олтп расшардженной базе, слишком неподьемная задача.

Да есть опыт, я так понимаю он противоречит вашему — так поделитесь своим успешным примером использования VoltDB.

У меня нету опыта с вольтдб, но есть представление как оно устроено и во что может упираться.

добавить проблемы с гео-распределенностью

В их доке написано что есть возможность асинхронной репликации в географически удаленный кластер — вроде все по чесноку.

вольдб не реплицирует ноды, а только партиции. соберите сами простой гео-размазанный кластерок и отпадет необходимость в непонятных мне вопросах

вольдб не реплицирует ноды

Я где то писал про репликацию нодов?

отпадет необходимость в непонятных мне вопросах

Я вообще сейчас ничего не спрашивал.

Поговорим после того как вы будете в состоянии протестировать кластер на VoltDB и иметь на руках практические результаты. Не вижу смысла тут пересказывать вам ихний getting started.

ololo, разворачивать кластер что бы послушать сказки про сказочную бд, без конкретной информации(потому что nda), скудноватая овчинка, не находишь?

Я конечно дико извиняюсь, но пункт в NDA о неразглашении бенчмарков смотрится немного странно. Представьте себе ситуацию в магазине:

Клиент: У вас чайник хорошо воду кипятит?
Продавец: Лучше всех
Клиент: А за сколько он литр кипятит.

Продавец: Не скажу, это секрет. Но он лучше всех кипятит

Вот так и у вас. Тем более, что для проприетарного ПО бенчмарки — это чуть ли не единственный способ реально доказать, что оно может. Есть еще testimonials, но судя по всему с этим тоже пока негусто.

Feedback and testing procedures confidentiality включен в NDA — пункт 5. Если Вы серьезно заинтересованы в тестировании — у них на сайте есть форма — заполняете заявку, не думаю что будут проблемы.

вообще-то динамическое добавление\удаление нод — это почти единственная фича, которая отделяет кластерные базы от некластерных .

некластерным еще присуще отсутствие возможности масштабирования и тормознутость

«многофункциональный high availability multi-tenant кластер с централизованной системой управления»

Это все бла-бла-бла, в elastic главное — shared nothing architecture, а под такое определение простой реплицированный mysql попадает.

В elastic как бы главное не поиметь f*uckup когда у тебя юзверей многие и многие миллионы, поэтому это слово такое жизненное ;)

Какая “еще одна” база такое может ?

Кстати вот еще парочка для изучения: Clustrix, GenieDB, ScalArc, Schooner, ScaleDB, Akiban, CodeFutures, ScaleBase, Translattice, MySQL Cluster with NDB,JustOne DB

И на ком будем изучать ?

Та мне всеравно, я просто к тому что таких баз великое множество.

Никто и не сомневался что все равно ;)

Подписаться на комментарии