次の方法で共有

具体化されたビュー

  • [アーティクル]

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヒント

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

  • 具体化されたビューは、クラスター間またはデータベース間のクエリに参与しますが、ワイルドカードのユニオンまたは検索には含まれません。

    • 次の例はすべて、 という名前の具体化されたビューを含みますViewName。
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • 次の例では、具体化されたビューのレコードは含 まれません 。
    cluster('cluster1').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 具体化されたビュー*のクエリ*のシャッフルを強制し、 (必要に応じて) シャッフル用の特定のキー*を提供します。 以下の例を参照してください。

例

  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

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

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

  • クラスター* リソース*: クラスター*で実行*されている他のプロセス*と同様に、具体化されたビュー*はクラスター*のリソース* (CPU*、メモリ*) を消費します。 クラスター*がオーバーロード*になっている場合に具体化されたビュー*を追加すると、クラスター*のパフォーマンス*を低下させる可能性があります。 クラスター*正常性メトリック*を使用してクラスター*の正常性をモニターします。 最適化された自動スケールでは、現在、自動スケールルールの一部として、具体化されたビューの正常性を考慮しません。

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

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

  • クラスター*内の具体化されたビュー*の数: 上記の考慮事項は、クラスター*で定義された個々の具体化されたビュー*に適用されます。 各ビューは独自のリソースを消費し、多くのビューは使用可能なリソースで互いに競合します。 クラスター内の具体化されたビューの数に対するハードコーディングされた制限はありませんが、多数の具体化されたビューが定義されたとき、クラスターは具体化されたビューをすべて処理できない可能性があります。 クラスター内に具体化されたビューが複数ある場合、容量ポリシーを調整できます。 さらに具体化されたビュー*を同時に実行する*には、ポリシー*における ClusterMinimumConcurrentOperations の値を大きくします。

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

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

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

ヒント

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

関連コンテンツ