Стоит ли использовать MongDB вместо PostgreSQL?

Question

[Заур Ашурбеков]

Здравствуй, Тостер!
Я до этого всегда работал только с PostgreSQL. Но недавно встала задача, где нужно хранить сотни различных структур данных. У структуры может быть от 1 до ~100 элементов, любых стандартных типов. Существует высокая вероятность того, что запись и чтение данных может происходить одновременно. Так же структура может меняться в течении её жизни и это не должно приводить к долгим тормозам базы.
Так вот, почитав описание MongoDB, я было обрадовался - вот оно счастье! Но когда дошел до отзывов... Там так часто ругаются на Mongo, особенно в крупных проектах, что у меня появились серьезные сомнения. Стоит ли мне использовать MongoDB или все же старый добрый PostgreSQL со связями?

Answer 1

[lega]

Там так часто ругаются на Mongo, особенно в крупных проектах, что у меня появились серьезные сомнения.

Это просто инструмент который имеет свои преимущества и не достатки, они либо не умеют его готовить, либо выбрали не правильный инструмент.

А вот в крупных компаниях оно успешно используется: Google, Yandex, SAP, Facebook, Cisco, Adobe...
https://www.mongodb.com/who-uses-mongodb

Так же umputun и @bobuk в одном из своих подкастов сделали вывод, что монги хватает на 95%* (веб) проектов.

Вы можете сделать мини-проект на монге, что-б пощупать и понять подходит оно или нет.

Comments

[Заур Ашурбеков]

"Вы можете сделать мини-проект на монге, что-б пощупать и понять подходит оно или нет"
Я, скорее всего, так и сделаю.

Answer 2

[Сергей Протько]

Не совсем. Слишком велики концептуальные различия.

Там так часто ругаются на Mongo, особенно в крупных проектах, что у меня появились серьезные сомнения.

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

В целом по вашему описанию монга подходит хорошо, но рекомендую все же более чательно почитать об агрегатах в контексте монги.

Стоит ли мне использовать MongoDB или все же старый добрый PostgreSQL со связями?

Есть еще вариант. С версии 9.4 postgresql тоже умеет jsonb, хоть и не так удобно.

Comments

[sim3x]

яндекс знач не умеет
ооок

[Сергей Протько]

sim3x: можете уточнить?

[sim3x]

Сергей Протько:
https://events.yandex.ru/lib/talks/2325/ описание проблем при работе с _большой_ базой

ИМО список костылей слишком велик

[Сергей Протько]

sim3x: никогда не ориентируйтесь на _большие_ проекты. Я был бы рад если бы у меня был проект схожих масштабов что бы надо было пилить такие кастыли.

[Сергей Протько]

sim3x: в целом же из их описания я бы брал какую-нибудь касандру.

Answer 3

[terrier]

Существует высокая вероятность того, что запись и чтение данных может происходить одновременно.

Ну и как вам понравится уровень изоляции Read Uncommited в таком случае?

Плюс к тому, атомарность гарантируется только тогда, когда вы в одной операции обращаетесь только к одному документу - иначе попрощайтесь с транзакциями. Гарантировать, что это условие будет соблюдаться абсолютно всегда в будущем системы - это очень сильно.

Про Durability в MongoDB можно даже не начинать, как говорится "Вы вполне можете использовать MongoDB, если ваши данные не очень ценны. С другой стороны, если ваши данные не очень ценны, вы также можете писать их в  /dev/null".

Действительно jsonb постгресовый оптимальный выход в данном случае

Comments

[lega]

> Про Durability в MongoDB можно даже не начинать,

Это чушь, правильно настроенная монга может быть ещё надежней чем postgre/mysql

[terrier]

lega: Так раскройте нам секрет правильной настройки монги, так чтобы надежнее традиционных RDBMS. Будет полезно и нам и разработчики mysql/postgresql , уверен, с удовольствием почитают, они всегда рады узнать новые способы повышения надёжности.

[Илья Шатохин]

terrier: глупый холливар, нет у монги проблем с надежностью. И jsonb точно не замена монги.

[Сергей Протько]

terrier почитайте про агрегаты транзакций и задумайтесь, нужен ли механизм транзакций если вы оперировать в рамках одной бизнес транзакции должны всегда только независимыми документами. Атомарность в этом случае нам гарантирована, а мы можем строить любую структуру, котоаря нам вздумается.

Проблемы начинаются только тогда, когда появляются связи между различными агрегатами транзакций. Это означает, что мы не верно выделили агргегаты, или же просто монга тут не подходит (графы например).

[terrier]

Илья Шатохин:
>> нет у монги проблем с надежностью.

Ну, давайте посмотрим вместе
https://jira.mongodb.org/browse/SERVER-22062 - захотели построить индекс в фоновом режиме? Время зависать!
https://jira.mongodb.org/browse/SERVER-21782 - "On a daily basis we have to restart MongoDB nodes (secondaries and primary) because performance degrades dramatically." Бедняги.
https://jira.mongodb.org/browse/SERVER-21191 - Сервер работал-работал, а потом неожиданно упал.
https://jira.mongodb.org/browse/SERVER-18908 - Реплики никогда не догонят праймари
https://jira.mongodb.org/browse/SERVER-14214 - выбрали нового лидера, но все пошло не так ...
https://jira.mongodb.org/browse/SERVER-14139 - Disk failure on one node can (eventually) block a whole cluster. Nuff said
https://jira.mongodb.org/browse/SERVER-22431 - любителям windows дополнительные падения в подарок.

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

[Илья Шатохин]

terrier: Завтра скажу ребятам, чтобы сворачивали наши хайлоады, а то аналитик с тостера мне глаза открыл, что мы все делаем не так и у нас все должно падать и зависать при таких нагрузках. Заодно надо в Google и Facebook написать, чтобы те тоже закрывали свои высокопроизводительные решения на монге. Падает-с же там у кого-то в жире.

[terrier]

Илья Шатохин: Да, спасибо, примерно такого уровня ответ я и ожидал.

[Илья Шатохин]

terrier: да всегда пожалуйста. У меня нет желания что-то там доказывать анонимам в интернете, это я переболел еще в период джуниорства. Ну и как бы еще раз ссылка, которую ниже дал lega - https://www.mongodb.com/who-uses-mongodb

Answer 4

[sim3x]

Изменения структуры моделей уже давно не проблема тк все используют миграции.
Или на уровне фремворка - тогда получаем консистентность по коду и данным
или на уровне СУБД - в виде набора sql скриптов для изменения БД

Comments

[Заур Ашурбеков]

там слишком много таблиц получится (сотни, тысячи). причем в некоторых только по одной, две записи будут.

[sim3x]

Заур Ашурбеков: похоже на неправильнуюб структуру БД

[Заур Ашурбеков]

sim3x: это я про тот вариант, если все структуры в виде таблиц создавать, что, конечно, я делать не буду))