Индексированные представления в OLTP?
Я знаком с индексированными представлениями 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? Почему я никогда не видел это в использовании?
2 ответа
Материализованные представления могут быть полезны для создания отчетов по OLTP, особенно если большое количество строк агрегируется для получения результатов. Требования к пространству полностью зависят от того, сколько данных вы сохраняете. Думайте об этом как кеш.
Сложный баланс заключается в том, насколько свежими должны быть данные для отчетов, и насколько сильно вы можете повлиять на производительность OLTP. Если некоторые устаревшие данные в порядке, вы можете запланировать обновления для представлений в то время, когда активность системы низкая.
Один раз, когда я не мог и нуждался в очень актуальных данных, я использовал какую-то специальную разработку. Каждое обновление базовой таблицы запускало триггер, который записывал запись в таблицу транзакций. Представление просматривало кэшированный агрегат плюс дельту, хранимую в таблице транзакций. Поскольку системные ресурсы позволяли, транзакции применялись к сводной таблице как дельта-транзакции. Это дало мне возможность получить вторые данные, хорошую производительность при составлении отчетов (единственной агрегацией были недавние транзакции) и довольно небольшую нагрузку на базу данных (только удваивая размер каждой записи, не пересчитывая каждый раз огромный агрегат).
К сожалению, его было сложно поддерживать, и он не использовал простые встроенные инструменты. Если вы можете подождать ваших отчетных данных, часто лучше использовать встроенные материализованные представления и отложить обновление.
Мы используем материализованные представления, чтобы ускорить работу там, где я работаю. Чаще всего для отчетов против системы OLTP. Многие из наших отчетов запускаются из хранилища данных, но, поскольку мы обновляем хранилище в одночасье, до момента получения данных из таблиц OLTP.