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

Question

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

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

SELECT [Некоторые столбцы]
FROM Таблица1 INNER JOIN Table2 [ДАННЫЕ]
INNER JOIN [BUNCH Таблицу 3 MORE JOINS] ...

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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