OLTP のインデックス付きビュー?

Question

私は SQL Server のインデックス付きビュー (または Oracle マテリアライズド ビュー) に精通しており、OLAP アプリケーションで使用しています。これらには、既存のコードを変更せずに、実行プランを横取りしてインデックス付きビューに再マップできるという非常に優れた機能があります。

いえ。非常に高価な結合である SPROC があったとします。

[一部の列] を選択します
FROM Table1 INNER JOIN Table2 [詳細]
内側の結合table3 [もっと参加するよりも束ね] ...

同様の結果セットを保持するインデックス付きビューを作成した場合、クエリ オプティマイザーはベース テーブルではなくインデックス付きビューに SPROC を送信する可能性が高く、パフォーマンスが大幅に向上します。

ここで、インデックス付きビューを使用したいとします。 OLTP!? つまり、ほとんどの OLTP (このサイトなど) は比較的読み取り負荷が高く、負荷の高い結合がある場合は、それらを大幅に高速化し、ロック競合を減らすことができる可能性があります (http://www.codinghorror.com/blog/archives/001166.html）。さらに良いのは、コードを変更する必要がなく、インデックス付きビューを作成するだけです。

ただし、これらのデータのコピーをインデックス付きビューに保持する必要があるため、データベースが大きくなるということも意味します...

OLTP の競合や速度の問題を解決するためにインデックス付きビューを使用したことがありますか?なぜこれが使われているのを見たことがないのですか？

Answer 1

マテリアライズド ビューは、OLTP に対するレポート作成に役立ちます。特に、結果を取得するために多数の行が集約される場合に便利です。必要なスペースは、保存するデータの量に完全に依存します。それをキャッシュと考えてください。

レポートに必要なデータの最新性と、OLTP パフォーマンスへの影響をどの程度許容できるかの間でバランスが難しいのが問題です。データが多少古くても問題ない場合は、システムのアクティビティが低い時間帯にビューの更新をスケジュールできる場合があります。

一度、最新のデータが必要なため、それができず、最終的にカスタム開発を使用することになりました。ベース テーブルが更新されるたびに、トランザクション テーブルにレコードを書き込むトリガーが起動されます。このビューでは、キャッシュされた集計と、トランザクション テーブルに格納されているデルタを調べました。システム リソースが許す限り、トランザクションはデルタ トランザクションとして集計テーブルに適用されました。これにより、2 番目のデータまで取得でき、レポートのパフォーマンスも良く (集計が行われたのは最近のトランザクションのみ)、データベースへの負荷もかなり少なくなりました (書き込みのサイズが 2 倍になるだけで、毎回巨大な集計を再計算する必要はありません)。

残念ながら、メンテナンスが複雑で、単純な組み込みツールは使用できませんでした。レポート データを待つことができる場合は、多くの場合、組み込みのマテリアライズド ビューを使用して更新を延期することが最善です。

Answer 2

私は仕事をスピードアップするためにマテリアライズドビューを使用しています。ほとんどの場合、OLTP システムに対するレポートに使用されます。レポートの多くはデータ ウェアハウスから実行されますが、ウェアハウスは夜間に更新されるため、現時点ではデータは OLTP テーブルから取得する必要があります。