В общем, я думал бы либо вид слоя или материализованное представление слоя для пользователей отчетности. Мое предпочтение, если нет конкретных проблем с производительностью, заключается в том, чтобы идти с представлениями с целью создания случайных материализованных представлений, которые используют переписку запроса для ускорения выбранных отчетов.
Если вы используете материализованные виды, вы, очевидно, будете материализовывать данные во второй раз, но в формате, который приведет к менее эффективному хранению. Это означает, что большая часть пространства в системе будет выделена для денормализованных материализованных представлений и их индексов. Это может создать довольно здоровенный счет у вашего поставщика дисков и может создать конкуренцию для ресурсов SAN.
Материализованные виды также означают больше конкуренции за пространство кэша между OLTP и пользователями отчетов. Поскольку они хранятся в разных объектах, отчеты, которые ищут недавнюю активность, не смогут извлечь выгоду из горячих блоков в кеше из активности OLTP и наоборот. Вы можете смягчить эту проблему, выбросив в нее ОЗУ или переместив отчетность в непиковые времена, но это не самое эффективное решение. Если у вас почти исключительно историческая отчетность, это, вероятно, не имеет большого значения - в любом случае не будет никакого обмена, потому что процессы заинтересованы в совершенно разных блоках, но если у вас много оперативной отчетности, это становится значительным.
Материализованные виды также могут быть менее гибкими. Если вы хотите представить одни и те же данные несколькими способами, это материализует его несколько раз, что приводит к реальным затратам как на диске, так и на кеше, а также увеличивает время, необходимое для периодического обновления вашего материализованного уровня представления. На практике это означает, что пользователи отчетов получают наименьший общий знаменатель данных и должны повторно изобретать колесо, когда они разрезают и копируют данные, потому что ИТ не хочет создавать для них новое материализованное представление.
Как я уже говорил ранее, предпочтение было бы правильным. Это позволяет избежать затрат на хранение данных несколько раз и позволяет делиться блоками в кеше между OLTP и запросами отчетности. Это также позволяет относительно легко предоставить пользователям разные виды данных и устраняет необходимость информировать бизнес-пользователей о том, насколько устаревшие данные, о которых они сообщают, являются. Если и когда производительность становится проблемой, потому что модель данных OLTP не поддерживает сортировку запросов, которые вы хотите запустить, вы можете создавать объекты с таргетингом на материализованные представления, которые действуют как индексы с помощью query rewrite. Это означает, что пользователи могут запрашивать регулярные представления, а администратор баз данных может впоследствии добавить материализованное представление, которое генерирует весь или часть результата, и оптимизатор может изменить план запроса, чтобы использовать это новое материализованное представление, а не сканировать таблицы (таблицы) и делать вещи как агрегирование данных во время выполнения.
В какой-то момент вы, вероятно, захотите перенести трафик отчетности, чтобы попасть в реальный хранилище данных с более объемной моделью данных. Если вы обнаружите, что вам действительно нужна производительность материализованного слоя представления, а не обычного слоя, я бы подумал о том, чтобы перейти к реальному хранилищу данных с фактами и размерами. Вы получите то, что гораздо более гибко для отчетности, в основном с теми же головными болями ETL, которые вы, вероятно, получите с полным материализованным уровнем представления.
жаль, что не упоминает о том, что это 10-граммовое корпоративное издание. – Sherry
@ Шерри - переписал сообщение для предприятия, не выражающего. –
спасибо за повторную отправку с изданием предприятия, а также хорошо рассмотрены вопросы хранения и ресурса MV. – Sherry