Можно ли в одном микросервисе использовать Postgres и MongoDB?

Question

[R1911]

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

Comments

[Akina]

Если у вас часть данных в постгрессе, а часть в монго, то я как-то не понимаю, как можно получить всё иначе чем обращаться к обеим СУБД...

[R1911]

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

[Akina]

данные которые редко претерпевают измненения и имеют похожие характеристики хранить как документы в определенных коллекциях и одним запросом вытаскивать все что нужно

Вот ну никак не воспринимается эта фраза как даже просто намёк на причину. И уж тем более она не тянет на обоснование.
Так что я бы предложил оставаться в постгрессе. Структурированные документы класть в JSON(B). Сырые статические - вообще в файловую систему.

Answer 1

[Сергей Горностаев]

Технически можно, но вряд ли нужно.

Comments

[R1911]

вот есть например у меня какой-то внутренний продукт с какими-то характеристиками как один документ, в этой же коллекций такой же по смыслу документ, но с другим количеством полей, когда мне надо вывести какие-то данные на фронт, например инфо по всем продуктам с возможностью посмотреть детальную инфо по каждому, я бы брал сами продукты из постгрес, а их характеристики уже из монго
Хотя бы в теории, это можно реализовать и как? И почему это может быть плохой идеей?

[historydev]

R1911, То есть таблицы для слабаков?)

я бы брал сами продукты из постгрес, а их характеристики уже из монго

[R1911]

historydev, скорей просто как изучение нового инструмента, его плюсов и минусов, как он интегрируется с реляционками и чем он может быть удобней)
А потом уже если нужно расширять
В целом же можно хранить одни и те же данные в разных БД и брать из той, которой хочется)

[historydev]

R1911, почитай для чего используются реляционные и нереляционные базы данных, а не костыль какой-то бред.

Уж точно никто не будет использовать отдельную базу для одной таблицы.

В целом же можно хранить одни и те же данные в разных БД и брать из той, которой хочется)

Представь что ты платишь за терабайт 1$ в месяц.
- Твоя база имеет кучу ценных данных весом в 100 терабайт.

А теперь посчитай, насколько вырастет твой расход в год, за лишь один дубликат этой базы.

[Сергей Горностаев]

R1911, это в постгресе можно сделать с помощью EAV, HStore или JSONB. Две СУБД - это больше точек отказа, больше сложность, больше требования к ресурсам, отсутствие ACID и т.д. и т.п.

Answer 2

[Алексей Черемисин]

Никто не запрещает.
У меня иногда по 3-5 разных баз используется, SQL, Redis, Mongo, Elastic

Comments

[R1911]

а как же история что к одному микросервису - одну бд?

[Everything_is_bad]

R1911, это история про другое, о том что не нужно шарить одну бд между микросервисами.

[Алексей Черемисин]

R1911, да чушь все это. Если нужно пара-тройка баз, так и делайте, какие проблемы.
Единственное, хорошо бы соблюдать "single point" чтобы две программные единицы оперировали единой сущностью. Иначе все может превратиться в кошмар. Тем более в микросервисах (от которых я сваливаю на монолиты).

Как пример, пусть у нас сервис общается с БД, кешируется в редисе, кладет данные в эластик. Но пусть это будут отдельные БД, Redis и индексы Elastic, только для этого сервиса.

Answer 3

[Дмитрий Шицков]

Для структурированных данных Postgres, для прочих тоже Postgres - в JSONB поле их. Работать будет гораздо проще чем мерджить данные с 2-х баз.
Или entity–attribute–value модель использовать, если все же документы должны иметь определенные комбинации полей.

Зачем вам зоопарк БД на пустом месте и тем более на старте сервиса? Ради каких преимуществ?
Будет потребность при росте - затащите и Редис, и Эластик, ну может и Монго (не надо)

Answer 4

[Василий Банников]

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

Comments

[R1911]

Если можно, тогда такой вопрос, у нас тут рядом еще планируется микросервис который будет обрабатывать и хранить подгружаемые по заявкам документы
Для такого же варианта использование только монги подойдет хорошо? Или все же файловое хранилище для всяких сканов удобнее?

[Василий Банников]

R1911, для сканов, как правило, лучше файловое хранилище.