Подводные камни MongoDB

http://hackingdistributed.com/2013/01/29/mongo-ft/

А если чиста поржать, то https://twitter.com/mongodbfacts

(Хотя там тоже можно откопать ссылки на нормальные источники)

Старенькое. Но я вот доки посмотрел акутальные.

Если запилить journaled на несколько машин, то подтверждение прийдет после записи в журнал primary. Если primary рухнет, то что, записи не было?

Не очень понял вопрос.

journaled на несколько машин

Что значит «на несколько машин»? Имеется в виду replicaSet?

Если primary рухнет, то что, записи не было?

Запись была. На primary она есть в журнале. Если тебе нужно подтверждение от secondary, то это тоже есть. В случае, если случился конфликт, есть механим rollback.

Да, насчет историй неуспеха.

Отсутствие транзакций и прочих двухфазных коммитов: из этого обстоятельства следует вывод о наличии стальных яиц у тех, кто держит в монге данные, связанные с деньгами. На мой взгляд, «неуспех» случается тогда, когда инструмент выбирается не под задачу.

MongoDB - отличный продукт, но ни в коем случае не является серебряной пулей.

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

Тот, кто держит деньги в Монге, имеет не стальные яйца, а медный лоб :)

Ну вот есть репликасет. Репликация на 3 узла. Я включаю запись в журнал и делаю writeConcern например на 3 или на majority.

Как я понял в журнал оно запишет на primary, а на остальных нет.

Какие тут опасные сценарии падения?

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

на остальных нет.

Не совсем так: {«j» : «true»} говорит о том, что мы будем считать запись удачной, если получим подтверждение от primary о записи в журнал. На остальных - если там включено журналирование - запись тоже произойдет, но по таймеру.

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

Какие тут опасные сценарии падения?

Любой сценарий падения без ACID потенциально опасен. Да и ACID не панацея... Хотя, большинство проблем, с которыми я сталкивался, работая с mongodb, пока что сводились к классическому «ССЗБ».

В случае {w : 3} при падении одной ноды, mongodb придётся ждать, пока нода не поднимется. Думаю, это почти всегда плохая идея для кластера из трёх нод.

В случае с majority появляется гарантия того, что данные попали к двум другим нодам. Это само по себе не значит, что данные уже попали на диски, но уже весьма надёжно. Тут надо заметить, что если в replicaSet из трёх нод есть arbiter, то majority может тебе принести несчастья: если одна нода лежит, арбитер никогда не подтвердит успешность и монга опять будет ждать, и ждать, и ждать...

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

Но в целом, если руки из жопы, то с монгой будут проблемы, да. Многочисленные статьи набигаторов c сиквеля, которые хотят от монги сиквеля, это подтверждают :)

Там в индексах работает далеко не всё, к чему вы привыкли на сиквеле. Они это постепенно выправляют, но иногда читая про их очередной «успех» я выпадаю в осадок.

Для range запросов в композитном индексе поле диапазона должно быть последним. Может cardinality неслабо просесть. Но кластеризацию наверное иначе не сделать.

Всякие там проекции/агрегации и т.п. с индексами считайте что вообще не работают.

В общем, смотрите какие вам выборки/индексы будут нужны. Оптимизатор на не примитивных условиях там лажает.

Если запросы простые, то можно посмотреть вот это http://www.tokutek.com/products/tokumx-for-mongodb/ . Они типа для монги и сиквеля точат альтернативу btree индексам. Говорят, что получается круто, но мопед не мой.

Спасибо :)

Спасибо. Но если каждый запрос профилировать, а не просто сделал индекс, забыл и надеешься что он будет использоваться, то что там не так с индексами? У меня например с MySQL тоже не такой сильный опыт чтобы я от других баз ожидал такую же работу. Я бы доверял профилировщику и описанию использования индексов в конкретном запросе

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

Например условие ((a > 100) or (a < 90)) на монге хрен вы загоните в индекс. Вроде очевидная вещь, а не дай бог нарваться в середине проекта, когда половина запросов такие и ничего не поменять.

Профилируйте заранее, если до этого монгой не пользовались.

Например условие ((a > 100) or (a < 90)) на монге хрен вы загоните в индекс.

Два запроса?

А если там еще нужна сортировка и разбивка на страницы?

В общем, накостылировать всегда что-то можно. Просто надо иметь в виду, что есть косяки на range, а с 2 условиями range по 2 колонкам вообще вилы. Или когда range по одной колонке и сортировка по другой.

Или когда range по одной колонке и сортировка по другой.

Тогда нужен специальный индекс для такой операции. И вот такой OR, да еще с сортировкой вероятнее если и работает в MySQL, то сортирует все равно на сервере ручками. Представь как это должно реализоваться.

