MDX のパフォーマンスとT-SQL

StackOverflow https://stackoverflow.com/questions/1672754

質問

6 億を超えるレコードを含むテーブルと、データベース上で複雑な検索操作を実行する一連のストアド プロシージャを含むデータベースがあります。ストアド プロシージャのパフォーマンスは、テーブルに適切なインデックスがあっても非常に遅くなります。データベースの設計は、通常のリレーショナル データベース設計です。データベース設計を多次元に変更し、従来の T-SQL クエリの代わりに MDX クエリを使用したいのですが、問題は次のとおりです。MDX クエリはパフォーマンスの点で従来の T-SQL クエリよりも優れていますか?はいの場合、クエリのパフォーマンスはどの程度向上しますか?

助けていただきありがとうございます。

役に立ちましたか？

解決

リンゴとオレンジ:Analysis Services OLAP キューブは、SQL Server データベースとは根本的に異なる種類のストレージであり、異なることを実行するように設計されています。技術的には、MDX は T-SQL よりも「高速」ではなく、その逆も同様です。MDX は単なる言語ですが、さまざまなニーズに合わせて設計されています。

そうは言っても、通常は立方体が最も効果的です。 数値 静的データの分析（大量の販売、取引、その他の記録を長期にわたって集計するなど）。対照的に、スキーマとインデックスが適切に構築されていれば、従来のリレーショナル データベースは通常、検索に問題なく機能します。簡単な判断方法：SQL クエリで多くのことを実行する必要がある場合 

select grock, sum/min/max/avg( foo ) 
from bar 
group by grock -- Ideal Analysis Services problem

その場合はキューブが役に立つかもしれません (これは集計数学関数 - sum() と group by 用に設計されています)。OTOH クエリで多くの処理が実行される場合

select cols 
from foo 
where <complicated search> -- Not so much

その場合、キューブはおそらく役に立たず、代わりにスキーマ、クエリ、インデックス作成、そしてデータが適切にパーティション化できる場合はテーブルのパーティション化の調整に重点を置くと思います。

クラスター化インデックスと、クエリに一致する非クラスター化インデックスをカバーしていますか?

他のヒント

MS SSAS OLAP キューブは、いくつかのストレージ モードで使用できます。

  1. リレーショナル (OLAP) - データとメタデータは DB に残り、さらにいくつかのマテリアライズド ビューが追加されます。速いかもしれないし、そうでないかもしれません。

  2. ハイブリッド (HOLAP) - メタデータと (事前計算された) 集計は、SSAS インスタンスを実行する新しいサーバーに保存されます。これにより、「昨年の月ごとの総従業員時間」などの集計を使用するすべてのクエリが高速化されますが、特定のレコードにドリルスルーするクエリは以前と同様になる可能性があります。

  3. すべてのデータとメタデータおよび集計が SSAS サーバーにコピーされる多次元 OLAP (MOLAP)。これは通常最も高速ですが、ストレージが重複します。

これを開始する前に、レポートと分析用にテーブル レイアウトを最適化することを検討する必要があります。つまり、データ ウェアハウス (DW) を使用し、データを Kimball スター ディメンションとファクト テーブルに配置します。次に、ETL(SSIS) を使用して DW を定期的に読み込み、レポートと分析を DW に向けます。SSAS をまったく使用する必要がない場合もあります。スター テーブル レイアウトに対して実行される SQL クエリは、通常、正規化された DB 運用データベースに対して実行するよりもかなり高速です。これでも遅すぎる場合は、DW 上に SSAS キューブを構築します。DW のロードを開始すると、運用データベースからレコードを削除できる場合があり、日常の使用を高速化できます。

要約すると、私の経験則は次のようになります。
1.DW を構築し、ETL プロセスを設定する
2.DW に対して T-SQL レポートを試してみてください。これで十分かもしれません。
3.それでも遅い場合は、HOLAP モードで SSAS キューブを (DW 上に) 構築し、MDX を使用してクエリを実行します。

「適切なインデックスを使用してもストアド プロシージャのパフォーマンスが非常に遅い」

ストアド プロシージャが本当の問題であるとしたら、私は驚きます。プロシージャの使用方法が遅いのかもしれませんが、ストアド プロシージャの定義上、ストアド プロシージャが遅くなるわけではありません。自分の手続きの何が遅いのか分かりましたか?彼らのプロフィールを作成しましたか?私なら、データベースを再設計する前に、そのルートを徹底的に検討します。多次元データベースは OLAP 用です。データベースは厳密に OLAP データベースですか、それとも OLAP と OLTP のハイブリッドですか?おそらく、OLTP 設計内のデータを非正規化し、非正規化 d 構造に複製する必要があるでしょうか?テーブル内の 6 億レコードは決して大きいわけではありませんし、小さいわけでもありませんが、だからと言ってストアド プロシージャを削除すれば魔法のように処理が高速になるとは思えません。問題を解決するためにより大きなプロジェクトに取り掛かる前に、ストアド プロシージャをプロファイリングし、パフォーマンスのボトルネックがどこにあるのかを確認します。

PowerPivot (Excel アドオン) を検討したことがありますか?垂直圧縮を使用してデータをローカルで約 95% 圧縮するため、心ゆくまで分析できます。

http://technet.microsoft.com/en-us/library/ee210692.aspx

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top