AnalyticDB:リアルタイムマテリアライズドビュー

仕組み

リアルタイムマテリアライズドビューは、2 種類のリフレッシュモードをサポートしています。整合性要件およびスループット要件に応じて、適切なモードを選択してください。

デフォルトモードを変更するには、チケットを送信チケットを送信してください。

同期モード

同期モードでは、MV の更新がベーステーブルへの書き込みと同一トランザクション内で実行されます。INSERT、COPY、UPDATE、または DELETE などの SQL ステートメントがベーステーブルに対して実行されると、データベースはまずベーステーブルを更新し、その後 MV を更新します。

• ベーステーブルへの書き込みが失敗した場合、MV は変更されません。

• MV の更新が失敗した場合、ベーステーブルへの書き込みもロールバックされ、書き込みステートメントはエラーを返します。

明示的なトランザクション（BEGIN/COMMIT）を使用する場合：

• READ COMMITTED 分離レベルでは、トランザクションがコミットされるまで、MV の更新は他のトランザクションから非表示になります。

• トランザクションをロールバックした場合、ベーステーブルおよび MV の両方がロールバックされます。

対応バージョン

同期モードは、以下の環境でデフォルト設定となります。

• AnalyticDB for PostgreSQL V7.0（V7.0.6.9 より前のインスタンス）

• AnalyticDB for PostgreSQL V6.0（V6.6.2.5 より前のインスタンス）

非同期モード

非同期モードでは、書き込みトランザクションは即時にコミットされます。その後、データベースがバックグラウンドで MV の更新をスケジュールします。複数の書き込みが同時に到着した場合、システムはそれらをまとめてバッチ処理するため、MV は個別の書き込みごとではなく、複数の書き込みを一度に反映することがあります。

この結果として得られるのは「結果整合性」であり、通常のシステム負荷下では、MV のデータは数秒以内にベーステーブルと一致します。この特性により、非同期モードは、ほとんどのリアルタイムデータウェアハウスのシナリオに適しています。

対応バージョン

非同期モードは、以下の環境で新規作成されるリアルタイムマテリアライズドビューのデフォルト設定となります。

• AnalyticDB for PostgreSQL V7.0（V7.0.6.9 以降のインスタンス）

• AnalyticDB for PostgreSQL V6.0（V6.6.2.5 以降のインスタンス）

リアルタイムマテリアライズドビューの作成および削除

作成

CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM base WHERE id > 40;

削除

DROP MATERIALIZED VIEW mv;

例

以下の例では、ベーステーブルを作成し、フィルター条件付きのリアルタイムマテリアライズドビューを作成した後、データを挿入して両方のテーブルをクエリし、増分更新の動作を確認します。

-- ステップ 1：ベーステーブルの作成
CREATE TABLE test (a int, b int) USING HEAP DISTRIBUTED BY (a);

-- ステップ 2：フィルター条件（b > 40）付きのリアルタイムマテリアライズドビューの作成
CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM TEST WHERE b > 40 DISTRIBUTED BY (a);

-- ステップ 3：ベーステーブルへの行の挿入
INSERT INTO test VALUES (1, 30), (2, 40), (3, 50), (4, 60);

-- ステップ 4：ベーステーブルのクエリ
SELECT * FROM test;

実行結果：

 a | b
---+----
 1 | 30
 2 | 40
 3 | 50
 4 | 60
(4 rows)

-- ステップ 5：マテリアライズドビューのクエリ
SELECT * FROM mv;

MV には、b > 40 の条件に合致する行のみが反映されます。

 a | b
---+----
 3 | 50
 4 | 60
(2 rows)

リアルタイムマテリアライズドビューの利用シーン

以下のすべての条件が満たされる場合に、リアルタイムマテリアライズドビューを有効に活用できます。

• 結果セットがベーステーブルに対して比較的小規模であること — フィルター条件により行数が大幅に絞り込まれている、集約操作により値がグループ化されている、あるいは半構造化データの分析によりコンパクトな結果が得られているなど。

• クエリの実行コストが高く、繰り返し実行するのに不経済であること — 集約操作に長時間を要し、事前に結果を計算しておくことでクエリ時間の短縮が可能である。

• 増分データ量が全データ量に比べて非常に小さいこと — 基本的にベーステーブルの大部分の行はクエリ間で変更されない。

また、外部スケジューラを用いずにリアルタイム ETL パイプラインを構築する必要がある場合にも、リアルタイムマテリアライズドビューは適しています。リアルタイムマテリアライズドビューを連鎖させることで、ベーステーブル上に 1 つ目のビューを作成し、そのビュー上にさらに別のビューを作成できます。ベーステーブルが変更されると、両方のビューが自動的に順次更新され、リアルタイムのワイドテーブル、集約結果、その他の変換結果を生成します。

標準のマテリアライズドビューとは異なり、リアルタイムマテリアライズドビューは、増分更新によって高いデータ整合性を維持しつつ、最小限のパフォーマンスオーバーヘッドで運用できます。一方、標準のマテリアライズドビューでは、ベーステーブルの変更ごとに手動による完全更新が必要であり、これはコストが非常に高くなります。リアルタイムマテリアライズドビューは、大量のデータ変更やストリーミング更新を伴うシナリオにおいて、はるかに優れたパフォーマンスを発揮します。

制限事項

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

リアルタイムマテリアライズドビューは、リアルタイムで維持されるインデックスと同様に機能します。つまり、読み取り性能を向上させる一方で、書き込みにオーバーヘッドを追加します。この書き込みオーバーヘッドは、以下の要素に依存します。

• クエリの複雑さおよびネスト深度：単一レイヤーのビュー（1 つのテーブル上、またはシンプルな JOIN）であれば、インスタンスサイズに応じて、1 秒あたり数十万～百万行程度の書き込みを処理可能です。一方、複雑な JOIN を含む深くネストされたビューでは、計算リソースの消費が大幅に増加します。

• JOIN 操作および書き込み増幅：大きなファクトテーブル（例：10 億行）と小さなディメンションテーブル（例：1 万行）を JOIN するビューの場合、ディメンションテーブルへの書き込みが大規模な再計算を引き起こし、書き込みスループットが著しく低下する可能性があります。

• 利用可能なインスタンスリソース：増分計算は他のワークロードとリソースを共有します。書き込みパフォーマンスが要件を満たさない場合は、計算リソースを増強することでスループットを向上させることができます。

次のステップ

• マテリアライズドビューの管理

• トランザクションの管理