Мускуль нормально сортирует. По индексу композитному. Монга не будет. Ну вот так вот, не умеет.

Я вас не отговариваю, просто объясняю разницу.

условие ((a > 100) or (a < 90)) на монге хрен вы загоните в индекс

Если я правильно понимаю, то на монге это обходится использованием aggregation framework и match в начале пайплайна. Документация утверждает, что в данном случае будет использоваться индекс:

db.col.aggregate([{ $match : {$or : [{ a : {$lt : 90} }, { a : {$gt : 100} }] } }]);

Проверил. Действительно, используется индекс. Пруф: https://gist.github.com/kdask/9208446.

Может подкрутили чего в планировщике, там немало тикетов висело на такие темы. Раньше был еще такой кейз:

(10 <= A <= 12) sort by B (индекс по A+B)

При то что работало (A in [10,11,12]) sort by B.

Или например в (A = 5) & (B != 3) & (C = 8) оно метит B как uncountable и напрочь отказывается юзать coverage index (A+B+C). Хотя при хорошей cardinality A это явно выгоднее, чем диск колбасить.

Честно говоря, релизы за последние пол года не отслеживал.

Скорее всего у меня был кейз когда range + sort по разным полям. Монга очень хочет, чтобы range был последним в индексе. Наверное поэтому в вашем примере косяков не вылезло. Давно уже ковырялся, сейчас не скажу точно.

Одно время (во времена <2.2) у монги не было поддержки булевых операций над данными, точнее было только «&». Это было несмешно.

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

Что касается транзакций и специфики асинхронности, то проблем не было. Книга «MongoDB в действии» от Кайла Бэнклера отлично покрывает возможности монги. Ну, а тем кто жаждет транзакций уже запилили TokuMX.

Эта неведомая фигня с JS случайно не однопоточность :) ?

Эта неведомая фигня с JS случайно не однопоточность :) ?

Нет. Это даже не проблема, т.к. для v8 с какой-то версии монго обещали это поправить (или уже поправили). У меня же не получилось сделать сервер-сайд логику, по типу PL/SQL. Давно было, не помню в чем затык был.

./mcon/connections.c:int mongo_connection_connect(char *host, int port, int timeout, char **error_message)
./mcon/connections.c:   tmp->socket = mongo_connection_connect(server_def->host, server_def->port, 1000, error_message);

Еще говорят ротация логов у них своя, с шашками и русалками

http://profyclub.ru/docs/167
Было уже?

Одна из самых больших проблем MondoDB – это блокировки и гранулярность блокировок. В моем личном списке недостатков у них вообще первое место. В MondoDB принята модель «1 писатель и много читателей». Причем «писатель» один не на документ или коллекцию, как во многих других БД, и даже не на базу данных. Он один на сервер. Сколько бы баз данных у нас на сервере ни было, только в одну коллекцию в данный момент может прийти запись.

Упал под стол

так было на заре. в нынешних версиях на запись лочится только коллекция в пределах реплики.

в 2.6 обещают выкатить http://docs.mongodb.org/master/core/index-intersection/

Есть интересная «фича» если разворачивать монгу на 32 битных системах - при попытки вливания большого количества информации, база данных попросту падает на столько, что восстановить ее становится очень проблематично. Но это фишка исключительно 32 битных систем, на 64-х не наблюдается, да и в системных требованиях монги рекомендуется использовать 64х битные ОС.

Там 2 гигабайта предел. Но это надо быть совсем ССЗБ чтобы в нынешнее время ставить 32-битную монгу.

в нынешнее время ставить 32-битную монгу.

Ну почму бы и нет. 32-битные системы в принципе не плохо разворачивать на всяких слабеньких VDS-ках с ограниченным объемом памяти, с целью сэкономить эту самую память.

Вообще провел пару экспериментов над монгой, на предмет разворачивания на слабженьких серверах, получилось так что монга на 32-битная системе на слабой вдс с 400мб оперативки и 6гб памяти - ломалась после заливания большого объема данных. А вот монга на 64-битной системе с теми же параметрами вполне себе выдерживала гораздо большие объемы данных и при этом не ломалась - ограничение было только в доступной памяти на жестком диске, размер оперативки имел значение только для скорости работы.

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

Монга претендует на простоту миграции с сиквеля. А это значит, что все вещи, перечисленные в главе мускульного руководства по оптимизации индексов должны работать сразу. Или хотя бы с принудительными хинтами.

Ну просто возникает вопрос, зачем при таком кроилове вообще выбирать монгу. IMHO 32-битную монгу давно пока выкинуть, или объявить что она не для продакшена.

На самом деле да, 32 битную монгу смысла использовать вобщем-то и нет. Только вот остается вопросом на кой фиг 32битную монгу в репозитории пихают.

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

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