Используете ли вы реляционные и документоориентированные субд в одном проекте?
Здравствуйте! Доводилось ли вам работать над проектами, в которых используется и реляционная субд, и документоориентированная ? К примеру.. Возможно у кого-то был случай, что данные профиля юзеров хранились в rdbms и к тому же операции над счетами выполнялись в рамках транзакций этой судб, а все остальные данные (связанные с этими юзерами или нет) - разреженные документы (например в MongoDB в виде BSON).
Про Redis можете забыть в контексте этого вопроса. Redis - судб вида key-value.
Да, это более чем нормальный сценарий. Скажем хранить все в postgresql и делать агрегации данных для ускорение выборок в какой нибудь elasticsearch или монгу.
А если вы еще и CQRS будете практиковать, то вообще ништяк. Тогда команды у нас будут работать только с postgresql и инициировать обновление агрегаций а запросы - с эластикой.
Транзакция хранятся в монгодб, но параллельно приходится проливать часть данных в SybaseIQ. Это нужно в основном для расчета различных извращенный отчетов для бизнеса, в монге такое посчитать не выйдет.
Не совсем понятно что вы делаете конечно, но могу предположить.. Т.е. имеется ввиду вы транзакции обрабатываете в mongodb (некое подобие их, разными процессами), а при помощи SybaselQ просто статистику просчитываете ? Я правилно понял ? SybaselQ конечно впервые слышу.. с столбцовыми субд не имел раньше дела. Скажите, учитывая контекст задачи в вопросе, можно ли заменить обычную rdbms столбцовой, если хранить только счета и информацию о пользователе ? Как такой вариант ?
Смотрите, документо ориентированная субд, такая как монгодб, хороша тем, что вы можете хранить данные в ней с нестабильной структурой (грубо говоря набором полей). Есть у вас какие то общие наборы полей: счет, сумма, дата... но остальное может быть разным, в зависимости от источника. + каждую неделю могут появляться новые поля. Использовать rdbms для хранения такого - это адъ.
Если стоит вопрос просто хранения данных, то все ОК. Но если вам нужно для бизнеса считать отчеты и различные статистики, а это в основном группировки по разным полям, с кучей условий... монга для этого плохо подходит. Потому выбираем часть данных в реляционку и там уже строим все расчеты
спасибо за столь развернутый ответ!!!!!! конечно же обо всем этом я знал уже. "Потому выбираем часть данных в реляционку и там уже строим все расчеты " а вот это уже ответ на вопрос в комментарии :) спасибо еще раз!!
Да, применяем. Все данные, у которых есть нормальная схема - в постгресе, данные, для которых нет общей схемы (в том числе пользовательские атрибуты к сущностям предметной области - различные заметки и комметарии, свой набор для каждого пользователя) - в монге.
sim3x это была основная альтернатива). Решили в монге, чтобы физически разделить core-данные, и пользовательские довески. Конечно, можно было бы поморочиться и сделать вертикальный partitioning, разбить на разные таблицы и связать внешними ключами, но там особенность еще в том, что для этих двух разных "классов" данных (в постгресе и в монге) также и разные требования к уровню качества обслуживания: недоступность пользовательских данных - вещь не особо приятная, но куда более терпимая, нежели недоступность основных (это GIS-проект, доступность карты весьма важна). Поэтому решили сразу сделать эдакий микросервис для пользовательских данных и обслуживать его по своим правилам (меньше бэкапов, чем у основных, меньше mirror-серверов и т.д.). Хотя конечно долго думали как лучше, т.к. постгрес с JSON-ом работает очень неплохо сейчас)
sim3x не, пока около гига, в основном строки и из них треть полей вводится вручную, поэтому растет медленно). Полет нормальный. Сам микросервис на asp.net webapi, но монга на дебиане крутится, не на винде.
sim3x: "если в ТЗ четко определены архитектурные решения" кто-то сначала должен очертить все. вы как ребенку объясняете, но я все это уже давно знаю :) в общем.. спасибо, но бесполезный комментарий вообще для меня :)
Средний
Простой
Средний
