В последнее время появилось много критики Монго. С чем связано это?

Question

[Антон Медведев]

В последнее время появилось много критики Монго. С чем связано это? Раньше она всем нравилась, а сейчас столько негатива о не слышу.

Comments

[Антон Медведев]

А что вы скажите о CouchDB?

Answer 1

[baadf00d]

эйфория от новых возможностей прошла и вскрылись недостатки, на мой взгляд основные их них:
— Слабая производительность на 1-серверной БД. Особенно заметно на map-reduce по данным, которые полностью влезли в память.
— Особенности документо-ориентированной структуры. Многие переходили с табличных БД и тут понеслась: сначала радость, что не надо возиться со структурой, а потом расплата — в одной коллекции куча разных объектов и приложение регулярно читает из вроде бы известной коллекции что-то для себя неожиданное (очень старые объекты, некорректно измененные и т.п.).
— Целостность данных. Кто-то привык, что БД контролирует этот вопрос, вешают констрейнты и ловят ошибки в логе в случае какой промашки по части бизнес-логики. Монга же ничего такого сама не контролирует, ну и получаются внутри БД ссылки на объекты, которых нет.
— Отсутствие полноценных транзакций. Те, кто бросились все хранить в монге с ужасом поняли, что для биллинга нужно что-то другое. (должен оговориться, что не все пока поняли)

По моему мнению отказаться от классической реляционной БД в пользу монги может позволить далеко не каждый проект. Если перетаскивать какой-нибудь небольшой интернет-магазин, то с бОльшей вероятностью это принесет боль и страдание нежели ожидаемый профит. Эффективным решением будет параллельное использование монги и реляционной БД, но чтобы это имело смысл — проект должен быть соответствующих размеров. Для небольшого проекта городить такой огород контрпродуктивно.

PS Мое мнение основано на годичном опыте неплотной работы с монгой, опыт работы с реляционными БД — примерно 10 лет.

Comments

[Дмитрий Зайцев]

По моему опыту работы с монго, она прекрасно годится как замена MySQL на небольших и средних веб-проектах, которые пишутся с чистого листа, а не переписываются. Из-за своей schema-less. За целостностью данных обычно помогает следить ODM. Без транзакций в этих проектах можно обойтись, ведь с MyISM как-то обходились, а тут у монги есть атомарные операции и все что меняется в одном документе — происходит атомарно, т.е. по сути в одной «транзакции».

[baadf00d]

У нас видимо очень разный опыт. Что это за проект где хватает MyISAM? Блог, форум, CMS — да, там хватит. Любого рода рекламная сеть, магазин или хоть что-то с биллингом или учетом товаров/остатков — нет.
Ну вот представьте, у вас есть магазин, в нем, кроме прочего, вы описываете 3 сущности: покупатель, продавец, платеж (или перевод/транзакция/проводка — кому как нравится). Вам нужно атомарно проверить достаточность средств у покупателя, перенести деньги из кармана покупателя в карман продавца и изменить статус платежа. Как вы это будете делать на монге? Ну ладно, засунуть оба кармана в одну коллекцию еще можно, но что делать с платежами?
Предположим, что вы дошли до того, чтобы конкурентно создавать задания на перевод и обрабатывать все платежи из одного треда — ошибки вроде бы пропали… до первой внезапной остановки сервера.

Про целостность не понял, что такое ODM? Маппилка пхп-объектов в монгу? Причем тут пхп? И причем тут маппинг? Вот вы замаппили объекты юзеров и ролей по коллекциям. После этого удаляете объект роль из базы, кто за вас будет проверять, что к этой роли привязаны юзеры? Проблема-то возникает не здесь, а дальше. С юзерами и ролями, допустим, вы все предусмотрели. Но вот прошло время, проект развивается и вы добавляете новую сущность в БД, которая так же привязана к ролям. Кто из разработчиков, добавляющих эту сущность, сам вспомнит, что надо модифицировать проверку перед удалением роли? Конечно, о нарушении целостности БД вы когда-нибудь скорее всего узнаете, и может как раз ODM вам о ней первым в лог напишет… Но разве от это не шаг назад по сравнению с констрейнтами в реляционной БД?

Answer 2

[merlin-vrn]

Куча недалёких школьников решили, что это серебряная пуля, и стали пихать её туда и туда. А потом выяснилось, что как и любое другое решение, в котором функциональность заведомо ограничена (в данном случае, в пользу скорости), она оказалась совсем не универсальна, и скорость-то, как выяснилось, получается только в определённом, не особенно-то и широком классе задач. Зато неудобства от ограниченной функциональности проявляются везде.

Короче, куча тупой рекламы. От этой рекламы ощущения как от фразы — «давайте встроим в стульчак bluetooth — с ним любая вещь лучше».

Answer 3

[nekipelov]

Сначала все руководствовались слухами, а теперь собственным опытом? :-)

Лично я много раз расстраивался, используя mongo. Уже по коду первый версий видно, что БД пишется далеко не профессиональными программистами (ну а кому еще взбредет в голову переопределять стандартные C функции? пруф: github.com/mongodb/mongo/blob/v1.4/util/assert_util.h, github.com/mongodb/mongo/blob/v1.4/util/allocator.h). Но вроде бы, от версии к версии, с проблемами сталкиваемся все реже. Только вот наш продукт еще на этапе разработки, кто знает, что будет в реальной работе…

Comments

[Алексей Гусейнов]

Переопределение assert так, чтобы кидалось исключение вместо жесткой остановки программы как раз грамотное решение. В случае с серверами зачастую можно многие исключения обработать отметив текущий запрос как ошибочный и приступив к следующему. В случае непредвиденной ошибки сервер должен пытаться восстановиться, а не падать лапками к верху.функцию выделения памяти внешней библиотеке. И это как раз очень хорошо, что разработчики позаботились о корректном завершении процесса при нештатной ситуации.

Я нехочу сказать, что там все идеально, в mongo есть вещи, которые мне не нравятся, особенно сообщения об ошибках, но конкретно по этим двум пунктам вы не правы.

[nekipelov]

Ты уверен, что достаточно долго программируешь на C++, чтобы считать такой код грамотным?

1. Я говорю не о сервере, а о библиотеке BSON для работы с mongo.

2. Assert никогда не останавливает программу в случае release сборки. Это проверка утверждения, которая срабатывает только в отладочной сборке. Где ты видел, чтобы на сервере использовались отладочные сборки? Поэтому нормальная практика делать вот так:

assert( ptr != nullptr );
if( ptr ) 
{
    ... 
    // code
}

3. Это макрос. Поэтому он заменяет код не только в самом mongo, но и твой код, а также сторонний код, подключаемый после заголовочных файлов mongo. В лучшем случае сломает сборку. В худшем же твои проверки будут работать не только в отладочном режиме, что очень плохо.

Answer 4

[weirdan]

Перерекламировали.