具体化されたビュー

適用対象: ✅Microsoft Fabric✅Azure データ エクスプローラー

具体化されたビュー*では、ソース* テーブル*または別の具体化されたビュー*に対する集計*クエリ*が公開されます。

具体化されたビュー*は常に、集計*クエリ* (常に最新の状態) の最新の結果を返します。 具体化されたビュー*のクエリ*は、ソース* テーブル*上で直接集計*を実行する*よりもパフォーマンスが高くなります。

Note

• 具体化されたビューが自分に適しているかどうかを判断するには、具体化されたビューを確認 ケースを使用します。
• 具体化されたビューには、いくつかの 制限があります。 この機能を使用する前に、 パフォーマンスに関する考慮事項を確認してください。
• 必要に応じて、 update ポリシー 使用することを検討してください。 詳細については、「 マテリアル化されたビューと更新ポリシーを参照してください。
• Monitor 具体化されたビューの推奨事項に基づいて、具体化されたビューの正常性を監視します。

具体化されたビュー*を使用する理由は何でしょうか？

一般的に使用される集計の具体化されたビューにリソース (データ ストレージ、バックグラウンド CPU サイクル) を投資することで、次の利点が得られます。

• パフォーマンス*の向上: 具体化されたビュー*のクエリ*は、通常、同じ集計*関数*についてソース *テーブル*にクエリ*を実行する*よりも優れたパフォーマンス*を発揮します。

• 新しさ: 具体化されたビュー*のクエリ*は、具体化が最後に行われたときとは無関係に、常に最新の結果*を返します。 このクエリ*ではビュー*の具体化されたパーツ*と、まだ具体化されていないソース* テーブル*内のレコード* (delta のパーツ*) が結合されることで、常に最新の結果*を提供します。

• コスト削減: 具体化されたビューをクエリする は、ソース テーブルに対して集計を行うよりも消費するリソースが少なくなります。 集計*のみ必要な場合は、ソース* テーブル*のアイテム保持ポリシー*を減らすことができます。 この設定により、ソース* テーブル*のホット* キャッシュ* コストが削減されます。

ユース ケースの例については、「 具体化されたビューのユース ケースを参照してください。

具体化されたビュー*の仕組みについて

具体化されたビュー*は、2つのコンポーネント*で構成されます:

• マテリアル化パーツ - ソース テーブルから集計されたレコードを保持しているテーブル。既に処理されています。 このテーブルは、集計のgroup-by組み合わせごとに常に1つのレコードを保持します。
• デルタ -まだ処理されていない、ソーステーブル内の新たに取り込まれたレコード。

具体化されたビュー*に対してクエリを実行する*と、具体化されたパーツ*をデルタパーツ*と組み合わせ、集計*クエリ*の最新の結果を提供します。 オフライン具体化プロセスでは、 delta から具体化されたテーブルに新しいレコードが取り込まれると、既存のレコードが更新されます。 delta と materialized パーツの交差部分が大きく、多くのレコードで更新が必要な場合、これが具体化プロセスに悪影響を与える可能性があります。 このような状況のトラブルシューティング方法についてはモニターの具体化されたビューを参照してください。

具体化されたビュー*のクエリ

具体化されたビュー*に対してクエリを実行する*には、2つの方法があります:

• ビュー*全体のクエリ*: 具体化されたビュー*に対してその名前でクエリを実行する*と、テーブル*に対するクエリ*と同様に、具体化されたビュー*のクエリはビュー*の具体化されたパーツ*と、まだ具体化されていないソース* テーブル*内のレコード*を組み合わせます (delta)。

  • 具体化されたビューに対してクエリを実行すると、ソース テーブルに取り込まれたすべてのレコードに基づいて、常に最新の結果が返されます。 具体化されたビュー*における具体化されたパーツ*と具体化されていないパーツ*の詳細については、「具体化されたビュー*の仕組み」をご覧ください。
  • このオプションは、クエリ時に delta 部分を具体化する必要があるため、最適なパフォーマンスを発揮しない場合があります。 この場合のパフォーマンスは、ビューの経過時間とクエリで適用されるフィルターによって異なります。 具体化されたビュークエリオプティマイザーセクションには、ビュー全体に対してクエリを実行するときにクエリのパフォーマンスを向上させる方法が含まれます。

• 具体化されたパーツ*のみのクエリ*: ビュー*に対してクエリを実行する*もう1つの方法は、materialized_view()関数*を使用することです。 このオプションは、ビュー*の具体化されたパーツ*のみのクエリ*をサポート*するとともに、ユーザー*が許容できる最大待ち時間*を指定します。

  • このオプションは最新のレコードを返すことは保証されませんが、常にビュー全体に対してクエリを実行するよりもパフォーマンスが優れます。
  • この関数は、たとえばテレメトリダッシュボードなど、パフォーマンスのために新しさをいくらか犠牲にしても構わないと思っているシナリオに役立ちます。

ヒント

具体化されたパーツに対するクエリは、常にビュー全体に対してクエリを実行するよりも優れたパフォーマンスを発揮します。 ユースケースに該当する場合、常にmaterialized_view()関数を使用します。

• 具体化されたビューは、Eventhouse または複数データベースにまたがるクエリに参加しますが、ワイルドカード共用体や検索には含まれません。

  • 次の例では、名前ViewName具体化されたビューをすべて含みます。

  cluster("<serviceURL>").database('db').ViewName
  cluster("<serviceURL>").database('*').ViewName
  database('*').ViewName
  database('DB*').ViewName
  database('*').materialized_view('ViewName')
  database('DB*').materialized_view('ViewName')
  

  • 次の例 、具体化されたビューのレコード 含めることはできません。

  cluster("<serviceURL>").database('db').*
  database('*').View*
  search in (*)
  search * 
  

