Индексированные представления в OLTP?

Question

Я знаком с индексированными представлениями SQL Server (или материализованными представлениями Oracle), мы используем их в наших приложениях OLAP. У них есть действительно классная особенность - возможность узурпировать план выполнения и переназначить его в индексированное представление без необходимости изменения существующего кода.

IE. Допустим, у меня был SPROC, который был действительно дорогим соединением.

ВЫБРАТЬ [НЕКОТОРЫЕ КОЛОННЫ]
ИЗ таблицы 1 ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таблица 2 [ДЕТАЛИ]
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Table3 [BUNCH MORE JOINS] ...

Если я создал индексированное представление с аналогичным набором результатов, то Query Optimizer, скорее всего, отправит SPROC в мое индексированное представление в отличие от базовых таблиц, и я получу значительное повышение производительности.

Теперь скажите, что я хотел использовать индексированные представления в OLTP!? Я имею в виду, что большинство OLTP (таких как этот сайт) относительно тяжело читаются, если у них дорогие объединения, мы могли бы ускорить их на тонну И потенциально уменьшает конфликт блокировок (http://www.codinghorror.com/blog/archives/001166.html). Еще лучше, если вам не придется изменять какой-либо код, просто создайте индексированное представление.

Но это также означает, что база данных становится больше, поскольку нам нужно хранить копию этих данных в индексированном представлении ...

Кто-нибудь когда-либо использовал индексированные представления для решения проблем конкуренции или скорости в OLTP? Почему я никогда не видел это в использовании?

Answer 1

Материализованные представления могут быть полезны для создания отчетов по OLTP, особенно если большое количество строк агрегируется для получения результатов. Требования к пространству полностью зависят от того, сколько данных вы сохраняете. Думайте об этом как о кеше.

Сложный баланс заключается в том, насколько свежими должны быть данные для отчетов, и насколько сильно вы можете повлиять на производительность OLTP. Если некоторые устаревшие данные в порядке, вы можете запланировать обновления для представлений в то время, когда активность системы низкая.

Один раз, когда я не мог и мне нужны были очень актуальные данные, я использовал какую-то специальную разработку. Каждое обновление базовой таблицы запускало триггер, который записывал запись в таблицу транзакций. Представление просматривало кэшированный агрегат плюс дельту, хранимую в таблице транзакций. Поскольку системные ресурсы позволяли, транзакции применялись к сводной таблице как дельта-транзакции. Это позволило мне получить вторые данные, хорошую производительность при составлении отчетов (единственной агрегацией были недавние транзакции) и довольно небольшую нагрузку на базу данных (только удваивая размер каждой записи, не пересчитывая каждый раз огромный агрегат).

К сожалению, его было сложно обслуживать, и в нем не использовались простые встроенные инструменты. Если вы можете подождать с вашими отчетными данными, часто лучше использовать встроенные материализованные представления и отложить обновление.

Answer 2

Мы используем материализованные представления, чтобы ускорить работу там, где я работаю. Чаще всего для отчетов против системы OLTP. Многие из наших отчетов запускаются из хранилища данных, но, поскольку мы обновляем хранилище в одночасье, до момента получения данных из таблиц OLTP.