Когда использовать MongoDB
Недавно я опробовал MongoDB и пришел в восторг от удобства работы с ней. Чуть позже я столкнулся с одним из минусов Монги — относительной медлительностью и прожорливостью. Потом оказалось, что сама концепция хранения данных в документальной форме редко совместима с реальными задачами. Так что же, не использовать совсем?
Я попытался применить MongoDB в нескольких проектах и могу сделать следующие субъективные выводы:
1. Монга конечно же не является заменой MySQL/PostgreSQL. Во-первых, MySQL намного быстрее. По крайней мере, на относительно небольших объемах данных. Не знаю, корректно ли сравнивать скорость работы табличной и документной СУБД, но приложением-то будут пользоваться юзеры и им пофиг по какой причине им приходится дольше ждать. Поэтому, сравнивать производительность все же приходится и Монга проигрывает очень сильно, даже с отключенным журналированием и всякими хитрыми индексами. Хотя, разработчики угрожают многократным ускорением сразу всего в свежей версии 3.0.
Во-вторых, документ-ориентированность MongoDB очень удобна, но только до тех пор, пока разработка не отклоняется от составленного вами проекта. Но заказчик может попросить вас привинтить небольшую фичу, из-за которой вся стройная архитектура приложения в миг превратится в урода. Да, я знаю, что требования должны жестко фиксироваться еще до проектирования, но иногда проще согласиться и за час внести изменения, чем неделю сраться с заказчиком, который потом к тебе больше не обратится. Так вот, табличная форма хранения данных традиционных СУБД позволяет относительно безболезненно вносить изменения — достаточно переписать несколько запросов, а структура таблиц и данные почти не меняются. В этом сила нормализации. А вот документ — это совсем негибкая сущность. Реальный пример негибкости здесь.
2. Как основную СУБД я использовать Монгу не стал бы совершенно точно, а вот как вспомогательную в некоторых случаях очень даже удобно. Пример, с которым я столкнулся: надо загрузить несколько лент новостей, распарсить их, загрузить полный текст, вытянуть данные из текста и обработать. Первоначально структура данных неизвестна, поэтому отсутствие у Монги необходимости описывать схему базы данных является огромным преимуществом. Да и теги очень удобно хранить в виде обычного массива прямо в документе. Таким образом, промежуточные данные обслуживаются Монгой, обработанные потом переносятся в MySQL, а временные коллекции грохаются. Профит!
Комментарии
Чингачгук
13 марта, 2015 - 08:15
Это ж получается, если мы монгу в ceph засунем, то получим и в скорости профит.
А мускулы будут сосать (не масштабируются фактически, исключение — галера).
pomodor
13 марта, 2015 - 19:11
А все ли задачи подразумевают необходимость масштабирования? Для обычного сайта MySQL с MYISAM — самое то.
Чингачгук
13 марта, 2015 - 10:27
Почему вы никогда не должны говорить «никогда»
habrahabr.ru/post/243431/
pomodor
13 марта, 2015 - 19:23
Там в каментах автора креатива прищучили. :) По делу только упоминание такой штуки, как Aggregation. В принципе, штука очень хорошая. Если освоить не самый очевидный синтаксис, то куча проблем снимается. Но синтаксис это нечто:
db.zoo.aggregate({$project: {name: 1, _id: 0, "staff.like": 1}}, {$unwind: "$staff.like"}, {$project: {_id: 0, name: "$staff.like", count: {$add: [1]}}}, {$group: {_id: "$name", num: {$sum: "$count"}}}, {$sort: {num: -1}}, {$limit: 1});
Получается, изначально используем Монгу из-за простоты и удобства, а на практике «простота» заканчивается вот такими шифрограммами.
Комментировать