Ну у нее сильный профит - шардинг по серверам из коробки. Работает «само». Многие к этой магии относятся с осторожностью и недоверием.

Зачем нужна Манга?

так правильнее :)

Зачем нужна Монга?

Чтобы не трахаццо с этими вашими формами нормальности и нелогичными не похожими на таблицы таблицами.

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

я смысла не вижу.

ковыряю OrientDB

Как там, кстати, китайская Hypertable поживает, которая Байдой финансируется?

Чтобы не трахаццо с этими вашими формами нормальности

Так уж и трахаться. С вики: «принципы нормализации — это формализованный здравый смысл». В точку прямо.

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

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

А вообще монга - УГ с точки зрения реализация. Репликация там прикручена кое-как, кеширование там уровня ОС. Есть аналоги, которые пытаются это пофиксить - rethinkdb, arangodb, но они пока поделки.

Что сейчас модно, молодёжно?

Монга.
А вот правильно сейчас, и всегда, «для каждой задачи инструмент... бла-бла-бла» (:

На сколько я понимаю mongodb очень удобна пока справляется с твоими задачами, но если она перестаёт с ними справляться то сделать с ней что-то (подтюнить что-бы справлялась) довольно трудно.
А ещё слышал такую умную мысль: монга опасна, так-как внушает пользователю уверенность в том что не нужно разбираться в базах данных.

Блин, чувак, по первому впечатлению Rethink - шикарен. А почему поделка? Думаешь таки не готов?

Думаю пока сырая, но это просто мнение, на практике я ее не пробовал.

Монга 1) Самая простая БД, проще реляционок 2) Автошардинг 3) MapReduce/AF 4) Consistent

А теперь поищем базу с такими же показателями.

Riak - key-value

Cassandra - нельзя заставить быть консистентной (они лгут что можно с помощью R+W>=N+1)

CouchDB - вундервафля с адовой моделью данных

RDMBS - автошардинг в жопе

HBase - геморов много с деплойментом

А если сравнить с rethinkdb, arangodb, orientdb?

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

кеширование там уровня ОС

Есть еще вариант: TokuMX
Там прикольная идея с Fractal tree

Нет. Вот, хотя бы активность в issues, отвечают на любой вопрос, даже самый тупой и актуальный только для тебя: https://github.com/rethinkdb/rethinkdb/issues?state=open

К тому же 8 миллионов инвестиций раунда A.

Cassandra - нельзя заставить быть консистентной

так это же фича. Нафига во Вконтактике или ЖЖ согласованность, чтобы публиковать нотариально заверенный скриншот страницы, и чтобы у всех он был один и тот же? Ну обновил юзер своё имя, в Воронеже оно сменится через три часа, а в Минске - через тридцать, ну и черт с ним.

зато Кассандра никогда не ляжет от типичной нагрузки и доса

HBase

вооот скаааажии.. Зачем они на любое слово делают (с)(тм)(r)? Захдишь на сайт Хадупа, а там «технологиями» вся глагне занята, и перед каждой (с)(тм)(r). И чем дальше - тем больше. Там даже методы и то бывают (с)(тм)(r)!

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

CouchBase?

Интересно было бы послушать реальную историю использования кассандры в качестве щита от ddos'а, хранением в ней картинок (меньше 64 мегабайтов). Но, наверное, это потребует что-то там менять в кишках самостоятельно :(

Поверь, большие блобы туда пихать - совсем не айс. man sstables + log structured merge tree. Оно будет работать очень грустно

Да я готов пользоваться ей в 90% сценариев всякой вебни. Но почему бы не дать людям заплатить небольшую цену в latency чтобы дать возможность работать с 10% сценариев на той же базе, ведь данные на column-family отлично ложатся.

Они уже сделали lightweight transactions на основе Paxos алгоритма, так вот почему бы не обьяснить по-человечески большими буквами приводит ли это к роллбекам при failed writes. Если да, то дело в шляпе - она может быть консистентна при R+W>=N+1. Если нет, то эти транзакции уж очень lightweight :)

Ну аргументы к HBase у тебя надуманые, ведь реально ее ругают за минимум 5 узлов в любом нормальном деплойменте и некую нериалтаймовость.

а я HBase дальше чем на хэлловорлдах не пользовался :3 Как раз из-за того, что от их ынтерпрайзности лютый баттхерт. Был один нормальный жирный диплоймент, в котором «руками не трогать» и всё

и некую нериалтаймовость.

как ты красиво сказал слово «тормоза»

Ну как сказать, это клон BigTable. А ее вообще выдрали из интигрированой инфраструктуры в единственном екземпляре. Опять же, для разработки в HBase все в полпинка подымается. Для говносайтиков конечно прийдется подымать жирный продакшн, но зачем HBase для говносайтиков

тормоза

Представь краулер. Просто неимоверное количество данных индексируется. Не важно как быстро ляжет в базу (в разумных пределах), но важно чтобы БД это проглотила. Нужна консистентность на некоторых задачах. Нужен column-family без вариантов. И да, нужно сканирование ренжей rowkey иногда. Нужен MapReduce. Выборка все равно не стучит прямо в HBase, все на кешах. Ну вот и смотри, тормоза это или нет

Собственно когда бенчмаркали последний раз, то Riak и MySQL Cluster быстро копытца откинули. Только HBase и Cassandra линейно масштабировались. Не помню что там с лейтенси, собственно за что некоторые ругают HBase, но общий throughput был на высоте и не оставал от кассандры

https://twitter.com/mongodbfacts/status/410150449623212032 и далее по @mongodbfacts. У mongodb очень большая ниша.

А что можете сказать о Tarantool? Костя Осипов на Highload++ очень доходчиво рассказывал про NoSQL.