増分マテリアライズドビュー

集計を毎回計算しないためのキャッシュ

分析基盤の集計クエリは高くつきます。「日次の商品別売上」を出すだけでも、数十億行のファクトテーブルを丸ごとスキャンし、グループ化して合算する。同じダッシュボードを100人が開けば、同じ重いスキャンが100回走る。ここで効くのがマテリアライズドビュー（materialized view, MV） です。

通常のビュー（論理ビュー）は、クエリの定義に名前を付けただけで、参照するたびに元のクエリが実行されます。対してマテリアライズドビューは、その結果を実体化（materialize）して物理的に保存します。読み取り側は、生のファクトテーブルではなく、すでに集計済みの小さな結果表を引くだけ。全行スキャンが1回の小さな索引アクセスに化けます。要は計算結果のキャッシュを、DBやウェアハウスが正規のオブジェクトとして管理する仕組みです。分析クエリがなぜスキャン中心で重いのかは /data-engineering/olap-vs-oltp/ に譲りますが、その重いスキャンを事前に済ませて畳み込んでおくのがMVの発想です。

フルリフレッシュの限界と増分の発想

最も素朴な最新化はフルリフレッシュ（完全再計算） です。ビュー定義のクエリをまるごと再実行し、結果表を丸ごと作り直す。常に正しい結果になりますが、コストは元クエリそのもの。1行変わっただけでも数十億行を再スキャンするので、頻繁に走らせれば鮮度は上がる代わりに計算費が青天井になります。

ここで発想を変えます。ベーステーブルの変更は普通、全体のごく一部です。ならば変わった差分（delta）だけから、ビューの差分だけを計算して適用すればいい。これが増分ビューメンテナンス（Incremental View Maintenance, IVM） です。ベース表の変更分を ΔBase、それに対応するビューの変更分を ΔView とすると、

フルリフレッシュ : View_new = Query(Base_new)         # 全体を作り直す
増分メンテナンス : ΔView = f(ΔBase, ...)              # 差分から差分を計算し
                  View_new = View_old (+) ΔView       # 既存結果に適用する

ΔBase が全体に対して十分小さければ、ΔView の計算はフルリフレッシュより桁違いに安くなります。IVMが成立するかは、この差分伝播関数 f がビュー定義の演算子ごとにきれいに書けるかにかかっています。

どの集計が増分化できるか：代数の問題

IVMの可否は「気合い」ではなく、集計関数が持つ代数的な性質で決まります。鍵は、差分を足し込む・差し引く操作だけで結果を更新できるかどうかです。

• 加法的で可逆な集計：COUNT と SUM が代表。行が1件増えれば結果に足し、1件消えれば引く。挿入も削除も、差分の値を加減するだけで正しい新値が得られます。AVG も、内部で SUM と COUNT を別々に保持すれば、両者を増分更新して割り算で復元できます。IVMが最も気持ちよく効く領域です。
• 加法的だが不可逆な集計：MIN と MAX が該当。挿入は簡単で「新値と現在値を比べて更新」で済みます。ところが削除が厄介です。現在の最大値そのものが消えると、次の最大が何かは残りのデータを見ないと分からない。差し引きでは決まらず、元データの再走査が要ります。純粋な差分だけでは閉じないのです。
• ホリスティックな集計：MEDIAN（中央値）や COUNT(DISTINCT ...)（正確な異なり数）のように、全データの分布を見ないと確定しないもの。これらは原理的に差分だけで更新できず、素朴なIVMの対象外です（近似構造や補助データを別に持てば緩和はできます）。

多くのウェアハウスやレイクハウスが「MVは自動で増分更新されるが、対応する集計・演算子には制限がある」と明記するのは、この代数的な壁が理由です。定義がその範囲を外れると、システムは黙ってフルリフレッシュに退避するか、増分維持そのものを拒否します。

差分をどう適用するか：追記型ストレージとの相性

