Когда использовать MongoDB

Недавно я опробовал MongoDB и пришел в восторг от удобства работы с ней. Чуть позже я столкнулся с одним из минусов Монги — относительной медлительностью и прожорливостью. Потом оказалось, что сама концепция хранения данных в документальной форме редко совместима с реальными задачами. Так что же, не использовать совсем?

Я попытался применить MongoDB в нескольких проектах и могу сделать следующие субъективные выводы:

1. Монга конечно же не является заменой MySQL/PostgreSQL. Во-первых, MySQL намного быстрее. По крайней мере, на относительно небольших объемах данных. Не знаю, корректно ли сравнивать скорость работы табличной и документной СУБД, но приложением-то будут пользоваться юзеры и им пофиг по какой причине им приходится дольше ждать. Поэтому, сравнивать производительность все же приходится и Монга проигрывает очень сильно, даже с отключенным журналированием и всякими хитрыми индексами. Хотя, разработчики угрожают многократным ускорением сразу всего в свежей версии 3.0.

Во-вторых, документ-ориентированность MongoDB очень удобна, но только до тех пор, пока разработка не отклоняется от составленного вами проекта. Но заказчик может попросить вас привинтить небольшую фичу, из-за которой вся стройная архитектура приложения в миг превратится в урода. Да, я знаю, что требования должны жестко фиксироваться еще до проектирования, но иногда проще согласиться и за час внести изменения, чем неделю сраться с заказчиком, который потом к тебе больше не обратится. Так вот, табличная форма хранения данных традиционных СУБД позволяет относительно безболезненно вносить изменения — достаточно переписать несколько запросов, а структура таблиц и данные почти не меняются. В этом сила нормализации. А вот документ — это совсем негибкая сущность. Реальный пример негибкости здесь.

2. Как основную СУБД я использовать Монгу не стал бы совершенно точно, а вот как вспомогательную в некоторых случаях очень даже удобно. Пример, с которым я столкнулся: надо загрузить несколько лент новостей, распарсить их, загрузить полный текст, вытянуть данные из текста и обработать. Первоначально структура данных неизвестна, поэтому отсутствие у Монги необходимости описывать схему базы данных является огромным преимуществом. Да и теги очень удобно хранить в виде обычного массива прямо в документе. Таким образом, промежуточные данные обслуживаются Монгой, обработанные потом переносятся в MySQL, а временные коллекции грохаются. Профит!