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