DAX Studio のパフォーマンスの問題: CallBackDataID

このチュートリアルでは、DAX Studio のパフォーマンスの問題であるCallBackDataIDについて説明します。これが何をするのか、そして DAX クエリのパフォーマンスにどのような影響を与えるのかを学びます。

ストレージ エンジンは、データ キャッシュの形式でフォーミュラ エンジンにデータを提供するように機能します。ただし、ストレージ エンジンが式を評価できない場合は、 CallBackDataID を使用して数式エンジンにヘルプを求め、コールバックします。

計算にCallBackDataIDを含めると、 DAX はストレージと数式エンジンの両方を使用するため、DAX のパフォーマンスが低下します。ただし、数式エンジンだけですべての作業を行うよりは、圧縮されたデータに対して実行され、実体化が必要ないため、それでも優れています。

また、数式エンジンが関与している場合、結果はキャッシュされません。キャッシュにより、LuckyTemplates でクエリまたはメジャーを実行する際のユーザー エクスペリエンスが向上します。

目次

• CallBackDataID を確認する場所
• パフォーマンスの問題を解決する方法
• 結論

CallBackDataID を確認する場所

CallBackDataID は、 DAX Studio 内のサーバー タイミングで見つかります。これらは重要であるため、xmSQL ステートメント内で強調表示されています。DAX を最適化したい場合は、CallBackDataIDを見つけることから始めるのが最適です。

のフィルターを活用することです。フィルターでCALCULATE を使用することは、 テーブルとして使用するよりも優れています。FILTERは反復子であり、テーブルをフィルターすると、 によって反復処理されます。これら 2 つのイテレータが存在すると、クエリの速度が低下する可能性があります。

CallBackDataID を使用した場合と使用しない場合の 2 つのサンプル クエリを次に示します。

これは、上記の 2 つのクエリを定義するローカライズされた対策です。

一番上のメジャーは、Sales テーブルを反復し、現在の価格と数量を乗算して、合計します。一番下のメジャーは、購入日が 2016 年 3 月 31 日以上であるかどうかをチェックします。メジャーに関数があると、 CALCULATEを使用していないためCallBackDataIDが作成されます。

これをテストするには、 CallBackDataIDを含むクエリを実行します。実行する前に、必ずキャッシュをクリアし、サーバー タイミングとクエリ プランをオンにしてください。

下部にある「サーバー タイミング」タブをクリックすると、最初のスキャンが強調表示されていることがわかります。これは、 CallBackDataIDが存在するためです。

xmSQL ステートメントでCallBackDataID を確認することもできます。メジャー内のIF関数はストレージ エンジンの能力を超えているため、数式エンジンの助けを求めます。

パフォーマンスの問題を解決する方法

CallBackDataIDを持たないクエリを実行すると、スキャンが強調表示されなくなっていることがわかります。

これは、 CALCULATEフィルターがストレージ エンジンにプッシュダウンされているためです。単独で機能するため、フォーミュラ エンジンの助けはもう必要ありません。

可能な限り、CALCULATEでフィルターを使用するようにしてください。ほとんどの作業をストレージ エンジンにプッシュすることで DAX のパフォーマンスを最適化し、処理を高速化します。

LuckyTemplates のストレージ エンジン – LuckyTemplates でのVertiPaq オペレーターとクエリの測定: 最適化のヒントとテクニック
DAX Studio の VertiPaq Analyzer | LuckyTemplates チュートリアル

結論

クエリが複雑すぎてストレージ エンジンが動作しない場合、パフォーマンスに影響が出る可能性があります。計算にCallBackDataIDなどの不要なプロセスが含まれるため、DAX の速度が低下します。CALCULATEでフィルターを使用すると、この問題を軽減できます。