Power BI Desktop でストレージ モードを管理する
Microsoft Power BI Desktop では、テーブルのストレージ モードを指定できます。 ストレージ モードを使用すると、Power BI Desktop でレポートのテーブル データをメモリ内にキャッシュするかどうかを制御できます。 キャッシュとは、データをメモリに一時的に格納することを意味します。
ストレージ モードを設定すると、多くの利点があります。 モデルでは、各テーブルのストレージ モードを個別に設定できます。 このアクションにより、1 つのセマンティック モデルが有効になり、次の利点が得られます。
クエリ パフォーマンス: ユーザーが Power BI レポートでビジュアルを操作すると、データ分析式 (DAX) クエリがセマンティック モデルに送信されます。 ストレージ モードを適切に設定してデータをメモリにキャッシュすると、レポートのクエリパフォーマンスと対話機能が向上します。
大規模なセマンティック モデル: キャッシュされていないテーブルは、キャッシュのためにメモリを消費しません。 メモリに完全にキャッシュするには大きすぎる、またはコストが高すぎる大規模なセマンティック モデルに対して対話型分析を有効にすることができます。 キャッシュする価値のあるテーブルとそうでないテーブルを選択できます。
データ更新の最適化: キャッシュされていないテーブルを更新する必要はありません。 更新時間を短縮するには、サービス レベル アグリーメントとビジネス要件を満たすために必要なデータのみをキャッシュします。
ほぼリアルタイムの要件: ほぼリアルタイムの要件を持つテーブルは、データ待ち時間を短縮するために、キャッシュされないという利点があります。
書き戻し: 書き戻しを使用すると、ビジネス ユーザーはセル値を変更して What-if シナリオを調べることができます。 カスタム アプリケーションは、データ ソースに変更を適用できます。 キャッシュされていないテーブルは、変更をすぐに表示できるため、効果をすぐに分析できます。
Power BI Desktop のストレージ モード設定は、次の 3 つの関連機能のいずれかです。
複合モデル: レポートに、DirectQuery 接続やインポートなどの 2 つ以上のデータ接続を任意の組み合わせで使用できます。 詳細については、「Power BI Desktopで複合モデルを使用する」を参照してください。
多対多リレーションシップ : 複合モデルを使用すると、テーブル間で多対多リレーションシップを確立できます。 多対多リレーションシップでは、テーブル内の一意の値に対する要件が削除されます。 また、リレーションシップを確立するためだけに新しいテーブルを導入するなど、以前の回避策も削除されます。 詳細については、Power BI Desktopの「多対多リレーションシップ」を参照してください。 ストレージ モードの: ストレージ モードでは、バックエンド データ ソースに対するクエリを必要とするビジュアルを指定できるようになりました。 クエリを必要としないビジュアルは、DirectQuery に基づいている場合でもインポートされます。 この機能は、パフォーマンスの向上とバックエンドの負荷の軽減に役立ちます。 以前は、スライサーなどのシンプルな視覚化であっても、バックエンド ソースに送信されるクエリが開始されました。
ストレージ モード プロパティを使用する
ストレージ モード プロパティは、モデル内の各テーブルに設定できるプロパティであり、Power BI によるテーブル データのキャッシュ方法を制御します。
ストレージ モード プロパティを設定するか、現在の設定を表示するには:
モデル ビューで、プロパティを表示または設定するテーブルを選択します。
[のプロパティ] ウィンドウで、[詳細] セクションを展開し、[ストレージ モード] ドロップダウンを展開します。
ストレージ モードの プロパティは、次の 3 つの値のいずれかに設定します。
インポート: この設定でインポートされたテーブルがキャッシュされます。 インポート テーブルからデータを返す Power BI セマンティック モデルに送信されたクエリは、キャッシュされたデータからのみ実行できます。
DirectQuery: この設定のテーブルはキャッシュされません。 Power BI セマンティック モデル (DAX クエリなど) に送信し、DirectQuery テーブルからデータを返すクエリは、データ ソースに対してオンデマンド クエリを実行することによってのみ実行できます。 データ ソースに送信するクエリでは、そのデータ ソースのクエリ言語 (SQL など) が使用されます。
デュアル: この設定を持つテーブルは、Power BI セマンティック モデルに送信されるクエリのコンテキストに応じて、キャッシュされたテーブルまたはキャッシュされていないテーブルとして機能できます。 場合によっては、キャッシュされたデータからクエリを実行します。 それ以外の場合は、データ ソースに対してオンデマンド クエリを実行してクエリを実行します。
テーブルの ストレージ モードの を Import に変更することは、元に戻せない 操作です。 このプロパティを設定した後は、後で DirectQuery
手記
デュアル ストレージ モードは、Power BI Desktop と Power BI サービスの両方で使用できます。
DirectQuery テーブルとデュアル テーブルに関する制約
デュアル テーブルには、DirectQuery テーブルと同じ機能制約があります。 これらの制約には、計算列の制限付き M 変換と制限付き DAX 関数が含まれます。 詳細については、「DirectQuery の制限事項
[デュアル] 設定の伝達
すべてのテーブルが Import と DirectQuery をサポートする 1 つのソースからの次のモデルについて考えてみます。
このモデルのすべてのテーブルが最初に DirectQuery
ディメンション テーブル (Customer、Geography、および Date) を デュアル に設定して、セマンティック モデル内の制限されたリレーションシップの数を減らし、パフォーマンスを向上させることができます。 通常、制限付きリレーションシップには、結合ロジックをソース システムにプッシュできない DirectQuery テーブルが少なくとも 1 つ含まれます。 デュアル テーブルは DirectQuery テーブルまたはインポート テーブルとして機能できるため、この状況は回避されます。
伝達ロジックは、多数のテーブルを含むモデルに役立つよう設計されています。 50 個のテーブルを持つモデルがあり、特定のファクト (トランザクション) テーブルのみをキャッシュする必要があるとします。 Power BI Desktop のロジックでは、デュアルを
伝達ロジックは、一対多リレーションシップの一方の側にのみ走査されます。
ストレージ モードの使用例
次のストレージ モードのプロパティ設定を適用するとします。
| 表 | ストレージ モード |
|---|---|
| セールス | DirectQuery |
| SurveyResponse | 輸入 |
| 日付 | デュアル |
| 顧客 | デュアル |
| 地理学 | デュアル |
これらのストレージ モードのプロパティを設定すると、Sales テーブルのデータ量が大きいと仮定すると、次のような動作になります。
Power BI Desktop では、ディメンション テーブル、日付、Customer、Geographyがキャッシュされるため、表示するスライサー値を取得すると、初期レポートの読み込み時間が速くなります。
Power BI Desktop では、Sales テーブルはキャッシュされません。 Power BI Desktop では、このテーブルをキャッシュしないことで、次の結果が得られます。
- データ更新時間が短縮され、メモリ消費量が削減されます。
- Sales テーブルに基づくレポート クエリは、DirectQuery モードで実行されます。 キャッシュの待機時間が発生しないため、これらのクエリには時間がかかる場合がありますが、リアルタイムに近くなります。
SurveyResponse テーブルに基づくレポート クエリはメモリ内キャッシュから返されるため、比較的高速です。
キャッシュにヒットするクエリまたはヒットしないクエリ
Power BI Desktop の診断ポートに SQL Profiler を接続する場合は、次のイベントに基づくトレースを実行することで、メモリ内キャッシュにヒットまたはミスしたクエリを確認できます。
- Queries Events\Query Begin
- クエリ処理\Vertipaq SE クエリの開始
- クエリ処理\DirectQuery 開始
Query Begin イベントごとに、同じ ActivityID を使用して他のイベントを確認します。 たとえば、
デュアル テーブルを参照するクエリは、可能であればキャッシュからデータを返します。それ以外の場合は、DirectQuery に戻ります。
次のクエリは、前の表から続行されます。 これは、デュアル モードの Date テーブルからの列のみを参照します。 したがって、クエリはキャッシュにヒットする必要があります。
次のクエリは、DirectQuery モードの
次のクエリは、両方の列を組み合わせるので興味深いものです。 このクエリはキャッシュにヒットしません。 まず、キャッシュから CalendarYear 値を取得し、ソースから SalesAmount 値を取得して結果を結合すると期待されるかもしれませんが、このアプローチは、SUM/GROUP BY 操作をソースシステムに送信するよりも効率的ではありません。 操作がソースにプッシュダウンされた場合、返される行の数ははるかに少なくなる可能性があります。
手記
この動作は、Power BI Desktop でキャッシュされたテーブルとキャッシュされていないテーブルを組み合わせた場合、多対多リレーションシップ とは異なります。
キャッシュの同期を維持する必要がある
前のセクションに表示されたクエリは、デュアル テーブルがキャッシュにヒットすることがあり、ヒットしない場合があることを示しています。 その結果、キャッシュが古い場合は、異なる値を返すことができます。 クエリの実行では、たとえば、キャッシュされた値と一致するように DirectQuery の結果をフィルター処理することで、データの問題をマスクしようとはしません。 データ フローを把握するのはユーザーの責任であり、それに応じて設計する必要があります。 必要に応じて、ソースでこのようなケースを処理するための確立された手法があります。
デュアル ストレージ モードは、パフォーマンスの最適化です。 ビジネス要件を満たす能力を損なわない方法でのみ使用する必要があります。 別の動作については、Power BI Desktopの
テーブル ビュー
セマンティック モデル内の少なくとも 1 つのテーブルのストレージ モードが
テーブル ビューでデュアル テーブルとインポート テーブルを選択すると、キャッシュされたデータが表示されます。 DirectQuery テーブルにはデータが表示されません。DirectQuery テーブルを表示できないことを示すメッセージが表示されます。
考慮事項と制限事項
ストレージ モードの現在のリリースと複合モデルとの相関関係には、いくつかの制限があります。
次のライブ接続 (多次元) ソースは、複合モデルでは使用できません。
- SAP HANA
- SAP Business Warehouse
DirectQuery を使用してこれらの多次元ソースに接続する場合、別の DirectQuery ソースに接続したり、インポートされたデータと組み合わせたりすることはできません。
複合モデルを使用する場合、DirectQuery の使用に関する既存の制限は引き続き適用されます。 これらの制限の多くは、テーブルのストレージ モードに応じて、テーブルごとに適用されるようになりました。 たとえば、インポートされたテーブルの計算列は他のテーブルを参照できますが、DirectQuery テーブルの計算列は、同じテーブルの列のみを参照するように制限されます。 モデル内のいずれかのテーブルが DirectQuery の場合、モデル全体に他の制限が適用されます。
関連コンテンツ
複合モデルと DirectQuery の詳細については、次の記事を参照してください。
- Power BI Desktop で複合モデルを使用する
- Power BI Desktop で多対多リレーションシップを適用する
- Power BI の DirectQuery
- Power BI データ ソース