私は55 GBのサイズのキューブを使用しており、完全に処理するには約2時間かかります。過去4年間のデータがありますが、私たちのビジネスでは2年間のデータしか必要としません。そのために、ディメンションビューとファクトビューを変更して、データが最後の2年間しか残っていないようにしました。これで、キューブのサイズが32 GBに減少しましたが、処理時間は30分(つまり、2時間30分)増加しました。キューブに入るデータの量を制限しているので、それが少なくなると思っていました。実際に短縮する必要があるのに、なぜ処理時間が増加したのですか?どうすれば今、処理時間を短縮できますか?
PS:私はすでにキューブパーティションを試しましたが、ディメンションサイズが大きいため、処理時間も増加しています。
WHERE句でデータを制限したビューを使用しています。
私の見解は基本的に次のようなものです:
SELECT V.Col1, V.Col2.... V.Col13
FROM DimeTable V
WHERE <my filter clause>
ディメンションテーブルからほとんどすべての列を選択しているため、これらのすべての列に非クラスター化インデックスを作成することはできません。挿入操作が遅くなる可能性があり、あまり役に立ちません。
キューブの処理は、主に3つのステップで構成されます。
ステップ2と3は私の考えでは(処理中に)最も安価なので、それから始めましょう。
インデックスの作成は、属性関係のビットマップインデックスの計算にすぎません。設計したものの数に応じて、これには時間がかかる場合とそうでない場合がありますが、通常は30分はかかりません。これは、「このアイテムグループがフィルターされている場合、そのアイテムが既に含まれているので、NONEMTPTYCROSSJOIN
を実行する代わりにそれらを追加できる」と言うだけです。
集計の計算は、それらを定義したすべてのレベルの小計が計算されるプロセスです。 usage based optimization
またはattribute hierarchies
を使用しておらず、自分で集計を定義していない場合、それらはディメンション階層のリーフレベル(すべての属性の最下位レベル)でのみ計算されます。これは基本的に「このアイテムグループの売上が必要な場合は、事前に計算しており、これらのアイテムを合計する必要がない」
データのフェッチ中に、処理時間の大部分が使用されます。処理中にクエリをトレースすると、すべてのディメンション属性に対してSELECT DISTINCT attributename FROM dimension_table
が実行されることがわかります。そのディメンションテーブルがビューであり、ビューを追加した後のビューからのクエリが遅い場合、そのディメンション処理はtime_the_view_is_slower * number_of_attributes
だけ遅くなる可能性があります。
ビューの選択リストにある列の数はほとんど関係ありません。ディメンションの属性の数isです。
distinct count
メジャーがある場合は、新しい実行プランのために、余分な場所にもソート操作が挿入されている可能性があります。
したがって、あなたのケースでは、有効な日付がインデックス付けされていないか、クエリが十分に選択されておらず、ソースクエリの追加の処理時間が余分な時間を誇張しているため、ディメンションビューが遅くなったと思いますインデックスと集計の作成。
キューブ内のデータを減らして計算されるセルの数を減らすことにより、プロセスのキューブブラウジングとMDXパフォーマンスを向上させた可能性が高いですが、より遅いソースクエリを作成することで処理時間が長くなり、その数が乗算されます。属性。
繰り返しますが、すべてをデフォルトのままにしておくと、処理時間が長くなることによる問題が何であるかはわかりません。 SSASソリューションのパフォーマンスは、処理時間よりも重要です。処理時間による問題が発生した場合は、別の方法で修正する必要がある別の問題である可能性があります。
したがって、最終的には、処理時間を心配している場合は、ソースデータベースに読み込むデータを少なくするか(設定によっては、ETLの読み込み時間を短縮できる可能性があります)、それに応じてビューにインデックスを付けて、これらすべての個別のクエリを調整します。
処理の速度が低下している原因を正確に知りたい場合は、変更の前後のすべてのクエリを追跡し、実行時間を比較して、どのクエリが原因で問題が発生しているかを確認します。