TokuMX for MongoDB. С перламутровыми пуговицами.

Приходит заказчик и говорит: а теперь сделайте мне, пожалуйста, отчет не такой, а воооот такой...

Так что, SQL точно не нужен?

не понимаю я, как люди умудряются сравнивать key-value хранилища с реляционными? это такая фанатичность или просто неграмотность?

плюсую первых двух комментаторов

Toku

И что там с патентами токутека? Ждать повестки в суд, или сразу отчисления выплачивать?

А, всё ясно: «TokuMX is free for evaluation and for development purposes.»

Ну теперь sql точно не нужен, я уверен

тебе не нужен?

Пф. Map Reduce. Хоть даже инкрементальный.

Ах да, не модно. MongoDB Aggregation Framework. Там операции на сиплюсплюшечке оптимально запилены. MapReduce просто на JS гоняет по базе

Пф. Map Reduce. Хоть даже инкрементальный.

То есть от декларативного языка уходим в пещеры императивного, с мамонтами и наскальными рисунками? Дааааа...

сравнивать key-value хранилища с реляционными?

С каких пор MongoDB стала key-value хранилищем? А так да, с комментом согласен, реляционным БД далеко до документо-ориентированных. И нечего их сравнивать.

Сорцы они зарелизили под GPLv2. Коммунити эдишен вроде бесплатный, продают поддержку, как монга. И тулзу горячего бекапа.

Про патенты на алгоритм сам не понял.

Документацию о проекциях прочитать не осилили, перед тем как высказаться :) ?

Из синхронной выборки во время чтения переходим в асинхронную в фоне. Это раз.

И еще: map и reduce это императивщина? Ну тогда я уже не знаю... Чистые лямбды, выполняющиеся над коллекциями, получая иммутабельные данные и возвращая иммутабельные - это императивщина?

Я думаю имелась ввиду возможность сделать join, groupBy и подобные фичи, которые делаются MapReduce или Aggregation Framework

а медики, во дуралеи, статистику sqlями обрабатывают, в 21 веке-то. Надо им про монго-бонго полечить.

Причем тут медики и причем тут у кого что там работает нормально. Никто никогда не говорил что SQL не работает.

Кстати, у медиков база хотя бы на 10-20 машин распределена? Сколько терабайт? Запросов в секунду (ну этих, с joinами)?

Ну пост-то о фрактальных индексах, там хранилище под мускуль тоже есть. А чего себе думали те, кто прочитал только последнюю строчку - без разницы.

Причем тут медики и причем тут у кого что там работает нормально. Никто никогда не говорил что SQL не работает.

Ты. Сказал. В первом посте. Что SQL наконец не нужен. Очень даже категорически сказал.

Я предлагаю пойти к фармацевтам и исследователям от медицины и полечить им, что SQL не нужен. Можешь еще википедии рассказать, что они лохи, у них же ж MySQL, надо монго, оно ведь такое крутое. Я уж не говорю про, ужос-ужос, магазин амазона.

А твои терабайты сайтиков о котиках и впрямь не нужны.

Не, я впрямь не понимаю. Каждый второй, даже каждый первый гнилой стартап кричит, что у него миллионы пользователей, терабайты данных, дюжины шардов. Да откуда они столько людей в пользователи берут и терабайты данных генерируют, если о них и не слышал-то никто?

Ну пост-то о фрактальных индексах, там хранилище под мускуль тоже есть.

Ну, пока FDW для постгреса не сделают, мне это неинтересно.
А как там с транзакциями и целостностью? Информацию о деньгах уже можно хранить?

Кстати, у медиков база хотя бы на 10-20 машин распределена? Сколько терабайт? Запросов в секунду (ну этих, с joinами)?

У медиков OLAP, а не OLTP.

CTRL+F транза

Ты. Сказал. В первом посте. Что SQL наконец не нужен. Очень даже категорически сказал.

Ни за что. Нужен же.

Иногда твой стартап настолько лоховской и ненужный, что сервер настолько ущербный, что кроме как MapReduceами вообще ничего посчитать нельзя. Любой join его ставит в ступор.

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

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

А триггеры не могут?

Я так понимаю новые view тоже триггерами будете строить? Или все же набором разных костылей c циклами for в триггерах, переизобретая императивный и одноядерный MapReduce? При всем том что это не единственная функция MapReduce

Для больших обработок будет масштабироваться на много машин?

Иногда твой стартап настолько лоховской и ненужный, что сервер настолько ущербный, что

...ты берешь и ставишь 24 ущербных сервера с овердохрена RAM, чтобы у тебя монгокластер (или riak, или вставь свое) вообще приемлемо работал. А потом сам, руцями, выполняешь работу оптимизатора запросов, указывая, где какой индекс заюзать, чтобы оно еще и не тормозило.

Эта низкоуровневая возня происходит в то время, как RDBMS победно шагают к большой кнопки «Сделай все зашибись».

Я так понимаю новые view тоже триггерами будете строить?

В postgresql 9.3 материализованные вьюхи таки будут.

Для больших обработок будет масштабироваться на много машин?

Как там — лоховской стартап и его ущербный сервер, который не может вьюху в реалтайме построить? Где там много машин? Определись уже.

Есть одновременно лоховской сервер, в котором более эффективно строить view один раз и по-тихоньку его обновлять. И есть отдельно кластер машин, в котором joinы гонять вообще не айс

Это может указывать только на разброд и шатание в менеджменте затрат

В разных никак не связанных с друг другом проектах разных компаний например. Я описал две ситуации когда алгоритмически MapReduce эффективнее. Это не отменяет нужности SQL и даже самых упоротых joinов