2

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

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

SELECT [SOME COLUMNS]
FROM Table1 INNER JOIN Table2 [詳細]
INNER JOIN Table3 [BUNCH MORE JOINS] ...

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

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

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

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

4

2 に答える 2

5

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

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

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

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

于 2008-10-07T14:20:04.360 に答える
2

マテリアライズド ビューを使用して、作業を高速化しています。ほとんどの場合、OLTP システムに対するレポート用です。レポートの多くはデータ ウェアハウスから実行されますが、一晩でウェアハウスを更新するため、データは OLTP テーブルから取得する必要があります。

于 2008-09-11T19:37:51.993 に答える