私はまだ OLAP、キューブ、および SSAS のコツを学んでいますが、パフォーマンスの障壁にぶつかりつつあり、何が起こっているのか理解できていません。
2 つの単純なディメンション (タイプと面積)、3 つ目の時間ディメンション階層 (年 -> 四半期 -> 月 -> 日 -> 時間 -> 10 分)、および 1 つのメジャー (合計) を定義する単純なキューブがあります。 Count というフィールドで）。データベースはイベントを追跡します。発生時期、種類、発生場所などです。ファクト テーブルは、10 分間隔ごとに事前に計算されたイベントの要約です。
そこで、キューブをセットアップし、ブラウザーを使用して一度にすべての属性を表示します。年から 10 分間隔までドリルダウンして、タイプごとのエリアごとの合計数を経時的に表示します。レポートのパフォーマンスは、ブラウズと似ています。
ほとんどの場合、それは十分にきびきびしています。しかし、ドリル ツリーを深く掘り下げるほど、各レベルを表示するのに時間がかかります。最後に、分レベルでは、わずか 6 件のレコードを表示するのに 20 分ほどかかるようです。しかし、その後、他の分レベルのドリルダウンを待機なしで表示できることに気付きました。その時点で、キューブはテーブル全体を計算しているように見えます。これが非常に時間がかかる理由です。
理解できない。すべてのデータを集計する必要があるため、Quarters または Years に移動すると、最も時間がかかると予想されます。約 180 セル (6 間隔、10 種類、3 領域) まで大幅にフィルター処理された最も低いメトリックに行くと、最速になるはずです。キューブが表示されているサブセットだけでなく、データセット全体を処理するのはなぜですか? 集計の最高レベルが非常に速く、最低レベルが非常に遅いのはなぜですか?
最も重要なことは、それを改善するために構成または設計によってできることはありますか?
これは、SQL Server 2005 で実行され、BI 設計に Visual Studio 2005 を使用する SSAS 2005 です。キューブは (デフォルトで) 完全な MOLAP に設定されていますが、分割されていません。ファクト テーブルには 1,838,304 行あるため、これはクレイジーなエンタープライズ データベースではありませんが、単純なテスト データベースでもありません。パーティショニングはなく、すべての SQL は 1 台のサーバーで実行され、ワーク ステーションからリモート アクセスします。