Комментарии 22
Конечно, сравнение MongoDB и PostgreSQL, это как удава в попугаях измерять. Сильно уж разные СУБД для разных задач. Но как совсем база для начала изучения - может быть.
Это связано с тем, что данные денормализованы и не требуют дорогостоящих соединений между таблицами.
Денормализация денормализации рознь.
Есть кейсы, когда нормализация наоборот ускоряет манипуляции с данными.
Для монги главный фактор для использования: требуется дешевое горизонтальное масштабирование. Во всех остальных случаях: стоит подумать нужна ли реально монга, потому что потом будет больно с нее съезжать, т.к. честный ACID снимает кучу головняков, не только для "денежных" сервисов.
Одно из самых важных отличий -- простота обеспечения отказоустойчивости и шардирования. В MongoDB поддержка нескольких узлов есть "из коробки", а PostgreSQL же в этом плане -- конструктор "собери сам", вот вам встроенная поддержка репликации на основе WAL, а дальше сами.
Пулинг соединений, балансировка, failover, шардирование, логическая или физическая репликация -- всё выбери сам, настрой сам и борись с багами в сторонних утилитах тоже сам =)
В MongoDB официальная поддержка AСID появилась с версии v4 в 2018 году.
То ест до 4 версии, MongoDB не могла называться СУБД.
Атомарные модификаторы в MongoDB могут работать только с одним документом
А с 4 версии, она стала СУБД только на пол шишечки.
Я знаю что хейтить MongoDB модно (особенно тем, кто про неё читал в интернете "она теряет данные"), но её вполне можно было использовать примерно с версии 1.8.
А вы точно знаете, чем субд отличается от просто файлика на диске?
А вы как собираетесь оценивать точность моего знания? По тому, совпадает ли оно с вашим или нет? Беспроигрышный вариант! То что у вас невысокое мнение о MongoDB, по той или иной причине, не говорит ничего о её качестве и "настоящести". В нашем проекте (170млн запросов от клиентов в сутки) работает нормально, в разных ролях, и как основное хранилище, и как объектное хранилище, и как in-memory кэш и сервис очередей. Могла бы быть побыстрее в некоторых сценариях, ну тут уж куда деваться, что есть то есть.
А если ответить на ваш вопрос нейтрально, то всё зависит от требований. Даже "файлик на диске" может быть частью СУБД, на SQLite можете посмотреть например или на BerkeleyDB.
У вас видимо чисто интернете представление об этой СУБД, работаю с ней около 7 лет, с удовольствием ставлю в различные проекты, и могу сказать, что это просто прекрасное программное решение, которое помогает покрывать и автоматизировать многие вещи. Добавленная в эту СУБД validation schema дает все те же возможности для нормального хранения данных. Интеграции, например mongodb + kafka, спокойно отправляют всякие редисы и кролики отдыхать. Для проектов с поддержкой gql это вообще песня, так как не надо делать запросы, а можно просто ходить во view коллекции, из-за чего получается создавать нереально быстрые решения для лютейшего хайлоада. Также оч радует работа с geo.
В общем, настоятельно вам рекомендую изучить вопрос детальнее, обратиться к доке и практике, чтобы как вы выразились "на пол шишечки" понимать о чем говорите.
Делал я когда-то бенчмарки. Тут мы видим сравнение графовой субд, документной недо-субд, и реляционной субд, и для референса простое хранение данных в памяти процесса. Три кейса: создание дерева из 100К документов, выборка по родителю и выборка топ100 по дате создания. Всё прогонялось в 100 конкурентных потоках.
Ну просто нереальная скорость, да, хороший компромисс за отсутствие гарантий. А если сказать Монге не мухлевать, а сообщать об успехе только после сброса буферов, то там скорость ещё более проседает. И это была 3 Монга, без ACID. И 2 Ориент, с тормозным драйвером под ноду.
Про 32ТБ лимит у PostgreSQL - слишком толсто. Это все же ограничение на одну partition, коих можно иметь десятки тысяч для одной таблицы.
Главное достоинство MongoDB, одновременно и главный ее недостаток - горизонтальное масштабирование из коробки, ценой отсутствия транзакционной целостности между документами.
Да и для монги тоже 32Тб не предел. А про транзакции уже давно есть мультидокументные, которые в пределах узла реплики атомарны. А если надо то и на кластере можно, но ценой резкого увеличения времени выполнения запроса.
В статье же сказано
одна таблица в PostgreSQL не может занимать более 32 Тб
А это ложное утверждение, так как 32 ТБ - ограничение на один раздел, а не таблицу.
транзакции уже давно есть мультидокументные
Уже нет. Появились в 4.0, а в 4.2 их заменили распределенными транзакциями.
Но самое главное, что это не совсем транзакции. С одной стороны, да, они гарантируют, что если в транзакции были изменены несколько документов, то до фиксации транзакции эти изменения не видит никто (запрещено грязное чтение). Но с другой стороны, фиксация устроена таким образом, что после нее клиент вполне может видеть только часть из документов, участвовавших в транзакции. Этот момент явно описан в документации:
if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern
"local"can read the results of write 1 without seeing write 2
Лично у меня называть это транзакционной целостностью язык не поворачивается.
Ну read concern local это всё-таки не про транзакции, так же как и write concern, отличный от majority. Есть read concern majority, есть, если уж очень надо -- linearizable.
После чего все выгоды от шардирования теряются. Вернулись к тому, с чего начали. "Вам горизонтальное масштабирование или транзакционной целостность?"
Товарищ Брюер что-то знал, когда постулировал CAP-гипотезу (теоремой всё-таки называть не стану). Но если почитать про Spanner того же Брюера, то не всё так однозначно =)
Главный минус MongoDB по сравнению с PostgreSQL, что в PostgreSQL можно организовать документную схему хранения, а MongoDB в реляционную БД не превратить никак.
В проектах часто применяю гибридную схему в PG, основные колонки - создаются как обычно, а разные необязательные и денормализированные данные в колонке типа jsonb. Как итог: миграшки делать надо сравнительно редко, в объекте есть большая часть связанных данных "одним запросом", и при этом при всём имеем все плюшки реляционных данных, чтобы делать сложные запросы с кучей join если потребуется.
Можно сравнить монгу с jsonb посгреса по производительности
RavenDB и бутылка рома! :)
MongoDB vs PostgreSQL. Сравнение документо-ориентированной и реляционной базы данных