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

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

Mongo fan

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

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

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

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

Ваша оценка: Нет Средняя оценка: 3.7 (3 votes)
a

Это ж получается, если мы монгу в ceph засунем, то получим и в скорости профит.
А мускулы будут сосать (не масштабируются фактически, исключение — галера).

Ваша оценка: Нет
11
pomodor

А все ли задачи подразумевают необходимость масштабирования? Для обычного сайта MySQL с MYISAM — самое то.

Ваша оценка: Нет
a

Почему вы никогда не должны говорить «никогда»
habrahabr.ru/post/243431/

Ваша оценка: Нет
11
pomodor

Там в каментах автора креатива прищучили. :) По делу только упоминание такой штуки, как 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});

Получается, изначально используем Монгу из-за простоты и удобства, а на практике «простота» заканчивается вот такими шифрограммами.

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.
Linux I класса
Linux II класса
Linux III класса
Счетчики
  • Самый популярный сайт о Linux и Windows 10
О Либератуме

Liberatum — это новости мира дистрибутивов Linux, обзоры, сборки, блоги, а также лучший сайт об Ubuntu*.