На новом проекте проекте предлагают использовать 2 СУБД PostgreSQL для всего и монгу для неструктурированных данных.
Мне не нравится идея хранить данные в двух бд и их поддерживать.
Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.

Монга имеет хорошее горизонтальное масштабирование, но до этого проекту нужно еще дожить. На постгресе тоже можно сделать кластер. Если будет свсем тяжко, то таблицы с jsonb можно вынести в отдельную бд и на отдельные сервера. Или же партиционирование прикрутить.

Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?
Можно конечно сделать микросервисы, где один будет отвечать за монгу, а второй за документы в постргресе, но это все отчеты и статистику придется делать на клиенте или в еще одном сервисе интеграции документов из двух бд.

Здравствуйте, BlackEric, Вы писали:

BE>Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.

Класть рядом не обязательно, можно индексировать прям внутри.

BE>Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?

Аргументов за Mongo я не увидел. Теоретический рост нагрузки — вам видней. Да, Mongo масштабируется проще Postgres, но не принципиально лучше. Но это классический случай преждевременной оптимизации, причём на архитектурном уровне, что особенно больно. Я за Postgres пока его хватает,.

По-мне самый отстой с двумя БД это транзакции. Корректный код будет писать очень сложно, поэтому будут писать некорректный. Поэтому БД будут разъезжаться и будут всякие фантомные баги в данных, которые никто не знает, откуда взялись.

Если хочется экзотики — я бы подумал про другие варианты, вроде YDB.

BE>На новом проекте проекте предлагают использовать 2 СУБД PostgreSQL для всего и монгу для неструктурированных данных.
BE>Мне не нравится идея хранить данные в двух бд и их поддерживать.
Проси бюджет на выделенного DBA, который этот зоопарк будет поддерживать. Обычно после этого заказчик быстро соглашается на вариант попроще.

BE>Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.
Я такое делал. В целом, вполне рабочий вариант.
Причем, отдельные поля в таблице можно не делать, PSQL умеет стоить индексы прямо по содержимому JSON.
Что еще тут нужно учесть:
1. Критерии поиска. В монге (по крайней мере в .NET-клиенте) индексы можно строить автоматически, по требованию. В PSQL это всегда придется делать руками.
Если вариантов сочетаний полей для поиска много, это может стать проблемой: и по необходимости ручных манипуляций, и по размеру индексов, и по скорости вставки/обновления данных.
2. Размер JSON-документа. Если он больше 2Kb (8k страница, и хотя бы 4 записи на страницу), то в PSQL эти данные будут лежать TOAST. А это чуть медленнее обычной таблицы.
Тут есть смысл попрофайлить типовые сценарии Mongo vs PSQL, если скорость критически важна.
3. Распределенные транзакции. Про это коллега выше написал.

BE>Монга имеет хорошее горизонтальное масштабирование, но до этого проекту нужно еще дожить. На постгресе тоже можно сделать кластер. Если будет свсем тяжко, то таблицы с jsonb можно вынести в отдельную бд и на отдельные сервера. Или же партиционирование прикрутить.
BE>Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?
Имхо, если на данном этапе нет однозначного понимания преимуществ Mongo, то и брать ее пока что не стоит.
Делай как проще и быстрее, собирай фидбек, адаптируй архитектуру.
В конце-концов, перейти с JSON в PSQL на JSON в Mongo можно сравнительно быстро.

Здравствуйте, BlackEric, Вы писали:

BE> Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?

Делал. В твоем описании плюсов за монгу не увидел. Помимо всего прочего монгу еще нужно уметь готовить (а это дисциплина специальной олимпиады). Возможно есть смысл стартовать с минимального кластера psql (чтобы сразу ловить грабли шардирования, репликации и т.д.), но про монгу думать уже когда-нибудь потом.

Здравствуйте, BlackEric, Вы писали:

BE>Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?

Нет ни одной причины использовать mongodb в 2025 году. Равно как и неструктурированных данных в 2025 году не бывает. Если вы собираетесь искать по этим данным, то они уже стуктурированы. Если не собираетесь, складывайте документы на S3 и храните в базе только индекс.

