В общем, я бы подумал о слое представления или о материализованном слое представления для отчетов пользователей. Я предпочитаю, если нет конкретных проблем с производительностью, заключаться в том, чтобы использовать представления с целью создания случайных материализованных представлений, использующих переписывание запросов для ускорения выбранных отчетов.
Если вы используете материализованные представления, вы, очевидно, материализуете данные во второй раз, но в формате, который приведет к менее эффективному хранению. Это означает, что большая часть пространства в системе будет выделена для денормализованных материализованных представлений и их индексов. Это может привести к довольно внушительному счету от вашего производителя дисков и может создать конкуренцию за ресурсы SAN.
Материализованные представления также означают большую конкуренцию за пространство кеша между OLTP и пользователями отчетов. Поскольку они хранятся в разных объектах, отчеты, которые ищут последние действия, не смогут извлечь выгоду из горячих блоков в кеше из-за активности OLTP и наоборот. Вы можете смягчить эту проблему, перебрасывая оперативную память или перенося отчеты в непиковое время, но это не самое эффективное решение. Если у вас есть почти исключительно историческая отчетность, это, вероятно, не имеет большого значения - в любом случае не будет никакого совместного использования, потому что процессы заинтересованы в совершенно разных блоках - но если у вас много оперативной отчетности, это становится значительным.
Материализованные представления также, вероятно, будут менее гибкими. Если вы хотите представить одни и те же данные несколькими способами, то их материализация несколько раз увеличивает реальные затраты как на диске, так и в кэше, а также увеличивает время, необходимое для периодического обновления вашего материализованного слоя представления. На практике это означает, что пользователи отчетов получают наименьшее общее знаменательное представление данных и вынуждены заново изобретать колесо при разрезании и нарезке данных, потому что ИТ не хочет создавать для них новое материализованное представление.
Как я уже говорил ранее, я бы предпочел слой обычного вида. Это позволяет избежать затрат на хранение данных несколько раз и позволяет совместно использовать блоки в кэше между OLTP и отчетными запросами. Это также позволяет относительно легко предоставлять пользователям различные представления о данных и устраняет необходимость информирования бизнес-пользователей о том, насколько устаревшими являются данные, о которых они сообщают. Если и когда производительность становится проблемой, потому что модель данных OLTP не поддерживает виды запросов, которые вы хотите выполнить, вы можете создавать целевые материализованные представления, которые действуют как индексы, через переписывание запросов . Это означает, что пользователи могут запрашивать обычные представления, а администратор базы данных может позже добавить материализованное представление, которое генерирует весь или часть результата, и оптимизатор может изменить план запроса, чтобы использовать это новое материализованное представление, а не сканировать таблицы и выполнять действия. как агрегирование данных во время выполнения.
В какой-то момент вы, вероятно, захотите переместить отчетный трафик в реальное хранилище данных с более многомерной моделью данных. Если вы обнаружите, что вам действительно нужна производительность материализованного слоя представления, а не обычного слоя представления, я бы настоятельно подумал о переходе к реальному хранилищу данных с фактами и измерениями. Вы получите что-то гораздо более гибкое для отчетности с теми же головными болями ETL, которые вы, вероятно, получите с полным материализованным слоем представления.