всего об этом спрашивать, но так как касается проектирования бэка, то решил здесь.
Подскажите, что лучше использовать (relational db, views + denormalization) или write relational db + read document-oriented noSql?
Дано: система документооборота между различными контрагентами. Над одним документом могут работать N компании/ сотрудников, в каждой компании у документа свой жизненный цикл - согласования, правки, статусы и т.д. Ну и есть общий стейт, который считается на основе стейтов в каждой компании.
Сейчас все это храним в нормализованном виде в 8 таблицах, все ОК, но начитает тормозить на тяжёлых запросах / фильтрах по всем документам - строим запросы сразу ко всем таблицам, группировки / джойны / расчеты - тяжело, индексов не хватает.
Что думаем:
Либо пилить вьюшки/триггеры, либо поставить рядом document-oritented noSql и асинхронно ивентами обновлять и хранить денормализованный плоский стейт, удобный для чтения/фильтров.
Из требовании: не профукать смену стейта, стейт чтения меняется достаточно часто, т.е. база для чтения постоянно обновляет записи.
Куда можно копать? Адекватная ли идея с nosql-read или легче запилить вьюхи/денормализованные таблицы в основной реляционной БД (+acid гарантия) и не иметь дела со всякими асинхронными ивентами?
вопросы которые стоит задавать: - денормализация вьюшки и т.д. - это всегда slate data - насколько это критично для флоу. Задержки там небольшие и если это только для UI топо идее норм - вопрос в чем "тормозит". Если вопрос только в UI - я бы начал с того что бы проанализировал запросы глянул можно ли обойтись просто парой реплик базы и тд. перед тем как решать вопросы построения вьюшек. Для этого по хорошему нужно какую-нибудь надежную инфраструктуру которая тригернет апдейт гарантированно
короч опять же - "nosql read или денормализация и вьюхи" - это все вопрос "как ты гарантируешь что стэйт актуализируется
Обсуждают сегодня