M>Нет ни одной причины использовать mongodb в 2025 году. Равно как и неструктурированных данных в 2025 году не бывает. Если вы собираетесь искать по этим данным, то они уже стуктурированы. Если не собираетесь, складывайте документы на S3 и храните в базе только индекс.

А S3 к каждому современному проекту, конечно же, прилагается совершенно бесплатно.
Его так-то тоже нужно либо разворачивать локально, либо покупать как сервис.
А грамотно развернуть и эксплуатировать локальный кластер того же minio — это плюс-минус того же уровня задача, что развернуть кластер монги.

Здравствуйте, RushDevion, Вы писали:

M>>Нет ни одной причины использовать mongodb в 2025 году. Равно как и неструктурированных данных в 2025 году не бывает. Если вы собираетесь искать по этим данным, то они уже стуктурированы. Если не собираетесь, складывайте документы на S3 и храните в базе только индекс.

RD>А S3 к каждому современному проекту, конечно же, прилагается совершенно бесплатно.
RD>Его так-то тоже нужно либо разворачивать локально, либо покупать как сервис.
RD>А грамотно развернуть и эксплуатировать локальный кластер того же minio — это плюс-минус того же уровня задача, что развернуть кластер монги.

Тут тогда можно использовать FileStream в MS SQL вместо S3 Minio. У постгреса аналогов для этого вроде бы нет?

BE>Тут тогда можно использовать FileStream в MS SQL вместо S3 Minio.
Можно, конечно.
Просто изначально же речь шла о каких-то слабоструктурированных данных в Mongo и необходимости поиска по ним.
А это неявно предполагает сравнительно небольшие размеры JSON-документов.
А теперь мы почему-то пришли к бинарным данным потенциально большого размера с доступом в режиме стриминга.
Это же совершенно разные вещи

BE>У постгреса аналогов для этого вроде бы нет?
Какие-то сторонние поделки имеются, но официального инструмента уровня File Stream в MSSQL я не знаю.

M>Равно как и неструктурированных данных в 2025 году не бывает.

Часто вопрос возникает не к "неструктурированным" данным, а данным, без чёткой схемы. Когда каждая запись у тебя различается структурой.
Да, это можно разрулить и в сиквеле, но не всегда удобно.

Здравствуйте, Enomay, Вы писали:

E>Часто вопрос возникает не к "неструктурированным" данным, а данным, без чёткой схемы. Когда каждая запись у тебя различается структурой.
E>Да, это можно разрулить и в сиквеле, но не всегда удобно.

С чем обычно возникают проблемы разруливания в сиквеле со слабоструктурированным джейсоном по сравнению с монгой? Какой класс проблем решается сильно проще?

Здравствуйте, BlackEric, Вы писали:

BE>На новом проекте проекте предлагают использовать 2 СУБД PostgreSQL для всего и монгу для неструктурированных данных.
BE>Мне не нравится идея хранить данные в двух бд и их поддерживать.
BE>Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.

Это и есть правильный путь. json в постгрес — норм

Работа с одной системой сильно проще, чем с двумя. Одна транзакционность чего стоит.

Здравствуйте, BlackEric, Вы писали:

BE>На новом проекте проекте предлагают использовать 2 СУБД PostgreSQL для всего и монгу для неструктурированных данных.
BE>Мне не нравится идея хранить данные в двух бд и их поддерживать.
BE>Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.

BE>Монга имеет хорошее горизонтальное масштабирование, но до этого проекту нужно еще дожить. На постгресе тоже можно сделать кластер. Если будет свсем тяжко, то таблицы с jsonb можно вынести в отдельную бд и на отдельные сервера. Или же партиционирование прикрутить.

BE>Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?
BE>Можно конечно сделать микросервисы, где один будет отвечать за монгу, а второй за документы в постргресе, но это все отчеты и статистику придется делать на клиенте или в еще одном сервисе интеграции документов из двух бд.

Если хочется mongo в дополнение к Postgres, то есть FerretDB, где все в "одном флаконе".