マテリアライズドビュー

マテリアライズドビューとは

マテリアライズドビュー (Materialized View) は、複雑なクエリの結果を事前に計算してテーブルとして保存し、読み取り時に再計算を不要にする仕組みである。通常のビュー (仮想テーブル) がクエリ実行時に毎回計算するのに対し、マテリアライズドビューは結果をディスクに保存する。

ビュー vs マテリアライズドビュー

ビューとマテリアライズドビューの違いを以下にまとめる。

観点	ビュー	マテリアライズドビュー
データ保存	なし (クエリ定義のみ)	あり (結果をディスクに保存)
読み取り速度	元のクエリをその場で実行するのと同じ	事前計算済みの分だけ速い
データの鮮度	常に最新	リフレッシュまで古い
ストレージ	不要	必要

PostgreSQL での使用

PostgreSQL での使用の例を示す。

-- マテリアライズドビューの作成
CREATE MATERIALIZED VIEW monthly_sales AS
SELECT
  date_trunc('month', created_at) AS month,
  product_id,
  SUM(amount) AS total_sales,
  COUNT(*) AS order_count
FROM orders
GROUP BY month, product_id;

-- 読み取り (事前計算済みなので高速)
SELECT * FROM monthly_sales WHERE month = '2026-03-01';

-- CONCURRENTLY を使うには列名だけの一意インデックスが必要
CREATE UNIQUE INDEX monthly_sales_key ON monthly_sales (month, product_id);

-- リフレッシュ (最新データで再計算)
REFRESH MATERIALIZED VIEW CONCURRENTLY monthly_sales;

PostgreSQL のリフレッシュは中身の全面的な作り直しで、変更分だけを反映する機能は無い。CONCURRENTLY を付けない REFRESH はビューへの読み取りをブロックするため、実行中の SELECT は待たされる。CONCURRENTLY を付ければ読み取りを止めずに済むが、条件が 2 つある。列名のみで構成され全行を含む一意インデックスが 1 つ以上あること (式インデックスや WHERE 付きの部分インデックスでは条件を満たさない)、そしてビューが既にデータを持っていることである。上の例で一意インデックスを先に作っているのはこのためで、これを忘れると REFRESH MATERIALIZED VIEW CONCURRENTLY はエラーになる。なお CONCURRENTLY でも、同じビューに対して同時に走らせられるリフレッシュは 1 つだけである。

DynamoDB でのマテリアライズドビュー

DynamoDB にはマテリアライズドビューの機能がないが、DynamoDB Streams + Lambda で同等の仕組みを構築できる。

[orders テーブル] → [DynamoDB Streams] → [Lambda] → [monthly_sales テーブル]

データベースごとの対応の差

対応状況はデータベースによって差が大きい。PostgreSQL はネイティブ対応だがリフレッシュは手動 (またはジョブでの定期実行) が基本で、Oracle は自動リフレッシュやクエリの自動書き換えまで踏み込んだ機能を持つ。MySQL にはネイティブのマテリアライズドビューがなく、集計テーブルをトリガーやバッチで自前維持するのが慣行だ。クラウド DWH (BigQuery、Redshift、Snowflake など) も各自の実装を持ち、増分更新の賢さが製品選定の比較点になる。「使っている DB で何がどこまで自動化されるか」を先に確認すると設計の手戻りが減る。

リフレッシュ戦略

リフレッシュ戦略を以下にまとめる。

戦略	説明	用途
完全リフレッシュ	全データを再計算	小〜中規模データ
差分リフレッシュ	変更分のみ更新	大規模データ
リアルタイム	イベント駆動で即座に更新	DynamoDB Streams
スケジュール	定期的に再計算	日次/時間ごとの集計

使うべきケース

使うべきケースを以下に示す。

適する用途	適さない用途
複雑な集計クエリが頻繁に実行される	データの鮮度が最重要
ダッシュボード、レポート	書き込みが読み取りより多い
読み取り性能が重要	ストレージコストが問題

理論と実装の両面から学ぶなら関連書籍が参考になる。