Три проблемы MongoDB

Не скажу тут ничего нового, но хоть самому себе окончательно сформулирую причины, по которым отношусь к MongoDB с большой настороженностью. Раньше уже писал (тут), но за месяцы эксплуатации с чем-то смирился, на что-то забил, а оставшееся стало важнее.

Во-первых, дисциплину схемы данных поддерживать крайне сложно. Разработчики должны постоянно помнить, что это не RDBMS, потому десятки связанных «внешними ключами» коллекций могут решить тактическую задачу, но в стратегической перспективе вы всё сделаете неправильно (особенно с учётом пока ещё отсутствия multi-document transactions, но в 4.x вроде запилят).
Фигня в том, что так или иначе, если вы не делаете простое или специфическое приложение, вы всё равно однажды скатитесь ровно к тем самым десяткам коллекций, что в MongoDB чревато — механизмы проверки целостности данных в зачаточном состоянии. Конечно, допускаю, что вас может оставить равнодушным потенциал продолбать связность чего-то вроде клиент-счёт, но обычно это разработчиков тревожит.
Соответственно, у вас всего один вариант хранить сложные данные: огромные документы с большим уровнем вложенности, в которых всё-всё. Казалось бы, ну и ладно, это же хорошо, это вот прям MongoDB way! Не-а, переходим к следующим пунктам.

Во-вторых, механизм локов. Реально проблема, когда дело доходит до лока на уровне документа (почти всегда). Если кратко без нюансов и минимально для понимания, во время изменения документ залочен целиком.
Представим, что вам хватило мудрости создать документ «дом». В котором «квартиры». В которых «жильцы». Если ваш сервис раз в час переписывает «дом» целиком, жить можно. Если «дом» меняется несколькими сервисами в десятки потоков из разных источников… Пока вы меняете семейный статус Петрова, запись рождения Иванова и удаление Сидорова из пятой квартиры будут ждать в очереди.
На графиках очень красиво выглядят пики, когда звёзды сходятся и при [условно] 100RPS на «дом» последние изменения накатываются через 10 секунд, например. Шутки шутками, но т.к. такие лаги аукаются во всём остальном, становится грустно.

В-третьих, как ни странно, но у MongoDB очень бедный язык запросов внутри документов. Они чуть ли не в каждом релизе улучшают и дополняют, но если вам надо получить квартиры, в которых за последние пять лет произошло возгорание на кухне, в котором участвовал Фёдоров с условной судимостью… Такое стоит неоднократно пережить на собственном опыте.
Зачастую вам проще просто найти «дом», вытащить его целиком и вне MongoDB пройтись по документу. Соответственно, получаем дополнительную нагрузку что на базу, что на код. Не ок.

Потому совет всё тот же: сначала делайте сервис на RDBMS. MySQL и PostgreSQL давно уже взрослые и крепкие базы. Когда сервис заработает, поживёт и вам станет яснее реальная нагрузка и вообще вектор развития, тогда вы сможете достаточно просто мигрировать на MongoDB. Вот мигрировать с MongoDB на RDBMS врагу не пожелаю.
При всём этом MongoDB неплохая база, если использовать её правильно. Плохо, что использовать её неправильно слишком легко.

Три проблемы MongoDB: 2 комментария

    • Стараюсь писать по опыту, а Rabbit мы почти не используем, потому ничего внятного о нём сказать не могу.

Добавить комментарий