具体化されたビュークエリオプティマイザー

ビュー*全体に対してクエリを実行する*とき、具体化されたパーツ*はクエリ*のdelta実行中にと組み合わせられます。 これには、delta の集計と、具体化されたパーツ*との結合*が含まれます。

• 具体化されたビュー クエリのキーによるグループに対するフィルターがクエリに含まれている場合、ビュー全体のクエリのパフォーマンスが向上します。 .create materialized-viewパフォーマンスヒントセクションで、クエリパターンに基づいて具体化されたビューを作成する方法に関するその他のヒントをご覧ください。
• クエリ オプティマイザーは、クエリのパフォーマンスを向上させるために期待される集計/結合戦略を選択します。 たとえば、クエリをシャッフルするかどうかは、delta一部のレコードの数に基づいて決定されます。 次のクライアント要求プロパティは、適用される最適化をある程度制御します。 具体化されたビュークエリを使用してこれらのプロパティをテストし、クエリのパフォーマンスに与える影響を評価できます。

クライアント要求プロパティの名前	型	説明
materialized_view_query_optimization_costbased_enabled	bool	falseに設定する場合、具体化されたビュークエリでの集計／結合の最適化を無効にします。 既定の戦略を使用します。 既定値は true です。
materialized_view_shuffle	dynamic	具体化されたビュー*のクエリ*のシャッフルを強制し、 (必要に応じて) シャッフル用の特定のキー*を提供します。 以下の例を参照してください。

ingestion_time() 具体化されたビューのコンテキストでの関数

ingestion_time() 関数は、具体化されたビューのコンテキストで使用する場合、ビュー全体にクエリを実行 場合、null 値を返します。 ビューの具体化された部分に対してクエリを実行する場合、戻り値は具体化されたビューの種類によって異なります。

• 1 つの arg_max()/arg_min()/take_any() 集計を含む具体化されたビューでは、 ingestion_time() はソース テーブル内の対応するレコードの ingestion_time() と等しくなります。
• 他のすべての具体化されたビューでは、 ingestion_time() の値は、具体化のおおよその時間です (「具体化されたビューのしくみ」 参照)。

例

1. ビュー*全体に対してクエリ*を実行します。 ソース* テーブル*には最新のレコード*が含まれます:

   ViewName
   

2. 最後に具体化された時点に関係なく、ビュー*の具体化されたパーツ*のみに対してクエリ*を実行します。

   materialized_view("ViewName")
   

3. ビュー全体に対してクエリを実行し、shuffle戦略を使用する「ヒント」を提供します。 ソース* テーブル*には最新のレコード*が含まれます:

   • 例1: (hint.shufflekey=Id を使用するのと同様に) Id列*に基づいてシャッフルします:

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
   ViewName
   

   • 例2: (hint.strategy=shuffle を使用するのと同様に) すべてのキー*に基づいてシャッフルします:

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
   ViewName
   

パフォーマンスに関する考慮事項

具体化されたビュー*の正常性に影響を与える可能性がある主なコントリビューターは、次のとおりです:

• 具体化されたデータとの重複: 具体化中に、最後の具体化 (デルタ) を処理し、ビューに具体化した後、すべての新しいレコードをソース テーブルに取り込みます。 新しいレコードと既に具体化されたレコードとの交差が大きいほど、具体化されたビューのパフォーマンスが低くなります。 具体化されたビューは、(たとえば、arg_max ビュー内の) 更新されているレコードの数がソース テーブルの小さなサブセットである場合に最適に機能します。 すべてまたはほとんどの具体化されたビュー レコードを具体化サイクルごとに更新する必要がある場合、具体化されたビューは正常に機能ないことがあります。

• 取り込み率: 具体化されたビュー*のソース* テーブル*には、データ* ボリュームまたは取り込み率に対するハードコーディングされた制限はありません。 ただし、具体化されたビューの推奨取り込み率は、1～2GB/秒以下です。より高い取り込み率でも、うまく機能する可能性があります。 パフォーマンスは、データベースのサイズ、使用可能なリソース、および既存のデータとの交差の量によって異なります。

• 具体化されたビュー*の定義: 具体化されたビュー*の定義は、最適なクエリ* パフォーマンス*を得るためのクエリ*のベスト プラクティス*に従って定義する必要があります。 詳細については、「コマンド パフォーマンス* ヒントの作成」を参照してください。

具体化されたビューに対する具体化されたビュー

ソースの具体化されたビューが重複排除ビューである場合、具体化されたビューを別の具体化されたビュー上に作成できます。 具体的には、ソースレコードを重複排除するために、ソースの具体化されたビューの集計は、take_any(*)のように行う必要があります。 第2の具体化されたビューは、サポートされる集計関数を使用できます。 具体化されたビュー上に具体化されたビューを作成する方法の詳細については、.create materialized-viewコマンドを参照してください。

ヒント

別の具体化されたビュー上で定義された具体化されたビューに対してクエリを実行するとき、materialized_view()関数を使用してのみ具体化されたパーツに対してクエリを実行することをお勧めします。 両方のビューが完全に具体化されていない場合、ビュー全体のクエリは実行されません。 詳細については、具体化されたビュークエリを参照してください。

関連するコンテンツ

• 具体化されたビューのポリシー
• 具体化されたビューの制限事項と既知の問題
• 具体化されたビューのユース ケース
• マテリアライズドビューを監視する
• .create materialized view
• .alter materialized-view
• {.disable | .enable} materialized-view