このページは Cloud Translation API によって翻訳されました。

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

このドキュメントでは、継続的なマテリアライズドビューの概要と一般的なユースケースについて説明します。このページを読む前に、Bigtable の概要を理解する必要があります。

Bigtable の継続的マテリアライズドビューは、継続的に実行される SQL クエリの事前計算された結果であり、継続的マテリアライズドビューを増分更新します。SQL クエリには、基盤となる Bigtable テーブルの集計と変換を含めることができます。継続的なマテリアライズドビューを使用すると、パフォーマンスと効率を向上させることができます。

継続マテリアライズドビューのデータには次のものが含まれます。

ソーステーブルのデータから派生した集計値または変換値
グループ化キーを定義する集計されていない値

継続的マテリアライズドビューを使用すると、データを取り込むときに事前集計できます。また、連続マテリアライズドビューのスキーマはソーステーブルとは異なるため、ソーステーブルで使用されるクエリとは異なるルックアップパターンのクエリ用に最適化された構造でソーステーブルデータを提示します。

Bigtable の継続的マテリアライズドビューの主な特長は次のとおりです。

メンテナンス不要: 継続的なマテリアライズドビューはバックグラウンドで事前に計算されます。更新や削除など、ベーステーブルのデータ変更は、ユーザーの操作なしでバックグラウンドで継続マテリアライズドビューに自動的に伝播されます。
SQL 開発パターン: 継続マテリアライズドビューは、SQL 関数、フィルタ、集計などの GoogleSQL for Bigtable クエリに基づいています。
ガベージコレクションとの同期: 継続マテリアライズドビューは、ソーステーブルのガベージコレクションポリシーと同期されたままになり、テーブルデータが期限切れになったり削除されたりするたびに自動的に更新されます。
読み取りと書き込みのレイテンシは影響を受けない: インスタンスのクラスタが適切にプロビジョニングされているか、自動スケーリングを使用している場合、継続的なマテリアライズドビューはソーステーブルのパフォーマンスにほとんど影響しません。
結果整合性: 継続的マテリアライズドビューはバックグラウンドで計算されます。継続的マテリアライズドビューの更新は遅れる場合がありますが、継続的マテリアライズドの結果は時間の経過とともに常に整合しています。

継続マテリアライズドビューは、Google Cloud CLI、 Google Cloud コンソールの Bigtable Studio クエリエディタ、Java と Go 用の Bigtable クライアントライブラリを使用して作成できます。

連続マテリアライズドビューから読み取るには、次のコマンドを使用します。

Bigtable Studio クエリエディタ
SQL クエリをサポートする Bigtable クライアントライブラリ
Java と Go 用の Bigtable クライアントライブラリを使用した ReadRows API 呼び出し

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

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

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

マテリアルビューを使用すると、次のユースケースでクエリのパフォーマンスを向上させることができます。

事前集計データ: 継続マテリアライズドビューを使用して、受信データを行間で集計できます。これは、ダッシュボードの指標など、要約された集計データをすばやく取得する場合に便利です。
ラムダアーキテクチャとカッパアーキテクチャの自動化: アプリケーションでリアルタイムストリーミングパイプラインデータと過去のデータを含むバッチパイプラインデータの組み合わせが必要な場合、継続的なマテリアライズドビューを使用すると、追加のストリーミング処理ツールやカスタム ETL ジョブを必要とせずに、すべてのデータソースの最終的な整合性のあるビューを取得できます。

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

カウンタを使用する場合

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

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

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

フィルタが不要で、行全体にまたがる必要のない集計
書き込みが行われたクラスタから書き込みをすぐに読み取る必要がある場合

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

集計に対してクエリを実行する際のキーを変更する
集計に反映されたベーステーブルの変更を確認する
複数の行のデータを自動的に結合する

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

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

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

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

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

マテリアルビューは、インスタンスあたり 1,000 テーブルの制限にカウントされます。

ストレージ

連続マテリアライズドビューごとに、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 の使用を開始するには、ログのクエリと表示の概要をご覧ください。

制限事項

継続的マテリアライズドビューを定義する SQL クエリは変更できません。継続マテリアライズドビューを削除し、変更を加えて新しいマテリアライズドビューを作成する必要があります。
別の継続的マテリアライズドビューまたは論理ビューの継続的マテリアライズドビューは作成できません。
継続マテリアライズドビューのガベージコレクションポリシーを構成することはできません。すべてのデータ保持はソーステーブルのガベージコレクションポリシーによって管理され、ソースのガベージコレクションは継続マテリアライズドビューに自動的に反映されます。