継続的マテリアライズドビュー

このドキュメントでは、継続的マテリアライズドビューの概要と一般的なユースケースについて説明します。このページをお読みになる前に、 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 クライアントライブラリを使用した ReadRows API 呼び出し

詳細については、継続的マテリアライズドビューから読み取るをご覧ください。

継続的マテリアライズドビューを使用する場合

継続的マテリアライズドビューを使用すると、SQL を使用して Bigtable データの新しい表現を定義できます。作成後、継続的マテリアライズドビューは、ソーステーブルのデータを SQL クエリで定義された形式に継続的かつ自動的に再構築します。その後、テーブルにクエリを実行してデータを読み取った後に変換または集計するのではなく、継続的マテリアライズドビューにクエリを実行できます。

継続的マテリアライズドビューを使用すると、次のユースケースでクエリのパフォーマンスを改善できます。

データの事前集計: 継続的マテリアライズドビューを使用して、行全体の受信データを集計できます。これにより、ダッシュボードの指標などの集計データをすばやく取得できます。
Lambda アーキテクチャと Kappa アーキテクチャの自動化: アプリケーションで、リアルタイムストリーミングパイプラインデータと過去のデータを含むバッチパイプラインデータの組み合わせが必要な場合は、継続的マテリアライズドビューを使用します。これらのビューは、追加のストリーム処理ツールやカスタム ETL ジョブを必要とせずに、基盤となるデータの変更を反映するように時間とともに更新されるすべてのデータソースのビューを提供します。
セカンダリアクセスパターン: 継続的マテリアライズドビューは、データの代替表現を作成します。この表現は、ソーステーブルに対するクエリで使用するルックアップパターンとは異なるルックアップパターンを持つクエリ用に最適化できます。これにより、継続的マテリアライズドビューは、データの非同期セカンダリインデックスを効果的に作成するための強力なツールになります。これらのパターンの詳細については、非同期セカンダリインデックスを作成するをご覧ください。

継続的マテリアライズドビューと他のタイプの Bigtable ビューを比較するには、テーブルとビューをご覧ください。

カウンタを使用する場合

データを事前集計するもう 1 つの方法は、分散カウンタ を集計セルを使用して作成することです。

集計セルへの書き込みは、書き込み先のクラスタからすぐに読み取ることができます。継続的マテリアライズドビューは、データの書き込み後に処理され、最終的にソーステーブルと整合性が保たれます。

次の場合は、継続的マテリアライズドビューではなくカウンタを使用します。

フィルタを必要とせず、行をまたぐ必要のない集計
書き込み先のクラスタから書き込みをすぐに読み取る必要がある場合

次の場合は、継続的マテリアライズドビューを使用します。

集計に対するクエリに別のキーを生成する
ベーステーブルの変更が集計に反映されることを確認する
複数の行のデータを自動的に結合する

次のようなユースケースでは、カウンタと継続的マテリアライズドビューを組み合わせて使用します。

集計セルで最新の指標をキャプチャし、それらの指標の過去のロールアップを保持する
継続的マテリアライズドビューで指標を結合する

リソースのプロビジョニングとパフォーマンス

継続的マテリアライズドビューの継続的な処理は、優先度の低いバックグラウンドジョブとして行われます。そのため、クラスタのサイズが適切であれば、アプリケーションのパフォーマンスとソーステーブルの読み取り / 書き込みレイテンシへの影響は最小限に抑えられます。

継続的マテリアライズドビューのデータを最新の状態に保つための効果的な手法として、継続的マテリアライズドビューを含むインスタンスのクラスタで自動スケーリングを有効にします。自動スケーリングにより、処理オーバーヘッドを処理するのに十分なノードが自動的に追加され、不要になったら削除されます。これにより、継続的に実行される SQL クエリの実行中に十分なコンピューティング容量を確保できます。自動スケーリングにより、継続的マテリアライズドビューのストレージ要件に対応するのに十分なノードを確保することもできます。

継続的マテリアライズドビューは、インスタンスあたりのテーブル数 1,000 個の上限にカウントされます。

既存のテーブルに継続的マテリアライズドビューを作成する

既存のテーブルに継続的マテリアライズドビューを作成すると、Bigtable は、既存のテーブルデータでビューを設定する 1 回限りのプロセスを開始します。この初期設定にかかる時間は、テーブルのサイズとクエリの複雑さによって異なります。この間、ビューはクエリに使用できません。この初期データ設定は、クラスタのパフォーマンスへの影響を最小限に抑えるために、優先度の低いバックグラウンドジョブとして実行されます。大きなテーブルの場合は、ビューの作成を高速化するために、クラスタに一時的にノードを追加できます。

次の図は、継続的マテリアライズドビューの作成プロセスを示しています。

Bigtable で継続的マテリアライズドビューを作成するプロセス。 — **図 1.**Bigtable で継続的マテリアライズドビューを作成するプロセス（クリックして拡大）。

**図 1.**Bigtable で継続的マテリアライズドビューを作成するプロセス（クリックして拡大）。

たとえば、ソーステーブルに advertiser_id#region#ad_id パターンのキーを持つ行と、広告費用を表す数値データを含む spend_usd 列修飾子を含む data 列ファミリーが 1 つあるとします。

行キー	`data:spend_usd`
`adv1#us-east#ad1`	100
`adv1#us-west#ad2`	150
`adv2#us-east#ad3`	200

次のクエリを使用してこのテーブルの継続的マテリアライズドビューを定義すると、175 ノードのクラスタで 1 TB のデータの初期設定が約 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 時間で処理します。初期設定に必要な時間を短縮するには、クラスタに一時的にノードを追加するか、自動スケーリングを使用している場合は、一時的にノードの最大数を増やします。

ストレージ

継続的マテリアライズドビューごとに、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`	継続的マテリアライズドビューのシステムからのエラー数

また、多くの Bigtable テーブル指標を使用して、継続的マテリアライズドビューをモニタリングすることもできます。この場合、テーブル ID の代わりに継続的マテリアライズドビュー ID を使用します。特に、継続的マテリアライズドビューは CPU 指標の内訳に含まれているため、その影響を把握できます。Data API の ReadRows メソッドを使用して継続的マテリアライズドビューを読み取ると、1 秒あたりのリクエスト数、レイテンシ、スループットの Bigtable 指標が生成されます。詳細については、指標をご覧ください。

Cloud Logging の使用を開始するには、ログのクエリと表示の概要をご覧ください。

制限事項

テーブルごとに最大 5 つの継続的マテリアライズドビューを作成できます。必要に応じて、 Cloud カスタマーケアに連絡して、この上限の引き上げをリクエストできます。
_key を指定せずにビューを作成する場合、ソーステーブルで選択した列は NULL にすることはできません。詳細については、定義された行キー句をご覧ください。GROUP BY
継続的マテリアライズドビューを定義する SQL クエリを変更することはできません。継続的マテリアライズドビューを削除し、変更を加えて新しいビューを作成する必要があります。
別の継続的マテリアライズドビューまたは論理ビューの継続的マテリアライズドビューを作成することはできません。
継続的マテリアライズドビューのガベージコレクションポリシーを構成することはできません。すべてのデータの保持はソーステーブルのガベージコレクションポリシーに則って管理され、ソースのガベージコレクションは継続的マテリアライズドビューに自動的に反映されます。

継続的マテリアライズド ビュー

継続的マテリアライズド ビューを使用する場合