Можно ли в одном микросервисе использовать Postgres и MongoDB?
Не судите строго, я тут новенький и есть такой вопрос, можно ли использовать на одном сервисе запрос к двум бд разных видов и потом маппить эти данные? Часть данных я беру с постгрес, часть в виде документа из коллекции в монго или это какой-то прям совсем костыль и пятое колесо?
Akina, мы только проектируем эту часть и возникла такая мысль, чтобы данные которые редко претерпевают измненения и имеют похожие характеристики хранить как документы в определенных коллекциях и одним запросом вытаскивать все что нужно
данные которые редко претерпевают измненения и имеют похожие характеристики хранить как документы в определенных коллекциях и одним запросом вытаскивать все что нужно
Вот ну никак не воспринимается эта фраза как даже просто намёк на причину. И уж тем более она не тянет на обоснование.
Так что я бы предложил оставаться в постгрессе. Структурированные документы класть в JSON(B). Сырые статические - вообще в файловую систему.
вот есть например у меня какой-то внутренний продукт с какими-то характеристиками как один документ, в этой же коллекций такой же по смыслу документ, но с другим количеством полей, когда мне надо вывести какие-то данные на фронт, например инфо по всем продуктам с возможностью посмотреть детальную инфо по каждому, я бы брал сами продукты из постгрес, а их характеристики уже из монго
Хотя бы в теории, это можно реализовать и как? И почему это может быть плохой идеей?
historydev, скорей просто как изучение нового инструмента, его плюсов и минусов, как он интегрируется с реляционками и чем он может быть удобней)
А потом уже если нужно расширять
В целом же можно хранить одни и те же данные в разных БД и брать из той, которой хочется)
R1911, это в постгресе можно сделать с помощью EAV, HStore или JSONB. Две СУБД - это больше точек отказа, больше сложность, больше требования к ресурсам, отсутствие ACID и т.д. и т.п.
R1911, да чушь все это. Если нужно пара-тройка баз, так и делайте, какие проблемы.
Единственное, хорошо бы соблюдать "single point" чтобы две программные единицы оперировали единой сущностью. Иначе все может превратиться в кошмар. Тем более в микросервисах (от которых я сваливаю на монолиты).
Как пример, пусть у нас сервис общается с БД, кешируется в редисе, кладет данные в эластик. Но пусть это будут отдельные БД, Redis и индексы Elastic, только для этого сервиса.
Для структурированных данных Postgres, для прочих тоже Postgres - в JSONB поле их. Работать будет гораздо проще чем мерджить данные с 2-х баз.
Или entity–attribute–value модель использовать, если все же документы должны иметь определенные комбинации полей.
Зачем вам зоопарк БД на пустом месте и тем более на старте сервиса? Ради каких преимуществ?
Будет потребность при росте - затащите и Редис, и Эластик, ну может и Монго (не надо)
Можно, разрешаю, но выглядит как-то странно.
Я бы задумался над возможностью переноса всех данных либо в монгу, либо в постгрес, чтобы в будущем не возникало проблем с консистентностью данных.
Если можно, тогда такой вопрос, у нас тут рядом еще планируется микросервис который будет обрабатывать и хранить подгружаемые по заявкам документы
Для такого же варианта использование только монги подойдет хорошо? Или все же файловое хранилище для всяких сканов удобнее?