ΔView を計算できても、それをベース側の変更と一貫して適用しなければ結果は壊れます。ここで効くのが、レイクハウスのテーブルフォーマットが持つスナップショットとMERGEの仕組みです。ベーステーブルのどの版（スナップショット）を入力にビューを更新したかを記録しておけば、次回はその版から現在までの差分だけを読み、ΔView を MERGE（upsert）でビューへ適用できます。既存ファイルを書き換えず追記とメタデータ差し替えで版を進める設計は /data-engineering/lakehouse-iceberg-delta/ が詳しく、「前回どこまで取り込んだか」を版で管理して増分を回す点は、パイプライン全体の冪等な差分適用と同じ思想です。

この「前回位置を覚えて差分だけ適用し、失敗しても同じ結果に収束させる」構図は、ETL/ELTの増分ロードとバックフィルの設計そのものです（/data-engineering/etl-elt-pipelines/）。MVの増分メンテナンスは、パイプラインの冪等な増分適用を、集計結果という特定の成果物に特化させたものと捉えると見通しがよくなります。

鮮度とコストのトレードオフ、そしてストリームへの連続

MVの設計は最終的に一つのトレードオフに帰着します。ビューを新鮮に保つほど、更新の計算コストと運用の複雑さが増す。 三つのつまみで妥協点を選びます。

1. リフレッシュ間隔（鮮度）。オンデマンド（クエリ時）／定期スケジュール／変更に即応の連続、の順に新鮮になり、その順にコストが上がります。「1時間ごとにフルリフレッシュ」で足りるBI用途に、秒単位の連続更新は過剰です。

2. 増分かフルか。差分が小さく集計が増分可能なら増分が圧勝。逆に、毎回ベースの大半が入れ替わるような更新パターンでは、補助状態の維持コストがかさみ、素直なフルリフレッシュのほうが安い局面すらあります。

3. 保持する状態量。IVMは速さの代償に補助状態（SUM と COUNT の分解、結合の中間結果など）を持ちます。鮮度を上げ、扱う集計を増やすほど、この状態のメモリ・ストレージが膨らみます。

連続化するとストリーム特有の課題も引き継ぎます。イベントは遅れて・順不同で届くので、いつビューを確定してよいかの判断（ウォーターマーク）や、遅延データによる後からの補正、結果の複数回発行と冪等な適用が必要になります。この意味論は /data-engineering/stream-watermarks-windowing/ の窓とウォーターマークの議論と地続きです。増分MVを「速い読み取りの道具」ではなく「鮮度・計算・状態の三者を、集計の代数構造とリフレッシュ間隔で調停する設計対象」として扱えるかが、上級者の分かれ目になります。

まとめ

• マテリアライズドビューは集計クエリの結果を実体化したキャッシュ。読み取りは事前計算済みの表を引くだけで速いが、本質的な難所はベース変更時にビューをいかに安く最新化するかにある。
• フルリフレッシュは常に正しいがベース全体の再計算コストがかかる。増分メンテナンス（IVM） は変更分 ΔBase からビューの差分 ΔView だけを計算・適用し、差分が小さいほど桁違いに安い。
• 増分化の可否は集計の代数的性質で決まる。SUM・COUNT は加減で更新でき最も相性が良い。MIN／MAX は削除で再走査が要り、MEDIAN などホリスティックな集計は差分だけでは閉じない。削除と結合が難度を跳ね上げる。
• 差分の一貫した適用は、テーブルフォーマットのスナップショット＋MERGEや、パイプラインの冪等な増分ロード／バックフィルと同じ思想の上に成り立つ。
• 設計は鮮度・計算コスト・状態量の三者のトレードオフ。リフレッシュ間隔を詰めた連続的な増分MVは、CDCの更新ストリームを入力にしたストリーミング連続集計に連続的につながり、ウォーターマークや冪等適用の課題を引き継ぐ。