はじめに
世の中は現地時間2025/07/15-2025/07/16に行われたAWS Summit New York City 2025で発表されたアップデートの話題（特にBedrock系）で持ちきりですが、Redshift関連の「カスケードリフレッシュ」というアップデートを試してみます。
アップデート内容ついて
タイトルとしては、『Amazon Redshiftは、ネストされたマテリアライズドビューのカスケードリフレッシュのサポートを発表しました』、というリリースになっています。
従来のRedshiftのマテリアライズドビューリフレッシュ方針
従来、例えば下図のテーブルtにINSERTやUPDATEなどのデータ更新があった時、末端のマテビューwにデータ更新を反映するには、「順番に」更新①〜③までをREFRESH MATERIALIZED VIEWする必要がありました。
一応厳密にいうと、AUTO REFRESHという機能を使えば、テーブルtを直接参照しているマテビューuについては一定の制約下で自動更新することができますが（更新①部分）、仮にv,wにAUTO REFRESHを入れたとしてもマテビューuのリフレッシュは伝播しないため更新②、③は必ず順に、実行される必要がありました。
新機能「カスケードリフレッシュ」でのマテリアライズドビューリフレッシュ方針
今回の新機能のCASCADE REFRESHを使えば、下記のようにマテビューwを指定してリフレッシュをかけるだけで、基底のマテビューuから順に自動更新をかけてくれる、ということができるようになりました。
REFRESH MATERIALIZED VIEW w CASCADE;
ちなみに、vをカスケードリフレッシュすれば、u,vが順番にリフレッシュされ、wはリフレッシュ対象にはなりません。
ネスト（入れ子）マテリアライズドビューの利点
そもそもの話として、あえてマテリアライズドビューを入れ子にする必要は？運用上どんな利点があるの？という疑問もあるかもしれませんが、以下のような利点があります。
-
マテリアライズドビューの再利用性を高める
▶︎ あるマテビューの変換、集計結果を再利用できることによって、アクセス権限ごとのマテビューを作成するなど、柔軟な要求に応えることができる -
各マテビューの複雑化を避ける
▶︎ 同じ変換、集計のクエリを複数のマテビューに書かなくても良くなる
上記利点を失うことなく、最大限リフレッシュの運用負荷を下げられるのが今回の「カスケードリフレッシュ」です。
実際の環境で試してみる
1 . テーブルとマテリアライズドビューを作成
-- テーブル t の作成
DROP TABLE IF EXISTS t CASCADE;
CREATE TABLE t (
id INTEGER,
name VARCHAR(50),
value INTEGER,
updatetime TIMESTAMP
);
-- テストデータ挿入
INSERT INTO t VALUES
(1, 'item1', 100, '2025-07-16 00:00:00'),
(2, 'item2', 100, '2025-07-16 00:00:00'),
(3, 'item3', 100, '2025-07-16 00:00:00');
-- マテリアライズドビュー作成
CREATE MATERIALIZED VIEW u AS SELECT * FROM t;
CREATE MATERIALIZED VIEW v AS SELECT * FROM u;
CREATE MATERIALIZED VIEW w AS SELECT * FROM v;
2 . 初期状態の確認
SELECT 'テーブル t' AS source, * FROM t
UNION
SELECT 'マテビュー u' AS source, * FROM u
UNION
SELECT 'マテビュー v' AS source, * FROM v
UNION
SELECT 'マテビュー w' AS source, * FROM w ORDER BY source,id;
3 . テーブルtのデータ更新
UPDATE t SET value = 200,updatetime = CURRENT_TIMESTAMP
WHERE id = 1;
テーブルだけが更新されて、マテビューの結果には反映されていないことがわかります。
4 . （新機能を使わず）マテビューwをリフレッシュしてみる
REFRESH MATERIALIZED VIEW w;
マテビューwは更新されているけど、依存しているマテビューが最新ではないよ、と教えてくれます。
実際、w含めてテーブルの更新は反映できていません。
5 . マテビューwをカスケードリフレッシュしてみる
REFRESH MATERIALIZED VIEW w CASCADE;
先ほどと異なり、正常終了しました。データはというと・・・
期待通り、マテビューu,v,wが１つのリフレッシュコマンドで更新できていました！！
終わりに
今回のアップデートで末端のマテリアライズドビューのみをリフレッシュするだけで、依存するマテリアライズドビュー全てを更新できることがわかりました。末端さえリフレッシュすればOK、と認識しておけば、リフレッシュバッチの設計も大幅に単純化することができ、運用のオーバーヘッドをかなり減らすことができると思いました！
また将来的なこととしては、AUTO REFRESHがネストのマテリアライズドビューにも伝播させられるような設定ができればもっと便利になりそうだなぁ、という感想を持ちました。（設計思想の問題もあるかと思いますが）
小ネタ
ちなみに2025年7月17日現在、Redshift query editor v2は、この構文を不正なものとして認識しているようです。恐れずに実行しましょう。
