継続的マテリアライズド ビュー
このドキュメントでは、継続的なマテリアライズド ビューの概要と、その一般的なユースケースについて説明します。このページをお読みになる前に、Bigtable の概要を理解しておく必要があります。
Bigtable では、継続的マテリアライズド ビューは、継続的なフルマネージド バックグラウンド プロセスの結果です。このプロセスでは、指定された SQL クエリを使用して、Bigtable がソースデータの変更に応じて増分更新する事前計算テーブルを作成して維持します。SQL クエリには、基盤となる Bigtable テーブルの集計と変換を含めることができます。
継続的なマテリアライズド ビューのデータには、次のものが含まれます。
- ソーステーブルのデータから派生した集計値または変換値
- グループ化キーを定義する集計されていない値
継続的マテリアライズド ビューを使用すると、データを取り込むときにデータを事前集計できます。また、継続的マテリアライズド ビューはソーステーブルとは異なるスキーマを持ち、ソーステーブルのデータは、ソーステーブルで使用されるクエリとは異なるルックアップ パターンを持つクエリ用に最適化された構造で表示されます。
Bigtable の継続的マテリアライズド ビューの主な特長は次のとおりです。
- メンテナンス不要: 継続的マテリアライズド ビューはバックグラウンドで事前に計算されます。更新や削除など、ソーステーブルに対するデータ変更は、バックグラウンドで自動的に継続的マテリアライズド ビューに反映されます。ユーザーが操作する必要はありません。
- SQL 開発パターン: 継続的マテリアライズド ビューは、SQL 関数、フィルタ、集計など、Bigtable クエリ用の GoogleSQL に基づいています。関数はデフォルトで決定的ですが、限定されたユースケースでは、厳選された非決定的関数を使用するようにオプトインできます。
- ガベージ コレクションとの同期: 継続的なマテリアライズド ビューは、ソーステーブルのガベージ コレクション ポリシーと同期を維持し、テーブルデータの有効期限が切れたり削除されたりすると自動的に更新されます。
- 読み取りと書き込みのレイテンシは影響を受けない: インスタンスのクラスタが適切にプロビジョニングされているか、自動スケーリングを使用している場合、継続的マテリアライズド ビューがソーステーブルのパフォーマンスに与える影響は最小限に抑えられます。
- 結果整合性: 継続的マテリアライズド ビューはバックグラウンドで計算されます。継続的マテリアライズド ビューの更新が遅れることがありますが、継続的マテリアライズドの結果は常に一貫しています。
継続的なマテリアライズド ビューの定義に使用する行キー、列修飾子、列値は、サービスデータとして扱われます。このため、機密情報を含む行キー、列修飾子、列値を使用して、継続的なマテリアライズド ビューを作成しないでください。サービスデータが取り扱われる方法については、Google Cloud のプライバシーに関するお知らせをご覧ください。
継続的なマテリアライズド ビューは、Google Cloud CLI、 Google Cloud コンソールの Bigtable Studio クエリエディタ、または Java と Go 用の Bigtable クライアント ライブラリを使用して作成できます。
継続的なマテリアライズド ビューから読み取るには、次のものを使用します。
- Bigtable Studio クエリエディタ
- SQL クエリをサポートする Bigtable クライアント ライブラリ
- Java および Go 用の Bigtable クライアント ライブラリを使用した
ReadRowsAPI 呼び出し
詳細については、継続的なマテリアライズド ビューからの読み取りをご覧ください。
継続的マテリアライズド ビューを使用する場合
継続的マテリアライズド ビューを使用すると、SQL を使用して Bigtable データの新しい表現を定義できます。作成された継続的マテリアライズド ビューは、ソーステーブルのデータを SQL クエリで定義された形式に継続的かつ自動的に再構築します。その後、テーブルにクエリを実行して、読み取り後にデータを変換または集計する代わりに、継続的なマテリアライズド ビューにクエリを実行できます。
継続的マテリアライズド ビューを使用すると、次のユースケースでクエリのパフォーマンスを改善できます。
- データの事前集計: 継続的なマテリアライズド ビューを使用して、受信データを複数の行にわたって集計できます。これにより、ダッシュボードの指標などの要約データや集計データをすばやく取得できます。
- ラムダ アーキテクチャとカッパ アーキテクチャの自動化: アプリケーションで、リアルタイム ストリーミング パイプライン データと、過去のデータを含むバッチ パイプライン データの組み合わせが必要な場合は、継続的なマテリアライズド ビューを使用します。これらのビューは、追加のストリーム処理ツールやカスタム ETL ジョブを必要とせずに、基盤となるデータの変更を反映して時間の経過とともに更新されるすべてのデータソースのビューを提供します。
- セカンダリ アクセス パターン: 継続的マテリアライズド ビューは、データの代替表現を作成します。この表現は、ソーステーブルに対するクエリで使用するルックアップ パターンとは異なるルックアップ パターンを持つクエリ用に最適化できます。これにより、継続的マテリアライズド ビューは、データに非同期セカンダリ インデックスを効果的に作成するための強力なツールになります。これらのパターンの詳細については、非同期セカンダリ インデックスを作成するをご覧ください。
継続的マテリアライズド ビューと他のタイプの Bigtable ビューを比較するには、テーブルとビューをご覧ください。
カウンタを使用するタイミング
データを事前集計するもう 1 つの方法は、集計セルを使用して分散カウンタを作成することです。
集計セルへの書き込みは、書き込まれたクラスタからすぐに読み取ることができます。継続的マテリアライズド ビューは、データが書き込まれた後に処理され、最終的にソーステーブルと整合します。
次の場合は、継続的マテリアライズド ビューではなくカウンタを使用します。
- フィルタを必要とせず、行をまたぐ必要がない集計。
- 書き込み先のクラスタから書き込みをすぐに読み取る必要がある場合。
継続的マテリアライズド ビューは、次の場合に使用します。
- 集計に対するクエリ用に別の鍵を生成します。
- ベーステーブルの変更が集計に反映されていることを確認します。
- 複数の行にわたるデータを自動的に結合します。
次のようなユースケースでは、カウンタと継続的なマテリアライズド ビューを組み合わせて使用します。
- 集計セルで最新の指標をキャプチャしますが、それらの指標の過去のロールアップは保持します。
- 継続的マテリアライズド ビューで指標を組み合わせる。
リソースのプロビジョニングとパフォーマンス
継続的マテリアライズド ビューの継続的な処理は、低優先度のバックグラウンド ジョブとして行われます。その結果、クラスタのサイズが適切であれば、アプリケーションのパフォーマンスとソーステーブルの読み取り / 書き込みレイテンシへの影響は最小限に抑えられます。
継続的マテリアライズド ビューのデータを最新の状態に保つためのベスト プラクティスとして、継続的マテリアライズド ビューを含むインスタンスのクラスタで自動スケーリングを有効にします。自動スケーリングでは、処理オーバーヘッドを処理するのに十分なノードが自動的に追加され、不要になると削除されます。これにより、継続的に実行される SQL クエリの実行中に十分なコンピューティング容量を確保できます。自動スケーリングにより、継続的なマテリアライズド ビューのストレージ ニーズを処理するのに十分なノードを確保することもできます。
継続的マテリアライズド ビューは、インスタンスあたり 1,000 テーブルの上限にカウントされます。
既存のテーブルに継続的マテリアライズド ビューを作成する
既存のテーブルに継続的マテリアライズド ビューを作成すると、Bigtable は、既存のテーブルデータでビューを埋める 1 回限りのプロセスを開始します。このプロセスは、初期入力と呼ばれます。初期入力に必要な時間は、テーブルのサイズとクエリの複雑さによって異なります。デフォルトでは、初期入力中にビューをクエリすることはできません。ただし、アプリケーション開発中など、不完全なデータを許容できるユースケースでは、allow_incomplete_view クエリヒントを使用して、データ入力が完了する前にビューをクエリできます。この間にビューが集計を実行すると、返される集計にはデータの一部のみが反映される可能性があります。詳細については、初期入力中にデータを読み取るをご覧ください。
この初期入力は、クラスタのパフォーマンスへの影響を最小限に抑えるため、優先度の低いバックグラウンド ジョブとして実行されます。大きなテーブルの場合は、クラスタに一時的にノードを追加して、ビューの作成を高速化できます。
次の図は、継続的なマテリアライズド ビューを作成するプロセスを示しています。
たとえば、ソーステーブルに、advertiser_id#region#ad_id パターンに従うキーを持つ行と、広告費用を表す数値データを含む spend_usd 列修飾子を含む 1 つの列ファミリー data が含まれているとします。
| 行キー | data:spend_usd |
|---|---|
adv1#us-east#ad1 |
100 |
adv1#us-west#ad2 |
150 |
adv2#us-east#ad3 |
200 |
次のクエリを使用してこのテーブルの継続的なマテリアライズド ビューを定義すると、1 TB のデータの初期入力は 175 ノードのクラスタで約 3 時間で完了します。
SELECT
SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
count(*) AS count,
sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
FROM `$0`
GROUP BY advertiser_id
Bigtable は線形にスケーリングされるため、175 ノードのクラスタは、データが同様の形状であると仮定すると、2 TB のデータを約 6 時間、10 TB のデータを約 30 時間で処理します。初期入力に必要な時間を短縮するには、一時的にクラスタにノードを追加するか、自動スケーリングを使用している場合は一時的に最大ノード数を増やすことができます。
非確定的 SQL 関数
デフォルトでは、継続的なマテリアライズド ビューは、インスタンス内のすべてのクラスタで一貫した結果を保証するために、決定論的関数のみをサポートします。ただし、CLUSTER_ATTRIBUTE() などの非確定的関数を使用して、データを処理するクラスタでデータをフィルタリングすることもできます。詳細については、非決定的クエリをご覧ください。
これらの関数を使用するには、継続的なマテリアライズド ビューを作成するときに、セマンティクスの違いを認識する必要があります。詳細については、継続的なマテリアライズド ビューを作成するをご覧ください。
ストレージ
継続的マテリアライズド ビューごとに、Bigtable には次のものが保存されます。
- 継続的マテリアライズド ビューのデータ
- 中間ストレージ
他の Bigtable テーブルと同様に、継続的マテリアライズド ビューは、それを含むインスタンス内のすべてのクラスタに存在します。インスタンス内のクラスタには、ソーステーブルと、そのテーブルに基づく継続的なマテリアライズド ビューを保存するのに十分なノードが必要です。自動スケーリングを使用すると、ストレージ要件の変化に応じてクラスタのサイズをスケールアップまたはスケールダウンできます。
継続的なマテリアライズド ビューのストレージはソーステーブルとは異なりますが、継続的なマテリアライズド ビューはソーステーブルと同じインスタンスに作成する必要があります。
継続的マテリアライズド ビューのストレージ
継続的マテリアライズド ビューには、継続的マテリアライズド ビューの基となる SQL クエリの結果データが含まれます。つまり、SQL クエリの集計句で定義された集計値と、グループ化キーを定義する非集計値が含まれます。
中間ストレージ
継続的なマテリアライズド ビューとソーステーブルの同期をサポートするため、Bigtable は中間ストレージを使用して、継続的なマテリアライズド ビューを増分アップデートするために必要なデータのコピーを保存します。
中間ストレージ内のデータ量は、継続的なマテリアライズド ビューを定義する SQL クエリの結果を生成するためにソーステーブルでスキャンされるデータ量とほぼ同じです。たとえば、クエリがテーブル全体でデータを集計する場合、Bigtable はテーブル全体に相当するデータを中間ストレージに保持します。特定の行キー範囲または列のクエリに基づく継続的なマテリアライズド ビューでは、それらの行または列のみが中間ストレージに保持されます。
中間ストレージは、継続的マテリアライズド ビューの存続期間中保持され、ビューの増分アップデートを効率的にサポートし、ソーステーブルから継続的マテリアライズド ビューに削除を伝播します。中間ストレージのデータは読み取れません。中間ストレージの使用状況に関する分析情報については、継続的なマテリアライズド ビューの指標をご覧ください。
レプリケーション
レプリケーションを使用するインスタンスでは、継続的マテリアライズド ビューはテーブルと同じ方法で複製されません。代わりに、インスタンス内の各クラスタは、ソーステーブルの独自のコピーを使用して、継続的なマテリアライズド ビューを個別に処理します。たとえば、クラスタ A のソーステーブルに書き込まれたデータは、クラスタ B のテーブルにレプリケートされ、クラスタ B の継続的なマテリアライズド ビューにレプリケートされます。
費用
継続的なマテリアライズド ビューの使用にリソースごとの費用はかかりません。ただし、継続的マテリアライズド ビューの作成と同期には処理とストレージが必要であり、標準料金が課金されます。継続的なマテリアライズド ビューを作成すると、次の項目が増加する可能性があります。
- ストレージ - 継続的なマテリアライズド ビューにデータを保存する場合と、中間ストレージにデータを保存する場合に課金されます。詳細については、ストレージをご覧ください。
- コンピューティング - ソーステーブルと継続的なマテリアライズド ビューの継続的な同期には CPU 処理が必要です。追加のバックグラウンド処理を処理するために、クラスタにさらに多くのノードが必要になる場合があります。
同時に、ソーステーブルでの処理が減少する可能性があります。たとえば、データの範囲スキャンを実行して、繰り返しの計算やその他の効率の低いクエリを実行しなくなった場合などです。また、Dataflow や Spark などのパイプライン ジョブを実行してソースデータを集計し、Bigtable に書き戻す必要がなくなる場合もあります。
料金の詳細については、Bigtable の料金をご覧ください。継続的なマテリアライズド ビューの使用状況をモニタリングするのに役立つ指標については、指標をご覧ください。
指標
継続的マテリアライズド ビューは、継続的マテリアライズド ビューのモニタリングに使用できるいくつかの主要な指標を Cloud Logging に報告します。
| 指標 | 説明 |
|---|---|
materialized_view/max_delay |
継続的マテリアライズド ビューの処理遅延の上限 |
materialized_view/storage |
継続的なマテリアライズド ビュー ストレージに使用されるデータ量（バイト単位） |
materialized_view/intermediate_storage |
継続的なマテリアライズド ビューの中間処理で使用されるデータ量（バイト単位） |
table/materialized_view_intermediate_storage |
このテーブルで定義された継続的なマテリアライズド ビューの中間処理で使用されるデータ量 |
materialized_view/user_errors |
継続的マテリアライズド ビューのユーザーデータのエラー数。ユーザーエラーにより、データがビューに反映されない。 |
materialized_view/system_errors |
継続的マテリアライズド ビューのシステムエラーの数 |
また、テーブル ID の代わりに継続的なマテリアライズド ビュー ID を使用して、多くの Bigtable テーブル指標を使用して継続的なマテリアライズド ビューをモニタリングすることもできます。特に、継続的なマテリアライズド ビューは CPU 指標の内訳に含まれているため、その影響を把握するのに役立ちます。1 秒あたりのリクエスト数、レイテンシ、スループットの Bigtable 指標は、Data API の ReadRows メソッドを使用して継続的なマテリアライズド ビューを読み取るときに生成されます。詳細については、指標をご覧ください。
Cloud Logging の使用を開始するには、ログのクエリと表示の概要をご覧ください。
制限事項
- インスタンスごとに最大 50 個の継続的マテリアライズド ビューを作成できます。
- テーブルごとに最大 5 つの継続的マテリアライズド ビューを作成できます。必要に応じて、Cloud カスタマーケアに連絡して、この上限の引き上げをリクエストできます。
_keyを指定せずにビューを作成する場合、ソーステーブルで選択した列はNULLにできません。詳細については、GROUP BY句またはORDER BY句で定義された行キーをご覧ください。- 継続的マテリアライズド ビューを定義する SQL クエリは変更できません。継続的なマテリアライズド ビューを削除し、変更を加えた新しいビューを作成する必要があります。
- 別の継続的マテリアライズド ビューまたは論理ビューの継続的マテリアライズド ビューを作成することはできません。
- 継続的マテリアライズド ビューを定義するクエリでは、
SELECT *を使用できません。 - 継続的なマテリアライズド ビューにガベージ コレクション ポリシーを構成することはできません。すべてのデータの保持は、ソーステーブルのガベージ コレクション ポリシーに則って管理され、ソースのガベージ コレクションは継続的マテリアライズド ビューに自動的に反映されます。
- マイクロ秒単位のタイムスタンプ粒度のテーブルに継続的マテリアライズド ビューを作成することはできません。