プロジェクトではOLAP=を使用しており、毎日リアルタイムでキューブを更新する必要があるシナリオに直面しています。
キューブ内のデータを更新するための最適な方法についていくつかの提案が必要です。
新しいデータが到着し、そのテーブルにエントリを作成するたびに、トリガーのようにキューブの現在の値を更新する必要があります。
最適なセットアップについて具体的なガイダンスを提供することは困難ですが、いずれの場合も、OLAPキューブに書き込むトリガーなどはありません。
いくつかの出発点をお伝えします。
キューブのさまざまな ストレージオプション を調べる必要があります。
既定では、キューブは[〜#〜] molap [〜#〜](多次元OLAP)を使用し、スケジュールに基づいてキューブを処理します[1]すべてのデータと集計はOLAPデータベースに保存されます。リレーショナルデータは処理後にキューブでのみ表示されるため、これには待ち時間があります。
これは、開発者の観点からは最も簡単なオプションですが、要件を解決することはできません。
[1] MOLAPの場合、プロアクティブキャッシュオプションについては以下を参照してください
[〜#〜] rolap [〜#〜](リレーショナルOLAP)ストレージモードもあり、インデックスモードで集計をリレーショナルに保存しますデータベース。キューブにはデータのコピーはありませんが、データはキューブですぐに使用できます。
これはもちろん、SSASキューブのクエリパフォーマンスに影響します。一般に、クエリの戻りは遅くなり、処理時間は長くなります。
パフォーマンスが遅すぎる場合、[〜#〜] holap [〜#〜](Hybrid OLAP)と呼ばれる3番目のオプションがあり、データを保存しますリレーショナルデータベースでは、ただしOLAPデータベースの集計です。ソースデータが更新されると、集計が再度処理されます。これにより、レイテンシがゼロになり、クエリが集計が、ユーザーがドリルダウンするか、クエリがリレーショナルストアにアクセスする必要がある場合、パフォーマンスが低下します。
プロアクティブキャッシング
また、集計が更新される頻度を決定するプロアクティブキャッシュも確認する必要があります。これは、処理によってリレーショナルデータベースにかかる負荷と、SSASクエリのパフォーマンスおよびキューブの待機時間とのバランスを取る必要があります。
プロアクティブキャッシュを使用する場合、キューブは基になるデータソースの変更をリッスンし、選択したスケジュールでMOLAPパーティションを処理します。
この記事をご覧ください SQL Server Proactive Cachingの概要 動作の説明