Oracle Database 10g Enterprise Edition、 を使用するOLTPアプリケーションがあり、以下のニーズを満たすビジネス・レポーティング・レイヤーを構築する予定です。現在のOLTPは、ビジネスユーザーが を報告するアドホックを実行できるよう OLTPアプリケーションのビジネス・レポート
私たちが考えている解決策は、現行のOLTP上でOracle Materialized Views（MV）を使用してDBキャッシュ層を作成することです。 MVは非正規化され、報告用に設計されています。 MVログは増分リフレッシュを使用してMVに変更を同期させます。
私の質問、
一般的にはシェリー
、私は、ユーザーを報告するためのビュー層またはマテリアライズド・ビュー層のいずれかのことを考えられる、ありがとうございます。具体的なパフォーマンスの問題がなければ私の好みは、選択されたレポートをスピードアップするためにクエリー・リライトを使用する、時折マテリアライズド・ビューを作成することに目を向けるビューを伴うことです。
マテリアライズド・ビューを使用する場合は、2回目のデータのマテリアライズが行われますが、ストレージの効率が低下する可能性があります。つまり、システム内のほとんどの領域が非正規化マテリアライズド・ビューとその索引に割り当てられます。これは、ディスクベンダーから多額の請求書を生成し、SANリソースの競合を引き起こす可能性があります。
また、マテリアライズド・ビューは、OLTPとレポート・ユーザー間のキャッシュ・スペースの競合が増えることを意味します。それらは異なるオブジェクトに格納されているため、最近のアクティビティを検索しているレポートは、OLTPアクティビティのキャッシュ内のホットブロックの恩恵を受けることはできません。この問題を緩和するには、RAMをスローするか、レポートをピーク時以外に移動することで軽減できますが、これは最も効率的な方法ではありません。ほとんど歴史的な報告があれば、これは大したことではないでしょう。プロセスはまったく異なるブロックに関心があるため共有はできませんが、多くの運用レポートがあれば重要になります。
マテリアライズド・ビューの柔軟性が低下する可能性があります。同じデータを複数の方法で表示したい場合は、複数回実行することで、ディスクとキャッシュの両方で実費が発生し、マテリアライズド・ビュー・レイヤーの定期的リフレッシュに必要な時間が長くなります。実際には、レポートするユーザーがデータの共通点を最小限に抑え、IT部門が新しいマテリアライズドビューを作成する必要がないため、データをスライスしてサイコロを修正する必要があります。
私が先に述べたように、私の好みは通常のビュー層になります。これにより、データを複数回保存するコストが回避され、OLTPとレポート作成クエリーの間でキャッシュ内のブロックを共有することが可能になります。また、ユーザーにデータのさまざまなビューを比較的簡単に提供し、レポートしているデータがどれほど古くなっているかをビジネスユーザーに知らせる必要性を排除します。 OLTPデータ・モデルが実行する問合せの種類をサポートしていないためにパフォーマンスが問題になった場合は、query rewriteを介して索引のように動作するターゲット・マテリアライズド・ビューを作成できます。つまり、ユーザーは通常のビューを問い合せることができ、DBAは後で結果の全部または一部を生成するマテリアライズド・ビューを追加できます。オプティマイザは、表をスキャンして実行するのではなく、実行時にデータを集約するようなものです。
場合によっては、より多くの次元のデータモデルを使用して実際のデータウェアハウスにヒットするようにレポートトラフィックを移動することが必要な場合があります。通常のビュー・レイヤーではなく、マテリアライズド・ビュー・レイヤーのパフォーマンスが本当に必要な場合は、ファクトとディメンションを使用して実際のデータ・ウェアハウスに行くことを強く考えます。基本的に完全なマテリアライズド・ビュー・レイヤーを使用した場合と同じETLの頭痛で、レポート作成の方がはるかに柔軟なものが得られます。
申し訳ありませんが、その10gエンタープライズエディションです。 – Sherry
@ Sherry-は表現していない企業向けのポストを書き換えました。 –
エンタープライズエディションで再転載していただきありがとうございます。また、MVのストレージとリソースの問題をよく指摘しています。 – Sherry