Comments 87
Вы столько раз употребили термин «Big Data», что стало интересно, а на какие объемы данных рассчитана БД?
На те, что в Excel уже не умещаются.
Если использовать AsterixDB как хранилище с простыми запросами, в перспективе будет масштабироваться на сотни терабайт-петабайты (нет планов делать ее кросс-дата-центр пока, так что в пределах одного ЦОДа). Подложка (Hyracks) тестировалась на больших кластерах (1700 ядер) очень успешно. Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
>> Сам храню порядка 50GB, но для сложных «аналитических» запросов.
аналитика зачастую подразумевает неизменяемые данные, тут вам что-то вроде presto (facebook) или impala (cloudera) нужна, вот они не в теории, а на практике уже очень неплохо масштабируются.
>> Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
о да, я даже знаю с чем сравнивали. Hive? =) У хадупа основной проблемой является постоянное насилование диска после map и reduce фаз, а значит построить нормальный join и тд сложно, но со второй версии map-reduce уже не прибит гвоздями, поэтому можно нормальный DAG реализовывать. tez.incubator.apache.org/
По коду AsterixDB местами ужас-ужас (классы устанешь читать название в десяток слов), в работе запросы напоминают hive (заливаем на hdfs xml с планом запроса, каждая нода затянула в себя и построило псевдо AST, дальше начинаем интерпретацию этого AST, все вроде и работает, но работает не сильно шустро). Скорость запросов на больших объемах неплохая у presto и impala, так как первая генерирует байткод для jvm, а вторая llvm псевдокод который компилится прямо в рантайме.
В момент когда бенчмарки обретут нормальный вид, для примера как здесь
amplab.cs.berkeley.edu/benchmark/
то можно будет заявлять о превосходстве в скорости выполнения запросов, а до этого…
Конечно это db больше для аналитики, а не для постоянных update как в обычной базе данных, но тогда без отказоустойчивости она вообще пока совсем сырая.
в общем пока у нее не видно четкого позиционирования:
1) отказоустойчивость и масштабирование — монга и кассандра, ну или коучбейз
2) скорость аналитики — импала и престо
3) целостность транзакций — обычный реляционки
если я что-то пропустил, то прошу указать
и еще вопрос: у нас есть таблица, мы запускаем выборку с аналитикой, в этот момент происходит обновления некоторых полей. Что будет у меня в выборке?
с sql я знаю, что получу, так как там есть транзакции
с системами аналитики тоже знаю, так как данные неизменяемы
аналитика зачастую подразумевает неизменяемые данные, тут вам что-то вроде presto (facebook) или impala (cloudera) нужна, вот они не в теории, а на практике уже очень неплохо масштабируются.
>> Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
о да, я даже знаю с чем сравнивали. Hive? =) У хадупа основной проблемой является постоянное насилование диска после map и reduce фаз, а значит построить нормальный join и тд сложно, но со второй версии map-reduce уже не прибит гвоздями, поэтому можно нормальный DAG реализовывать. tez.incubator.apache.org/
По коду AsterixDB местами ужас-ужас (классы устанешь читать название в десяток слов), в работе запросы напоминают hive (заливаем на hdfs xml с планом запроса, каждая нода затянула в себя и построило псевдо AST, дальше начинаем интерпретацию этого AST, все вроде и работает, но работает не сильно шустро). Скорость запросов на больших объемах неплохая у presto и impala, так как первая генерирует байткод для jvm, а вторая llvm псевдокод который компилится прямо в рантайме.
В момент когда бенчмарки обретут нормальный вид, для примера как здесь
amplab.cs.berkeley.edu/benchmark/
то можно будет заявлять о превосходстве в скорости выполнения запросов, а до этого…
Конечно это db больше для аналитики, а не для постоянных update как в обычной базе данных, но тогда без отказоустойчивости она вообще пока совсем сырая.
в общем пока у нее не видно четкого позиционирования:
1) отказоустойчивость и масштабирование — монга и кассандра, ну или коучбейз
2) скорость аналитики — импала и престо
3) целостность транзакций — обычный реляционки
если я что-то пропустил, то прошу указать
и еще вопрос: у нас есть таблица, мы запускаем выборку с аналитикой, в этот момент происходит обновления некоторых полей. Что будет у меня в выборке?
с sql я знаю, что получу, так как там есть транзакции
с системами аналитики тоже знаю, так как данные неизменяемы
Мне нужна именно аналитика на полу-структурированных данных — если бы у меня все ложилось хорошо в реляционку, я бы монгу ни за что не поставил бы.
Не считаю код ужас-ужас, нормальный код. И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы. И выполнять физические операторы — обычное дело, выигрыш от байткода мизерный, особенно когда можно потерять 20-100x производительности от плохой оптимизации запроса.
По тем же бенчам видно — Shark часто забивает Impala. При этом частенько всех мочит Амазон со своей ParAxel, который в свою очередь проигрывает устоявшимся решениям вроде Vertica или Neteeza (кстати Neteeza пошла гораздо дальше байткода и зашила кое-что в железо, только вот по слухам начинает все это чистить оттуда).
Про позиционирование: в классе СУБД для слабо-структурированных данных пока рулят XML-СУБД. но с ними замучаешься работать и бесплатные не особенно качественные. AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно. Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
По последнему вопросу — что-то вроде SQL dirty read.
Не считаю код ужас-ужас, нормальный код. И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы. И выполнять физические операторы — обычное дело, выигрыш от байткода мизерный, особенно когда можно потерять 20-100x производительности от плохой оптимизации запроса.
По тем же бенчам видно — Shark часто забивает Impala. При этом частенько всех мочит Амазон со своей ParAxel, который в свою очередь проигрывает устоявшимся решениям вроде Vertica или Neteeza (кстати Neteeza пошла гораздо дальше байткода и зашила кое-что в железо, только вот по слухам начинает все это чистить оттуда).
Про позиционирование: в классе СУБД для слабо-структурированных данных пока рулят XML-СУБД. но с ними замучаешься работать и бесплатные не особенно качественные. AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно. Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
По последнему вопросу — что-то вроде SQL dirty read.
>> И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы
ключевым в моей фразе было: «построило псевдо-AST, дальше начинаем интерпретацию этого AST»
добавим сюда ложку полиморфизма (мы же пишем унифицированные функции и тд) и на выходе получаем случай, когда сама работа с диском/сетью отходит на второй план, а основное время кушается cpu в попытке разобраться «что и откуда» надо считать, как это проинтерпретировать и куда потом сложить.
>> По тем же бенчам видно — Shark часто забивает Impala.
против Spark ничего не имею, наоборот только хорошие отзывы, но для структурируемых данных все-таки лучше sql-like решения, ну просто потому что для этого уже есть люди. А shark это попытка прозрачно заменить бекенд для hive с map-reduce на spark. попытка более-менее удачная, но еще не стабилизированна.
ParAxel — платный продукт, Vertica или Neteeza тоже платные с некислой такой ценой. Если уж очень хочется, то сюда можно еще докинуть Teradata и Exadata (Oracle), они тоже молотят со свистом данные, но ценник еще выше.
>> AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно.
MemSQL — обещаний вагон было, на практике это шардинг, если пытаться делать join 2х таблиц и результирующий датасет не влазит в память, то запрос обвалится. Ответ одного из разрабов: «да, запрос упадет, но ведь это не главное, главное что сервер продолжит работать». В итоге заявки про процессинг терабайт на нем вызывает улыбку.
NuoDB — обещание acid и всего что только можно, терабайты данных, оптимизации. На практике когда дошло до тестов, то сами разработчики разводили руками от такой «производительности».
MongoDB — заявления о терабайтах и масштабируемости (несколько сотен гигабайт, в принципе нормальный объем), но вот вам 2 сценария:
1) добавляем машинку в реплика сет, данные переливаются на нее за 15 минут, следующие 4 часа строим ПОСЛЕДОВАТЕЛЬНО все индексы на 1 ядре
2) добавляем машинку в шардинг, было 2 шарда по 150гб, ожидем что будет 3 по 100гб. ожидаем… СУТКИ, потому что перелив чанков идет ну просто ужасно медленно, для исключения излишней нагрузки на отдающие машинки.
Поэтому любые заявления о том что «X такую-же мощь принесет в мир Y, но не сразу, естественно» вызывают лишь улыбку, пускай сразу принесут, а уже потом начинают пиарится.
А слабоструктурированное хранение и выборку, так уже давно можно в поле запихать целиком json, а во время аналитики раскладывать это по нужным колонкам (hive,impala,shark уже давно это умеют, просто еще один storage format), а если уж совсем припрет, то одна строка может несколько строк породить в выход.
( cwiki.apache.org/confluence/display/Hive/LanguageManual+LateralView )
Так же почему-то упускают тот же couchbase, он в качестве value хранит json, через view можно и join сделать, хотя конечно к производительности к нему тоже есть претензии.
>> Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
Проект уже 5 лет развивается, начиная с 2009, я понимаю что разработка базы данных это не в носу ковыряться, но и про быстро не верю.
MongoDB первый выпуск 2009, cassandra 2008, про другие open source решения для аналитики я вообще молчу, они на фоне этого продукта по возрасту вообще дети.
ключевым в моей фразе было: «построило псевдо-AST, дальше начинаем интерпретацию этого AST»
добавим сюда ложку полиморфизма (мы же пишем унифицированные функции и тд) и на выходе получаем случай, когда сама работа с диском/сетью отходит на второй план, а основное время кушается cpu в попытке разобраться «что и откуда» надо считать, как это проинтерпретировать и куда потом сложить.
>> По тем же бенчам видно — Shark часто забивает Impala.
против Spark ничего не имею, наоборот только хорошие отзывы, но для структурируемых данных все-таки лучше sql-like решения, ну просто потому что для этого уже есть люди. А shark это попытка прозрачно заменить бекенд для hive с map-reduce на spark. попытка более-менее удачная, но еще не стабилизированна.
ParAxel — платный продукт, Vertica или Neteeza тоже платные с некислой такой ценой. Если уж очень хочется, то сюда можно еще докинуть Teradata и Exadata (Oracle), они тоже молотят со свистом данные, но ценник еще выше.
>> AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно.
MemSQL — обещаний вагон было, на практике это шардинг, если пытаться делать join 2х таблиц и результирующий датасет не влазит в память, то запрос обвалится. Ответ одного из разрабов: «да, запрос упадет, но ведь это не главное, главное что сервер продолжит работать». В итоге заявки про процессинг терабайт на нем вызывает улыбку.
NuoDB — обещание acid и всего что только можно, терабайты данных, оптимизации. На практике когда дошло до тестов, то сами разработчики разводили руками от такой «производительности».
MongoDB — заявления о терабайтах и масштабируемости (несколько сотен гигабайт, в принципе нормальный объем), но вот вам 2 сценария:
1) добавляем машинку в реплика сет, данные переливаются на нее за 15 минут, следующие 4 часа строим ПОСЛЕДОВАТЕЛЬНО все индексы на 1 ядре
2) добавляем машинку в шардинг, было 2 шарда по 150гб, ожидем что будет 3 по 100гб. ожидаем… СУТКИ, потому что перелив чанков идет ну просто ужасно медленно, для исключения излишней нагрузки на отдающие машинки.
Поэтому любые заявления о том что «X такую-же мощь принесет в мир Y, но не сразу, естественно» вызывают лишь улыбку, пускай сразу принесут, а уже потом начинают пиарится.
А слабоструктурированное хранение и выборку, так уже давно можно в поле запихать целиком json, а во время аналитики раскладывать это по нужным колонкам (hive,impala,shark уже давно это умеют, просто еще один storage format), а если уж совсем припрет, то одна строка может несколько строк породить в выход.
( cwiki.apache.org/confluence/display/Hive/LanguageManual+LateralView )
Так же почему-то упускают тот же couchbase, он в качестве value хранит json, через view можно и join сделать, хотя конечно к производительности к нему тоже есть претензии.
>> Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
Проект уже 5 лет развивается, начиная с 2009, я понимаю что разработка базы данных это не в носу ковыряться, но и про быстро не верю.
MongoDB первый выпуск 2009, cassandra 2008, про другие open source решения для аналитики я вообще молчу, они на фоне этого продукта по возрасту вообще дети.
Проект на самом деле очень молодой — сначала делали Hyracks для sql-данных и замены map-reduce. И работает пока над ним совсем небольшая команда, и кстати особо не пиарятся — выступают на конференциях, но в open-source community шум не создают пока. Но ребята опытные, за плечами пару СУБД уже есть, так что не понимаю такое обилие критики.
Насчет полиморфизма — какой полиморфизм, при их модели данных? Нет его, приходится для неизвестных данных делать type promotion и следить за легальностью типов, но все решается созданием схемы и написанием упрощенных функций. Да и сомневоюсь что только из-за этого система будет в cpu сидеть.
Зато у них LSM структуры, хорошая физическая алгребра для параллельных запросов, появляется нормальный оптимизатор, и т.п. То есть будет полноценная параллельная СУБД.
Насчет полиморфизма — какой полиморфизм, при их модели данных? Нет его, приходится для неизвестных данных делать type promotion и следить за легальностью типов, но все решается созданием схемы и написанием упрощенных функций. Да и сомневоюсь что только из-за этого система будет в cpu сидеть.
Зато у них LSM структуры, хорошая физическая алгребра для параллельных запросов, появляется нормальный оптимизатор, и т.п. То есть будет полноценная параллельная СУБД.
>> Initiated in 2009, the NSF-sponsored ASTERIX project has been developing new technologies for ingesting, storing, managing, indexing, querying, and analyzing vast quantities of semi-structured information.
Копирайт во всех файлах тоже от 2009 года.
>> так что не понимаю такое обилие критики
Позиционироваться как открытое решение и держать закрытой google группу с обсуждением как-то у меня не вяжется. Конечно можно запросить приглашение и тд, но иногда хочется сразу посмотреть/погуглить, а уже потом думать связываться или нет, тут же этот сценарий не подходит.
Основная разработка идет несколькими людьми из университетов, разработка больше похожа на «мы вот тут пилим крутую хрень», вся суть в том, что без попыток регулярных прогонов в продакшене все эти разработки так и остаются крутыми на бумаге, попытка запуска в реальном проде сразу подымает пачку нестандартных проблем. Я только рад таким проектам и желаю им удачи, но практика показывает, что большинство университетских начинаний умирает так и не дожив до реального внедрения, хотя идеи которые они обкатывают потом растаскиваются по проектам с большим удовольствием. Конечно есть исключения, но их очень мало, и буду рад если этот проект попадет в их число.
А критика идет в первую очередь на ваш необоснованный оптимизм ;)
Копирайт во всех файлах тоже от 2009 года.
>> так что не понимаю такое обилие критики
Позиционироваться как открытое решение и держать закрытой google группу с обсуждением как-то у меня не вяжется. Конечно можно запросить приглашение и тд, но иногда хочется сразу посмотреть/погуглить, а уже потом думать связываться или нет, тут же этот сценарий не подходит.
Основная разработка идет несколькими людьми из университетов, разработка больше похожа на «мы вот тут пилим крутую хрень», вся суть в том, что без попыток регулярных прогонов в продакшене все эти разработки так и остаются крутыми на бумаге, попытка запуска в реальном проде сразу подымает пачку нестандартных проблем. Я только рад таким проектам и желаю им удачи, но практика показывает, что большинство университетских начинаний умирает так и не дожив до реального внедрения, хотя идеи которые они обкатывают потом растаскиваются по проектам с большим удовольствием. Конечно есть исключения, но их очень мало, и буду рад если этот проект попадет в их число.
А критика идет в первую очередь на ваш необоснованный оптимизм ;)
Вы действительно уверены в том, что главная проблема MongoDB — это отсутствие схемы и неудобный (или, скажем, на любителя) язык запросов/аггрегации?
Лично для меня это пока самые неприятные места Mongo. Хотя и скорость и объемы съедаемой памяти/диска тоже начинают нервировать. Опять же, AsterixDB эти проблемы решает, но это уже другая статья
Так ведь «отсутствие схемы и неудобный язык запросов» решаются использованием ORM, которая может контролировать соблюдение схемы и вводить свой оригинальный язык построения запросов. Не?
Со схемой можно еще справится таким путем, хотя у меня из разных языков в монгу лазают, и нужен тогда еще универсальный ORM.
А с запросами это как — грузим все данные в клиента и там пускаем запросы? А если надо сджоинить несколько коллекций? Сгруппировать тучу данных?
А с запросами это как — грузим все данные в клиента и там пускаем запросы? А если надо сджоинить несколько коллекций? Сгруппировать тучу данных?
Есть такая штука в монго: Aggregation Pipeline, позволяет делать выборки любой сложности.
Это покрывает только один select-group-aggregate шаг, добавить джоин суда нельзя, сделать агрегацию сразу на 2-3 уровнях тоже.
Что значит на 2-3 уровнях?
А насчет джойнов, то тут наверняка проблема в организации структуры данных. Джойны нужны в реляционных СУБД. В Монго денормализация является вполне нормальной практикой. Так что если нужны джойны, то стоит подумать над архитектурой БД.
А насчет джойнов, то тут наверняка проблема в организации структуры данных. Джойны нужны в реляционных СУБД. В Монго денормализация является вполне нормальной практикой. Так что если нужны джойны, то стоит подумать над архитектурой БД.
Если структура данных вложенная, то иногда требуется группировка и агрегация на нескольких уровнях.
Вот синтетический пример:
-customer
-order
-order_line_item
сгруппировать кастомеров по регионам, внутри каждого сгруппировать orders по категории товара, подсчитать агрегаты на всех уровнях
Вот синтетический пример:
-customer
-order
-order_line_item
сгруппировать кастомеров по регионам, внутри каждого сгруппировать orders по категории товара, подсчитать агрегаты на всех уровнях
Прелесть MongoDB в том, что можно создавать структуры любой вложенности и потом делать с ними все, что угодно:
А потом customer'ы шардятся на разные сервера. Хотя при таком подходе в дело вступает ограничение на размер одного объекта.
Можно сделать еще иначе (хоть при этом и довольно много дублей получается, но можно в поле customer хранить не весь профиль пользователя, а только необходимые вещи: айди, регион, имя — при этом при изменении этих данных в настройках профиля здесь их можно не менять, т.к. заказ был на старое имя из старого региона — это уже история):
В общем, все зависит от того, как спроектировать БД.
customer = {
objectId: ...,
...,
orders: [
objectId: ...,
...
items: [
objectId: ...,
...
]
]
}
А потом customer'ы шардятся на разные сервера. Хотя при таком подходе в дело вступает ограничение на размер одного объекта.
Можно сделать еще иначе (хоть при этом и довольно много дублей получается, но можно в поле customer хранить не весь профиль пользователя, а только необходимые вещи: айди, регион, имя — при этом при изменении этих данных в настройках профиля здесь их можно не менять, т.к. заказ был на старое имя из старого региона — это уже история):
order = {
objectID: ...,
customer: {
objectID: ...,
name: ...,
region: ...,
...
},
items: [ ... ]
}
В общем, все зависит от того, как спроектировать БД.
del
Вы действительно уверены в том, что главная проблема MongoDB — это
А какая главная проблема?
Индексы вымываются из памяти данными
mongos складывается, если в одном из шардов нет мастеры
Ну и блокировки на целую БД
mongos складывается, если в одном из шардов нет мастеры
Ну и блокировки на целую БД
Ну это кстати не фундаментальные проблемы дизайна СУБД, могут быстро допилить с их финансированием
Блокировки уже давно не на всю БД, а на коллекцию. Тоже великовато, но всё же.
Блокировки уже давно не на всю БД, а на коллекцию
Уже не первый раз вижу это утверждение, откуда такая информация?
Вот задача Collection-level locking у них все ещё открыта.
FAQ: Concurrency:
Beginning with version 2.2, MongoDB implements locks on a per-database basis for most read and write operations. Some global operations, typically short lived operations involving multiple databases, still require a global “instance” wide lock. Before 2.2, there is only one “global” lock per mongod instance.
Ну и блокировки на целую БД
Читал на зарубежных форумах, что эти блокировки не являются проблемой, проблемы начинаются когда база упирается в io, и начинает «тормозить», но она и без блокировок «тормозила» бы из за io.
Красивая теория, жаль что не работает — половина данных и индексов лежат в памяти же.
Работает, я для тестов разворачивал базу на RAM разделе, никаких тормозов из-за блокировок не было, монга выкладывалась на 100%.
Если в цифрах, то где-то было около 12К/сек insert-документов на одно ядро старенького ноутбука, при этом чтения выполнялись мгновенно.
У меня на проектах обычно данных на порядок больше чем оперативной памяти (зависит от задачи), поэтому там не может лежать половина.
Если в цифрах, то где-то было около 12К/сек insert-документов на одно ядро старенького ноутбука, при этом чтения выполнялись мгновенно.
половина данных и индексов лежат в памяти же.
У меня на проектах обычно данных на порядок больше чем оперативной памяти (зависит от задачи), поэтому там не может лежать половина.
Индексы вымываются из памяти данными
Такого не должно быть, как это можно проверить?
А что скажете про TokuMX в этом контексте?
Если использовать AsterixDB как хранилище с простыми запросами, в перспективе будет масштабироваться на сотни терабайт-петабайты (нет планов делать ее кросс-дата-центр пока, так что в пределах одного ЦОДа). Подложка (Hyracks) тестировалась на больших кластерах (1700 ядер) очень успешно. Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
нет репликации для отказоустойчивости
То есть нет того, что в монге сделано не просто хорошо, а прямо-таки лучше чем у всех остальных :)
...еще нет же.
сколько не видел носкльщиков, всегда одно и то же
1. сначала начинают проект на NoSQL бд т.к. SQL это непонятно и сложно
2. появляются проблемы и выясняется что требования к ссылочной целостности и строгость схемы в SQL-серверах не просто так
3. пытаются изобрести велосипед и воссоздать всё это средствами выбранного NoSQL решения
4. выясняют что фишки которые способствовали выбору NoSQL-решения (типа вывод в JSON или XML) для обработки данных вообще малозначны
5. переписывают под нормальный SQL-сервер (ну или проект загибается)
1. сначала начинают проект на NoSQL бд т.к. SQL это непонятно и сложно
2. появляются проблемы и выясняется что требования к ссылочной целостности и строгость схемы в SQL-серверах не просто так
3. пытаются изобрести велосипед и воссоздать всё это средствами выбранного NoSQL решения
4. выясняют что фишки которые способствовали выбору NoSQL-решения (типа вывод в JSON или XML) для обработки данных вообще малозначны
5. переписывают под нормальный SQL-сервер (ну или проект загибается)
1. сначала начинают проект на NoSQL бд т.к. SQL это непонятно и сложно
SQL это вполне понятно и, не сказать, что просто, но вполне осваиваемо.
2. появляются проблемы и выясняется что требования к ссылочной целостности и строгость схемы в SQL-серверах не просто так
3. пытаются изобрести велосипед и воссоздать всё это средствами выбранного NoSQL решения
4. выясняют что фишки которые способствовали выбору NoSQL-решения (типа вывод в JSON или XML) для обработки данных вообще малозначны
Просто нужно чёткое понимание, для чего использовать NoSQL-хранилище, а для чего обычную базу и не пытаться городить огород там, где его крайне сложно поставить.
Тогда посмотрите на меня (нас), мы храним в монге, и ни в какие sql переходить не будем. Предыдущие инкарнации это же задачи были в sql, и там не очень нравилось.
На счет схемы поддержу высказавшихся выше — если нужно что-то ограничивать и контролировать, то это можно делать до базы.
На счет схемы поддержу высказавшихся выше — если нужно что-то ограничивать и контролировать, то это можно делать до базы.
Если не секрет, то какие данные храните? И как обрабатываете?
абстрактно: заказ на выполнения множества услуг, который в реляционной базе распадется на пачку связанных таблиц, монге остается одним документом. По ходу выполнения — документ модифицируется/дополняется.
Статистика у нас в этом месте тривиальная, правда. В качестве исследований пробовали закинуть кучу данных из основной базы и собрать/посчитать нужные отчеты. Процесс реализации получается не сложнее (по сути те же яйца, только в профиль), но результат внутри (и в базе и в коде) выглядит гораздо понятнее и проще в развитии.
Пока переход на nosql у нас в одной подсистеме, но нам нравится, и при новых задачах смотрим в эту сторону в первую очередь.
Статистика у нас в этом месте тривиальная, правда. В качестве исследований пробовали закинуть кучу данных из основной базы и собрать/посчитать нужные отчеты. Процесс реализации получается не сложнее (по сути те же яйца, только в профиль), но результат внутри (и в базе и в коде) выглядит гораздо понятнее и проще в развитии.
Пока переход на nosql у нас в одной подсистеме, но нам нравится, и при новых задачах смотрим в эту сторону в первую очередь.
А как проблему изменения схемы обходите? Меняете данные или учитываете в коде?
Например: раньше было одно поле с телефоном, а теперь — массив. Или сложнее — раньше у услуги был один заказчик, а теперь — множество.
Например: раньше было одно поле с телефоном, а теперь — массив. Или сложнее — раньше у услуги был один заказчик, а теперь — множество.
У нас вообще глобальный подход — если что-очень меняется в модели данных — хранимые данные преобразуются к новой версии с обновлением ПО. Это на уровне философии вообще, от того что там внутри не зависит. В этой подсистеме навскидку не помню такой ситуации, область для нас хорошо известная/
Был вопрос вида «одна коллекция и поле в документе или имя коллекции. Были опасения, что блокировки при записи будут мешать, смотрели насколько есть запас производительности на больших объемах данных. (сравнение показалао, что нам хватит на долго). Так вот, разница в коде между двумя „моделями“ в получалась меньше, чем разница между моделями в коде поверх реляционной базы.
Если подход „при обновлении софта модифицируется все данные“ в не устраивает (реально большие данные), то код который сможет работать с разными версиями получается проще, чем при изменениях связей в реляционной базе.
Если немного отойти в сторону от конкретики: какие изменения в схеме бывают (очень грубо):
1. скаляр стал списком
sql: создали новую таблицу, новый класс в модель, в основном классе переписали методы вместо присвоить значение — изменить список, вместо прочесть значение — выбрать из списка.
nosql: нужно сделать это же, только без новой сущности и новой связи
2. скаляр стал классом
sql: создали новую таблицу, новый класс в модель, работа с классом.
nosql: новый класс в модель, работа с новым классом. Как хранить новый документ — внутри уже имеющихся или в отдельной коллекции — второй вопрос, может рассматриваться отдельно и позже.
Ссылки так и остаются ссылками, срезы так и остаются выборками. Если нужно собрать более „крупные“ документы из нескольких более мелких из разных коллекций — кто-то должен написать грамотно или на уровне базы или в приложении. Если нужно что-то пачкой обновить — тоже нужно грамотно писать update. Понимать что там внутри — нужно.
Хочется сказать „с простыми изменениями у nosql проще, в сложных — примерно так же“, но в лоб такие вещи сравнивать не очень хорошо, взгляд на данные с другого ракурса.
На ум приходит такая аналогия: „по ощущениям“ переход sql -> nosql получился как когда-то был переход от структурной парадигмы к объектной. Мозгов нужно столько же, но прикладывать иначе и в других местах.
Был вопрос вида «одна коллекция и поле в документе или имя коллекции. Были опасения, что блокировки при записи будут мешать, смотрели насколько есть запас производительности на больших объемах данных. (сравнение показалао, что нам хватит на долго). Так вот, разница в коде между двумя „моделями“ в получалась меньше, чем разница между моделями в коде поверх реляционной базы.
Если подход „при обновлении софта модифицируется все данные“ в не устраивает (реально большие данные), то код который сможет работать с разными версиями получается проще, чем при изменениях связей в реляционной базе.
Если немного отойти в сторону от конкретики: какие изменения в схеме бывают (очень грубо):
1. скаляр стал списком
sql: создали новую таблицу, новый класс в модель, в основном классе переписали методы вместо присвоить значение — изменить список, вместо прочесть значение — выбрать из списка.
nosql: нужно сделать это же, только без новой сущности и новой связи
2. скаляр стал классом
sql: создали новую таблицу, новый класс в модель, работа с классом.
nosql: новый класс в модель, работа с новым классом. Как хранить новый документ — внутри уже имеющихся или в отдельной коллекции — второй вопрос, может рассматриваться отдельно и позже.
Ссылки так и остаются ссылками, срезы так и остаются выборками. Если нужно собрать более „крупные“ документы из нескольких более мелких из разных коллекций — кто-то должен написать грамотно или на уровне базы или в приложении. Если нужно что-то пачкой обновить — тоже нужно грамотно писать update. Понимать что там внутри — нужно.
Хочется сказать „с простыми изменениями у nosql проще, в сложных — примерно так же“, но в лоб такие вещи сравнивать не очень хорошо, взгляд на данные с другого ракурса.
На ум приходит такая аналогия: „по ощущениям“ переход sql -> nosql получился как когда-то был переход от структурной парадигмы к объектной. Мозгов нужно столько же, но прикладывать иначе и в других местах.
Это вы не nosql-щиков описываете, а говнокодеров.
База — это инструмент, а не цель. И не стоит винить ее в том, что разработчик бездумно ее выбрал
База — это инструмент, а не цель. И не стоит винить ее в том, что разработчик бездумно ее выбрал
Можно конечно хранить json в блобах :) и будет nosql.
Вы так говорите, как будто это что-то плохое. :)
Я когда пытался учить Python и Google App Engine в частности (я сам не программист, но сочувствую), решил написать для себя небольшую систему сбора и отображения статистики. По-честному прочитал мануал. Создал коллекции subjects (около 10 элементов), objects (порядка 100 элементов на каждый subject) с ключом subject, ну и стал писать в коллекцию updates с ключом (datetime, subject, object) свои данные. Все как в обычном SQL, не зря же ссылочный тип был сделан, да и в мануале приводятся подобные модели. На SDK все это дело худо бедно крутилось, но в GAE первый же запуск задачи обновления данных съел 30% бесплатных операций записи, а отображения таблицы еще 30% операций чтения. Оказалось, что GAE каждое обращение к свойству элемента коллекции засчитывает как операцию чтения/записи, хотя для меня из мануала это почему было не очевидно. Я подумал, что чтение и запись происходит только при операциях get()/put().
В итоге, сделал сериализацию коллекции одной порции данных в blob по ключу (datetime, subject), добавил немного memcache и приложение стало съедать около 1% операций в день.
Задача была решена — я мог на определенный момент времени смотреть свои данные или изменения за заданный период (разность двух моментов). Но, например, график при такой модели уже не построишь.
Я когда пытался учить Python и Google App Engine в частности (я сам не программист, но сочувствую), решил написать для себя небольшую систему сбора и отображения статистики. По-честному прочитал мануал. Создал коллекции subjects (около 10 элементов), objects (порядка 100 элементов на каждый subject) с ключом subject, ну и стал писать в коллекцию updates с ключом (datetime, subject, object) свои данные. Все как в обычном SQL, не зря же ссылочный тип был сделан, да и в мануале приводятся подобные модели. На SDK все это дело худо бедно крутилось, но в GAE первый же запуск задачи обновления данных съел 30% бесплатных операций записи, а отображения таблицы еще 30% операций чтения. Оказалось, что GAE каждое обращение к свойству элемента коллекции засчитывает как операцию чтения/записи, хотя для меня из мануала это почему было не очевидно. Я подумал, что чтение и запись происходит только при операциях get()/put().
В итоге, сделал сериализацию коллекции одной порции данных в blob по ключу (datetime, subject), добавил немного memcache и приложение стало съедать около 1% операций в день.
Задача была решена — я мог на определенный момент времени смотреть свои данные или изменения за заданный период (разность двух моментов). Но, например, график при такой модели уже не построишь.
мы используем и то и другое. Причем mongo только как readonly cache. Получилось круто.
Ситуация даже хуже. Нужно добавить предысторию.
Пункт 0: «я слышал, что NoSQL — это модно и круто, а SQL — это старый отстой...»
Пункт 0: «я слышал, что NoSQL — это модно и круто, а SQL — это старый отстой...»
Хм, а как по мне, когда есть модели, то схема не особо то нужна… И не приходиться второй раз схему дублировать в моделе.
А как с быстродействием? Тот же простой «джойн» насколько быстро исполняется? Вернее насколько он зависит от размеров обеих таблиц? Не получается что сложность у него O(n1*n2)?
На всякий случай, вдруг, кто пропустил — если такая штука handlersocket для доступа к MySQL БД. У akalend есть плагин для NGINX. Ну и других биндингов в сети тоже есть. Лично для меня, главный плюс этого механизма — не надо заменять целиком движок БД, под который уже написаны тонны кода, но можно выборочно улучшить производительность ряда запросов.
У akalend есть плагин для NGINX.Который блокирует nginx, т.е. можно считать, что нету.
согл, мой плагин блокирующий, по этому смысла его использовать нет :)
но есть и хорошие новости: плагин Романа Аратюняна github.com/arut/nginx-mysql-hsock-module,
он же автор плагина видеовещания, в том числе и коммерческой версии.
но есть и хорошие новости: плагин Романа Аратюняна github.com/arut/nginx-mysql-hsock-module,
он же автор плагина видеовещания, в том числе и коммерческой версии.
Хм, язык запросов выглядит так же, как и LINQ, так что какой-нибудь Linq to Asterixdb не за горами…
Вставлю свои пару слов.
Нужен прототип блогоплатформы или новостного сайта? Берите mongo, все шикарно — репликация из коробки, json положили — json вытащили, красота!
Нужна финансовая аналитика/биллинговая система? Ну извините, тут без транзакций, джоинов и строгой схемы будете плакать и страдать.
Мое личное мнение (как я понял примерный формат целевых проектов для mongo) — эта база для хранения одной большой коллекции, либо нескольких слабо связанных. Поясню на примере: слабая связь — это связь, которая не используется в агрегации, например, связь таблиц users и posts в абстрактном приложении-блоге. Информация из users нам никогда не понадобится до агрегации. Противоположный пример — банковское ПО, где в сложной аналитике мы никак не обойдемся одной табличкой с транзакциями.
Как asterixDB собирается вписаться между двумя такими разными концепциями — пока не понимаю. Стремление угодить всем может обернуться эпической неудачей
Нужен прототип блогоплатформы или новостного сайта? Берите mongo, все шикарно — репликация из коробки, json положили — json вытащили, красота!
Нужна финансовая аналитика/биллинговая система? Ну извините, тут без транзакций, джоинов и строгой схемы будете плакать и страдать.
Мое личное мнение (как я понял примерный формат целевых проектов для mongo) — эта база для хранения одной большой коллекции, либо нескольких слабо связанных. Поясню на примере: слабая связь — это связь, которая не используется в агрегации, например, связь таблиц users и posts в абстрактном приложении-блоге. Информация из users нам никогда не понадобится до агрегации. Противоположный пример — банковское ПО, где в сложной аналитике мы никак не обойдемся одной табличкой с транзакциями.
Как asterixDB собирается вписаться между двумя такими разными концепциями — пока не понимаю. Стремление угодить всем может обернуться эпической неудачей
Ну мир не делится на блоггеров и финансистов, уверен достаточно кейсов для Asterix. Я сам совсем не блогов юзаю монгу, у меня туча вложенных структур, которые постоянно чем-то пополняются и ломятся в базу разношерстные клиенты. При этом надо делать нормальные репорты, а с монго я замучился. Уже выгружаю все в Asterix и там пишу запросы на приятном QL. Но у меня нишевый кейс.
А так я вижу такую последовательность — подсели на монго именно из-за простоты, потом требуется более сложный функционал, но переходить на реляционку не хочется. Просто перегружаем данные в AsterixDB и продолжаем радостно существовать.
А так я вижу такую последовательность — подсели на монго именно из-за простоты, потом требуется более сложный функционал, но переходить на реляционку не хочется. Просто перегружаем данные в AsterixDB и продолжаем радостно существовать.
Мы тоже отказались от монги. Перешли на Redis.
Кто-нибудь пробовал работать с RethinkDB?
На главном сайте ссылки на код не нашёл. Кажется вот он: code.google.com/p/asterixdb/
Посмотрел код… Мне кажется что производительность будет ужасная, особенно когда будет сделана попытка добавить устойчивость к сбоям, репликацию и масштабирование. Очень неприятно выглядит реализованная система типов и алгебра поверх нативных типов JVM. С одной стороны она очень примитивная (особенно по сравнению с postgresql), с другой стороны очень многословная. Я проследил выполнение функции max, которая SQL_MAX в исходниках. Код написал в «лучших» традициях энтерпрайзной Java. На пути выполнения простой функции встречаются десятки фабрик, классов-обёрток и прочего. И бОльшая часть кода отвечает за выведение типа и поиск к нему компаратора, а не собственно поиск максимального элемента. Плюс если у меня будет триллион записей типа int и одна последняя какого-нибудь несравнимого с int типа, то max вычислит max для всего триллиона и только на последней записи отправит Exception, что тип для всего выражения не вывелся.
Посмотрел и публикации. Более интересным показалось управление памятью в Hyracks ( code.google.com/p/hyracks ). Хотя я плохо понимаю зачем писать на Java, если при этом используется кастомный менеджер памяти почти для всего. Причём кастомный менеджер памяти использует ByteBuffer.allocate(), который создаёт массив внутри JVM Heap. То есть память получается под управлением родного JVM GC и кастомного внутри Hyracks.
В общем, проект молодой и исследовательский. Поэтому написан свой язык запросов, своя библиотека парсера, своя система типов и своя алгебра. Свой менеджер памяти и менеджер задач. Ничего не имею против, студентам очень полезно всё это писать и изучать. Но вот использовать результат в продакшене я бы не советовал.
Посмотрел код… Мне кажется что производительность будет ужасная, особенно когда будет сделана попытка добавить устойчивость к сбоям, репликацию и масштабирование. Очень неприятно выглядит реализованная система типов и алгебра поверх нативных типов JVM. С одной стороны она очень примитивная (особенно по сравнению с postgresql), с другой стороны очень многословная. Я проследил выполнение функции max, которая SQL_MAX в исходниках. Код написал в «лучших» традициях энтерпрайзной Java. На пути выполнения простой функции встречаются десятки фабрик, классов-обёрток и прочего. И бОльшая часть кода отвечает за выведение типа и поиск к нему компаратора, а не собственно поиск максимального элемента. Плюс если у меня будет триллион записей типа int и одна последняя какого-нибудь несравнимого с int типа, то max вычислит max для всего триллиона и только на последней записи отправит Exception, что тип для всего выражения не вывелся.
Посмотрел и публикации. Более интересным показалось управление памятью в Hyracks ( code.google.com/p/hyracks ). Хотя я плохо понимаю зачем писать на Java, если при этом используется кастомный менеджер памяти почти для всего. Причём кастомный менеджер памяти использует ByteBuffer.allocate(), который создаёт массив внутри JVM Heap. То есть память получается под управлением родного JVM GC и кастомного внутри Hyracks.
В общем, проект молодой и исследовательский. Поэтому написан свой язык запросов, своя библиотека парсера, своя система типов и своя алгебра. Свой менеджер памяти и менеджер задач. Ничего не имею против, студентам очень полезно всё это писать и изучать. Но вот использовать результат в продакшене я бы не советовал.
Ну я бы не стал делать настолько далеко-идущие выводы, на основе одной функции SQL_MAX — она написана для обработки разнородных данных, их действительно надо проверять и промоутить, ничего не поделаешь. Ничего не стоит сделать оптимизированную функцию под один тип и подставлять ее в этих случаях (когда оптимизатор знает, что тип один для всех значений). А если мы ничего не знаем про типы данных, то как избежать Exception на неправильном типе? Никак.
Масштабирование уже есть, нет репликации для отказоустойчивости пока.
Насчет памяти — СУБД всегда управляет своей памятью, особенно в Яве нельзя память отдавать на откуп GC — все встанет колом.
Проект довольно молодой, естественно с большой исследовательской составляющей. Но язык запросов не свой — это просто упрощенная XQuery, алгебра тоже проверенная из XML СУБД, конечно свой парсер (у всех свой парсер). И в основном пишут не студенты, а 2 парня, которые ушли из Оракла, ну и аспиранты, которыми они руководят. А Постгресс как раз был одними аспирантами написан, и вот — допилили в конце концов до крутой системы.
В общем зная эту комманду, уверен, результат будет вполне себе промышленный. Вопрос времени.
Масштабирование уже есть, нет репликации для отказоустойчивости пока.
Насчет памяти — СУБД всегда управляет своей памятью, особенно в Яве нельзя память отдавать на откуп GC — все встанет колом.
Проект довольно молодой, естественно с большой исследовательской составляющей. Но язык запросов не свой — это просто упрощенная XQuery, алгебра тоже проверенная из XML СУБД, конечно свой парсер (у всех свой парсер). И в основном пишут не студенты, а 2 парня, которые ушли из Оракла, ну и аспиранты, которыми они руководят. А Постгресс как раз был одними аспирантами написан, и вот — допилили в конце концов до крутой системы.
В общем зная эту комманду, уверен, результат будет вполне себе промышленный. Вопрос времени.
Если принято решение самостоятельно управлять памятью, так пожалуйста — добро пожаловать в off-heap. У Hazelcast кажется была бесплатная версия хотя бы. Или на ByteBuffer.allocateDirect() можно безболезненно перейти (но он не гарантирован в off-heap). Ну и я бы не был столь категоричен с «нельзя память отдавать на откуп GC». У меня были приличные БД в продакшене на Cassandra и SOLR (и видел ещё на ElasticSearch). Как раз базы данных на Java, но к ним написано руководство по GC-tuning. JVM GC может оказаться хорошим другом, если он настроен правильно.
Вы не подумайте, что я ругаю. Несколько негативный тон комментария просто реакция на (на мой взгляд) черезмерно радужный посыл основной статьи. Так сказать предупреждение — подумайте хорошо: действительно ли вам подходит это решение.
А если есть желание помочь авторам допилить эту БД: то конечно помогайте. Код довольно читаемый, кое-где комментарии бы не помешали, но самые критичные места откомментированы. Разве что пугает объём этого кода… Ну так это же БД.
Вы не подумайте, что я ругаю. Несколько негативный тон комментария просто реакция на (на мой взгляд) черезмерно радужный посыл основной статьи. Так сказать предупреждение — подумайте хорошо: действительно ли вам подходит это решение.
А если есть желание помочь авторам допилить эту БД: то конечно помогайте. Код довольно читаемый, кое-где комментарии бы не помешали, но самые критичные места откомментированы. Разве что пугает объём этого кода… Ну так это же БД.
Еще одна NoSQL база данных? Нет уж, увольте. Поработав очень плотно с кучей разнообразных данных в течение года, перепробовав множество инструментов, я пришел к выводу, что всю эту новомодную шумиху нужно жестко отсеивать. Классов задач не так уж и много, и в каждом уже есть свой лидер, проверенный временем. Пусть он не идеален, зато по нему уже много документации, большое комьюнити, библиотеки и т.п.
Программист должен быть немного консерватором, и уж точно не должен гоняться за новомодными штучками как девушка за чехольчиками для айфона.
Есть у меня друг один, кодить сразу стал на RoR, использует MongoDB… Впрочем, не буду о грустном. Отсеивайте «модные» тренды, если о чем-то постоянно везде говорят — это не значит, что эта вещь Вам подходит.
За время работы с самыми разнообразными данными (среди них и бигдата, чего уж там) — выделил для себя 3 отлично зарекомендовавших себя инструмента: Postgres, Redis, Cassandra. Каждый из них отлично подходит к своему кругу задач. И больше ничего не надо. Да, может быть какая-нибудь там lightningDB и показывала производительность чуть больше Редиса, но возиться с ней, ловить ее баги, переписывать на нее код — нет, спасибо, не надо.
Программист должен быть немного консерватором, и уж точно не должен гоняться за новомодными штучками как девушка за чехольчиками для айфона.
Есть у меня друг один, кодить сразу стал на RoR, использует MongoDB… Впрочем, не буду о грустном. Отсеивайте «модные» тренды, если о чем-то постоянно везде говорят — это не значит, что эта вещь Вам подходит.
За время работы с самыми разнообразными данными (среди них и бигдата, чего уж там) — выделил для себя 3 отлично зарекомендовавших себя инструмента: Postgres, Redis, Cassandra. Каждый из них отлично подходит к своему кругу задач. И больше ничего не надо. Да, может быть какая-нибудь там lightningDB и показывала производительность чуть больше Редиса, но возиться с ней, ловить ее баги, переписывать на нее код — нет, спасибо, не надо.
всю эту новомодную шумиху нужно жестко отсеивать.
Есть у меня друг один, кодить сразу стал на RoR, использует MongoDB… Впрочем, не буду о грустном. Отсеивайте «модные» тренды…
… выделил для себя 3 отлично зарекомендовавших себя инструмента: Postgres, Redis, Cassandra.
MongoDB такая-же «новомодная» как и Redis, Cassandra.
Ок, оставим только «модная». Вокруг Монго куча шума и пиара (понятно почему). По факту же у нас простейшие селекты на миллиард записей работали очень долго, по сравнению с Кассандрой. С записью дела обстоят настолько плохо, что просто диву даешься, как такое кто-то может всерьез использовать для чего-то иного, кроме простенького сайта.
Почему вокруг Монго много шума и пиара?
Поэтому что она изначально создавалась как коммерческий продукт. Дальше создатели (тогда еще 10 gen) увидели, что профит они так не получат, и решили зарабатывать на поддержке и (возможно) SaaS. Посмотрите стоимость Enterprise Subscription у них на сайте.
Подобным путем кстати движутся и MemSQL. Только у Монги получилось лучше — видимо, пиарщики получше сработали.
Бизнес-модель здесь до безумия проста — подсадим всех на свой продукт, а потом будем продавать саппорт, раз уж продавать продукт не получается. 10 gen решили не нацеливаться на корпоративный сегмент, где живет Oracle, а захватить толпу. Толпа всегда больше, чем bloody enterprise, поэтому отсюда такая популярность Монги.
Кстати, примечательный факт — 10 gen переименовались в MongoDB Inc. Думаю, очевидно, что весь бизнес этой компании построен вокруг одного-единственного продукта. И было бы наивно думать, что они не стимулируют искусственно спрос — ведь даже переименование компании призвано увеличить узнаваемость бренда вообще и компании в частности.
Ну а создатели остальных NoSQL-баз данных либо хуже пиарятся, либо не заинтересованы в бизнесе вообще, либо не успели вовремя занять нишу — и теперь там сидит Монга (до поры до времени).
Вердикт: у 10 gen (называю их так по привычке) хорошие пиарщики, жаль, что они не пишут код.
Подобным путем кстати движутся и MemSQL. Только у Монги получилось лучше — видимо, пиарщики получше сработали.
Бизнес-модель здесь до безумия проста — подсадим всех на свой продукт, а потом будем продавать саппорт, раз уж продавать продукт не получается. 10 gen решили не нацеливаться на корпоративный сегмент, где живет Oracle, а захватить толпу. Толпа всегда больше, чем bloody enterprise, поэтому отсюда такая популярность Монги.
Кстати, примечательный факт — 10 gen переименовались в MongoDB Inc. Думаю, очевидно, что весь бизнес этой компании построен вокруг одного-единственного продукта. И было бы наивно думать, что они не стимулируют искусственно спрос — ведь даже переименование компании призвано увеличить узнаваемость бренда вообще и компании в частности.
Ну а создатели остальных NoSQL-баз данных либо хуже пиарятся, либо не заинтересованы в бизнесе вообще, либо не успели вовремя занять нишу — и теперь там сидит Монга (до поры до времени).
Вердикт: у 10 gen (называю их так по привычке) хорошие пиарщики, жаль, что они не пишут код.
Чуть менее чем за всеми DB с этой странички nosql-database.org/ стоит компания одного продукта, которая предлагает платную поддержку и обучение. Я сам сейчас работаю в такой же компании :) Так что видимо у Монго и правда очень хорошие пиарщики, раз о ней говорят, а о других — нет.
И вот уже кто-то возвращается к Постгресу с его частичной поддержкой JSON…
Кстати, в PostgreSQL 9.4 разработали JSONB который вполне по скорости может конкурировать с монго, таким образом получая преимущества обоих БД.
Разнообразие и конкуренция это всегда хорошо, но до продакшена тут невероятно далеко
Сообщество Хабрахабра, я взываю к тебе!
Хочу найти хорошую СУБД со свойствами SQLite (бессерверность, однофайловость), но со вводом и выводом объектов JavaScript и с возможностью выборки по полям и подполям их.
Пока только NeDB знаю для этой цели и отчасти PouchDB ещё.
Возможно, мне поможет ORM для Node.js поверх SQLite, но тогда что это за ORM?
Если кто знает — порекомендуйте.
Хочу найти хорошую СУБД со свойствами SQLite (бессерверность, однофайловость), но со вводом и выводом объектов JavaScript и с возможностью выборки по полям и подполям их.
Пока только NeDB знаю для этой цели и отчасти PouchDB ещё.
Возможно, мне поможет ORM для Node.js поверх SQLite, но тогда что это за ORM?
Если кто знает — порекомендуйте.
однофайловостьдвухфайловость же…
нужно взять SQLite раз он подходит и написать скрипт/программу которая раскладывает свойства жаваскриптовых объектов на таблицу связанную саму с собой (т.е. дерево). Делается такое за неделю со всеми тестами и проверками на рабочих обхёмах данных и в сходном с рабочим окружении.
Делал так не раз.
Делал так не раз.
Довольно противоречивые требования. Обычно, это встраиваемо-интегрированные БД оптимизированные на производительность, где даже наличие поддержки SQL запросов недопустимый жир, а тут раз и JavaScript в качестве интерфейса ))
Sign up to leave a comment.
Долой оковы MongoDB