LASSIC Media らしくメディア
マテリアライズドビューとは｜集計を事前計算
日次のダッシュボードや月次レポートで、同じ集計クエリを開くたびに表示が重い。システム開発の発注担当者やプロジェクトマネージャーであれば、こうした相談を受けた経験があるかもしれません。複数のテーブルを結合し大量の行を集計するクエリは、参照のたびに計算をやり直すため、データ量が増えるほど応答が遅くなっていきます。開発会社に相談しても「クエリを工夫すれば速くなる」と説明されるだけで、根本的な解決になっていないと感じるケースもあるでしょう。
この重い集計を、あらかじめ計算しておくことで参照時の負荷を抑える仕組みがマテリアライズドビューです。テーブル設計の考え方である正規化と非正規化の違いや、分析用途のOLAPと日常処理用のOLTPの違いは、それぞれ別のテーマとして扱うべき論点です。本稿では、重い集計を事前計算して読み取りを軽くする仕組みと、その裏側にある鮮度（データの古さ）のトレードオフに絞って整理します。開発会社からこの仕組みを提案されたときに、何を確認すればよいかが分かる状態を目指します。
目次
この記事のポイント
- マテリアライズドビューは、問い合わせの結果を実体（テーブル）として保存しておき、参照時に保存済みの結果を返す仕組みです。
- 通常のビューが参照のたびに計算をやり直すのに対し、事前計算によって参照時の応答を軽くできます。
- 元データの変更には自動で追随しないため、リフレッシュの方式とタイミングをあらかじめ設計しておく必要があります。
マテリアライズドビューとは
マテリアライズドビューとは、問い合わせの結果をあらかじめ計算して実体（テーブル）として保存しておき、参照時にその保存済みの結果を返す仕組みです。
通常のビューは、SQLの定義だけを保存しておき、参照されるたびに元のテーブルへ問い合わせて計算し直す一種の名前付きクエリにあたります。PostgreSQL公式ドキュメントは、マテリアライズドビューについて次のように説明しています。「その後直接更新することはできず、作成に使ったクエリはビューのクエリと同じ方法で保存される」。
ここでいう「実体化」とは、定義クエリを実行した結果を、独立したテーブルとしてディスク上に持つことを指します。Wikipedia日本語版でも、マテリアライズドビューはクエリの結果を実際のテーブルにキャッシュする方式として紹介されています。通常のビューが仮想的なテーブルであるのとは対照的だと整理できるでしょう。
この違いから、マテリアライズドビューは「計算結果そのものを持つビュー」と捉えると分かりやすいでしょう。結合や集計を伴う重いクエリほど、都度計算と事前計算の差が応答時間に表れます。
身近な例えでいえば、通常のビューは注文のたびに一から作る料理、マテリアライズドビューはあらかじめ仕込んでおいた総菜に近い関係です。仕込み(事前計算)をどのタイミングで行うかによって、出来立ての鮮度と提供までの速さのどちらを優先するかが変わってきます。
発注担当者やプロジェクトマネージャーがこの仕組みを理解しておく意味は、開発会社との会話の中にあります。「重い集計をマテリアライズドビューにする」という提案を受けたときは、応答速度と引き換えに何が犠牲になるかを押さえておく必要があります。そうすれば、リフレッシュ頻度や保存領域の見積もりを的確に確認できるでしょう。
重い集計を事前計算し負荷を抑える狙い
複数のテーブルを結合し、大量の行を集計するクエリは、データ量が増えるほど実行のたびに時間がかかるようになります。ダッシュボードや月次レポートのように、同じ集計結果を何度も参照する用途では、この計算を毎回くり返すこと自体が無駄になりやすいのです。
マテリアライズドビューは、この重い計算をあらかじめ実行しておき、その結果だけを保存しておく仕組みです。参照する側は保存済みの結果テーブルを読むだけで済むため、複雑な結合や集計を毎回処理する必要がなくなります。PostgreSQL公式ドキュメントでも、マテリアライズドビューに保存されたデータへのアクセスは元のテーブルへの直接アクセスより速いという説明です。ビュー経由でのアクセスと比べても、多くの場合その傾向は変わりません。
この仕組みを使わずに重い集計をアプリケーション側で都度実行し続けると、データ量の増加とともに応答時間が伸び、利用者の待ち時間が業務の妨げになりかねません。集計処理をどこで肩代わりさせるかは、システムの応答性能を左右する設計判断のひとつといえます。
ECサイトの売上集計画面というケースで考えてみましょう。注文テーブルと商品テーブル、店舗テーブルを結合して日別・店舗別の売上を出すクエリは、注文件数が増えるほど処理に時間がかかります。担当者が管理画面を開くたびにこの集計を一から実行していては、閲覧のたびに待ち時間が発生してしまうでしょう。
この集計をあらかじめマテリアライズドビューとして計算しておけば、管理画面側は保存済みの結果を読み込むだけで済みます。集計対象のテーブルが増えても、参照側の応答は保存済みデータの読み込み時間に留まるため、利用者が体感する速度は安定しやすくなるのです。
同じ効果を自前の仕組みで実現しようとすると、集計結果を保存する別テーブルを用意し、更新のタイミングをアプリケーション側で管理するキャッシュ層を組む必要があります。データベース側にすでに備わっているマテリアライズドビューの機能を使えば、この作り込みの手間の多くを省けるでしょう。
ビューとの違いは計算タイミングにある
マテリアライズドビューと通常のビューは、SQLの見た目こそ似ていますが、内部の動きはまったく異なります。両者の違いを、計算タイミング・応答速度・データの鮮度・保存領域・更新の負荷という5つの観点で整理しました。
見た目のSQL構文が近いために、開発者間の会話でも両者が混同されやすい点には注意が要ります。「ビューを作った」と聞いたときに、それが参照のたびに計算するものか、事前計算した結果を保存するものかで、後工程での性能特性がまったく変わってくるからです。
| 観点 | ビュー（通常） | マテリアライズドビュー |
|---|---|---|
| 計算タイミング | 参照のたびに計算する | あらかじめ計算し結果を保存する |
| 応答速度 | 元テーブルの規模に比例して遅くなりやすい | 保存済みの結果を読むため速い |
| データの鮮度 | 常に最新（元テーブルの内容をそのまま反映する）。 参照する時点の値がそのまま返る。 |
リフレッシュした時点の内容にとどまる。 元テーブルが変わっても即座には反映されない。 |
| 保存領域 | 追加のデータ領域はほぼ不要。 定義（クエリ）だけを保持する。 |
計算結果を保存する分、領域が増える。 方式によっては新旧データを一時的に二重に持つ。 |
| 更新の負荷 | 元テーブル更新時の追加負荷はない。 参照時に毎回計算コストがかかる。 |
リフレッシュの都度、計算コストが発生する。 参照時の負荷は保存済みデータの読み込みのみで済む。 |
表からも分かる通り、マテリアライズドビューは応答速度と引き換えに、鮮度と保存領域という代償を抱える仕組みです。下の図は、複数テーブルの集計結果を事前計算して保存し、参照時はその保存済みデータを返すという流れを表したものになります。
リフレッシュの方式が鮮度を左右する
マテリアライズドビューは、作成した時点の計算結果を保存するだけで、元テーブルが更新されても内容が自動で追随するわけではありません。PostgreSQL公式ドキュメントも、マテリアライズドビューに保存されたデータは常に最新とは限らないと明記しています。
内容を新しくするには、REFRESH MATERIALIZED VIEWコマンドなどでリフレッシュを実行する必要があります。PostgreSQLの公式リファレンスでは、このコマンドについて「マテリアライズドビューの内容をすべて置き換える」と説明されています。実行するたびに、定義クエリが再計算される仕組みです。
リフレッシュの方式には、大きく分けて手動実行・定期的なスケジュール実行・差分（増分）反映の3通りがあります。Oracle Databaseの公式ドキュメントでは、完全リフレッシュと高速リフレッシュ（増分更新）という区分が示されています。前者は定義クエリ全体を再実行するのに対し、後者は変更分だけを反映する仕組みです。後者のほうが、計算量を抑えられるとされています。
どの方式を選ぶにせよ、リフレッシュが終わるまでは古いデータが参照され続けます。「どこまでの古さなら業務上問題ないか」を要件として先に決めておく必要があるでしょう。注文確定後すぐに残高や在庫数を反映させたい画面のように、秒単位の鮮度が求められる処理には、この仕組みは向きません。
リフレッシュ中の挙動にも注意が必要です。PostgreSQLの通常のリフレッシュはマテリアライズドビュー全体を一度削除してから作り直すため、その間は参照がブロックされます。公式ドキュメントが示すCONCURRENTLYというオプションを使うと、他の利用者の参照を止めずにリフレッシュを進められるでしょう。ただしその際は、ユニークインデックスをあらかじめ用意しておく必要があります。
リフレッシュのタイミングは、深夜バッチでまとめて行うやり方と、一定間隔でスケジュール実行するやり方のどちらかを選ぶのが一般的です。データの更新頻度と参照側の許容範囲に応じて、どちらの運用が業務に合うかを検討することになります。
差分（増分）反映は、Oracle Databaseの公式ドキュメントで「マテリアライズドビューログ」と呼ばれる変更履歴の仕組みを使います。この仕組みにより、前回のリフレッシュ以降に生じた変更分だけを取り込みます。定義クエリを全体から実行し直す完全リフレッシュより処理量を抑えられる一方、変更履歴の管理という追加の仕組みが必要になる点は押さえておきたいところです。
どの製品を採用するかによって、差分反映が標準機能として使えるか、自社の実装で補う必要があるかは変わります。発注前に、候補となるデータベース製品がどのリフレッシュ方式に対応しているかを確認しておくと、後工程での作り直しを避けやすくなるでしょう。
ダッシュボードなど向く用途・不向きな用途
マテリアライズドビューが力を発揮するのは、更新頻度が低く、参照頻度が高いデータです。典型例が、経営ダッシュボードや月次・週次のレポート、分析用の集計画面になります。
これらの用途では、元データが数分から数時間単位でしか変わらない一方、同じ集計結果を多数の利用者が繰り返し参照します。事前に計算しておいた結果を使い回すことで、参照のたびに重い集計を実行する無駄を避けられるのです。
検索機能のランキング表示や、会員向けのポイント集計画面も、向いている用途に含まれます。複数のテーブルを横断して集計するものの、更新は日次・週次で足りる機能だからです。集計対象が増えても、参照側の応答時間を一定に保ちやすい点が共通の利点でしょう。
基幹システムの本番データベースから直接レポートを出す運用でも、マテリアライズドビューは役に立ちます。分析用の重いクエリを本番テーブルに直接投げ続けると、日常の業務処理そのものが遅くなる恐れがあるためです。集計結果をあらかじめ切り出しておけば、分析側の負荷を業務処理から切り離せます。
逆に、注文確定後すぐに残高や在庫数を反映させたい画面のように、秒単位の鮮度が求められる処理もあります。こうした処理にマテリアライズドビューを使うと、リフレッシュ前の古いデータを利用者に見せかねない点が難所です。誤った在庫数を表示したまま受注を進めてしまえば、欠品対応や出荷調整の手戻りにつながりかねません。金融・在庫系のように鮮度の誤りが業務判断に直結する場面では、通常のビューや元テーブルへの直接参照を選ぶほうが無難でしょう。
向く用途と不向きな用途の境目は、「参照者が古いデータをどこまで許容できるか」という一点に集約されます。要件定義の段階でこの境目を見極めておくことが、設計の手戻りを防ぐ近道になるでしょう。
発注・レビューで確認する3つの点
許容できるデータの古さを言語化する
発注時にまず詰めておきたいのは、「このデータは何分・何時間古くても業務上問題ないか」という許容範囲です。マテリアライズドビューは元データの更新に自動で追随しないため、この許容範囲を先に決めておかないと、リフレッシュ間隔の設計自体が始まりません。
画面や帳票ごとに求められる鮮度は異なります。経営ダッシュボードなら1日1回のリフレッシュで足りる場合もあれば、業務担当者が使う集計画面では数十分おきの更新が必要になる場合もあるでしょう。用途ごとに許容範囲を洗い出す作業は、発注前の要件整理の段階で済ませておくのが望ましい進め方です。
この許容範囲の言語化を怠ると、開発が進んだ段階になって「思ったより古いデータが表示される」という指摘が上がりかねません。その結果、リフレッシュ間隔の再設計や実装のやり直しにつながることもあるでしょう。要件定義書に鮮度の許容範囲を明記しておくことが、手戻りを避ける実務上の備えになります。
リフレッシュ方式とタイミングを確認する
リフレッシュを手動・定期スケジュール・差分反映のどれで行うかによって、必要な実装の複雑さは変わります。差分（増分）反映を組むには、変更ログの管理やユニークインデックスの設計など、データベースの内部動作を理解した設計・実装のスキルが必要です。
内製でこの設計を担う場合、データベース設計者と実装担当者が、リフレッシュ方式ごとの制約を確認しながら検証する工数を見込んでおく必要があります。検証を省いてスケジュール実行だけを組んでしまうと、リフレッシュ中の負荷やロックの影響を、運用が始まってから洗い出す羽目になりかねません。
とくに差分反映の実装は、変更履歴の欠落や重複反映といった細かな不整合が起きやすく、テストの設計にも一定の経験が求められます。こうした検討を内製だけで進めるのが難しい場合は、外部パートナーの活用も選択肢のひとつになるでしょう。業務要件に応じたリフレッシュ方式の選定から、保存領域の見積もりまでを合わせて相談できます。
保存領域の増加を見積もる
マテリアライズドビューは計算結果を実体として保存するため、元テーブルとは別にデータ領域を消費します。集計対象のテーブルが大きいほど、消費する領域も大きくなるでしょう。リフレッシュ方式によっては、旧データと新データを一時的に二重に持つ場合もあります。保存領域の見積もりは、インフラ担当と事前にすり合わせておくことが欠かせません。
クラウド環境であれば、ストレージ課金の増分としてコストに跳ね返る点も見落とせません。集計結果をどこまで細かく事前計算しておくかは、応答速度と保存コストのバランスで判断する事項になります。
見積もりの段階では、集計対象のテーブルが今後どの程度の速さで増えていくかも合わせて確認しておきたいところです。データ量の伸びを見込まずに保存領域を見積もると、運用開始から日が浅いうちに容量不足へ直面しかねません。
運用開始後の見直し体制を決めておく
マテリアライズドビューは、導入して終わりではありません。集計対象のテーブルが増えたり、利用者数が伸びたりすれば、リフレッシュにかかる時間や参照側の負荷は変化していきます。リフレッシュが失敗したときに誰が気づき、どう対応するかという運用体制も、あわせて決めておく必要があるでしょう。
発注段階では、リフレッシュの実行結果を監視する仕組みや、失敗時の再実行手順まで含めて確認しておくと、運用開始後の手戻りを抑えられます。設計・実装だけでなく、運用の見直しまでを一体で相談できる体制を選ぶことが、長く使い続けるうえでの分かれ目になるでしょう。
集計対象のテーブル構造や業務ルールが変われば、マテリアライズドビューの定義クエリ自体も見直しが必要になります。システムを開発した会社と運用を担う会社が別々だと、この見直しの都度、仕様の確認に時間を要することもあります。体制を決める際は、引き継ぎのしやすさも考慮しておくとよいでしょう。
まとめ
本稿では、マテリアライズドビューの仕組みと、鮮度と応答速度のトレードオフを整理しました。要点を3つに集約すると次のとおりです。第一に、問い合わせの結果を実体として保存し参照時に返す仕組みであること。第二に、元データの変更に自動では追随せず、リフレッシュの設計が欠かせないこと。第三に、更新頻度が低く参照頻度が高い集計に向く一方、秒単位の鮮度が要る処理には不向きであることです。
- マテリアライズドビューは、問い合わせの結果を実体として保存し、参照時に保存済みの結果を返す仕組みです。
- 通常のビューが参照のたびに計算をやり直すのに対し、事前計算によって応答を軽くできます。
- 元データの変更には自動で追随しないため、リフレッシュの方式とタイミングを設計しておく必要があります。
- 更新頻度が低く参照頻度が高いダッシュボードや分析用の集計に向いており、秒単位の鮮度が要る処理には不向きです。
- 発注時は、許容できるデータの古さ・リフレッシュ方式・保存領域の増加をあらかじめ確認しておくと、後工程の手戻りを防げます。
よくある質問
マテリアライズドビューを使うと、集計クエリはどのくらい速くなりますか。
具体的な速度差は、元のクエリの複雑さやデータ量によって変わるため、一律の数値では示せません。ただしPostgreSQL公式ドキュメントは、マテリアライズドビューへのアクセスは元のテーブルへの直接アクセスより速いとしています。結合や集計を伴うクエリほど、事前計算の効果を感じやすいでしょう。導入前に、対象クエリの実行時間を実測しておくと、効果を判断する材料になります。
リフレッシュを忘れると、どうなりますか。
リフレッシュを実行しない限り、マテリアライズドビューの内容は作成またはリフレッシュした時点のまま残り続けます。PostgreSQL公式ドキュメントも、データは常に最新とは限らないと説明しており、古いデータをそのまま参照者に見せてしまう点には注意が必要です。業務要件に合わせた定期的なリフレッシュの仕組みを、あらかじめ組み込んでおくことが欠かせません。手動運用に頼ると実行漏れが起きやすいため、スケジュール実行や監視の仕組みとセットで検討するとよいでしょう。
通常のビューをマテリアライズドビューに置き換えるだけで、性能は上がりますか。
置き換えただけでは、期待した効果が出ない場合もあります。リフレッシュの頻度や方式を業務要件に合わせて設計しないと、鮮度が業務に見合わなかったり、リフレッシュの負荷が別の問題を生んだりしかねません。速度と鮮度のバランスを、用途ごとに検討する必要があるでしょう。集計対象のテーブル設計自体に無駄がある場合は、マテリアライズドビュー化の前にクエリやテーブル構造を見直す余地も残っています。
どのデータベース製品でも使えますか。
主要なデータベース製品の多くは、マテリアライズドビューに相当する機能を備えています。ただし対応状況やリフレッシュの実装方法は、製品ごとに異なるので注意が必要です。たとえばPostgreSQLは、REFRESH MATERIALIZED VIEWコマンドで更新する方式を採用しています。一方Oracle Databaseは、完全リフレッシュと差分反映を使い分ける方式を備えています。採用予定の製品のドキュメントで、対応機能を確認しておくとよいでしょう。クラウドのデータウェアハウスサービスでも、名称は異なるものの近い機能が提供されている場合があります。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、データベースの設計・集計処理の見直しから支援する体制です。マテリアライズドビューを含むリフレッシュ運用の設計、実装、保守までを一貫して任せられます。要件定義の段階から運用開始後の見直しまで、工程を分けずに任せられる点も特徴でしょう。既存システムの応答が遅くなってきた場合の原因調査から、リフレッシュ方式の選定、保存領域を含む構成の見直しまで対応します。集計処理まわりの設計やデータベースの構成でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- PostgreSQL公式ドキュメント「Materialized Views」
- PostgreSQL公式ドキュメント「REFRESH MATERIALIZED VIEW」
- Oracle Database公式ドキュメント「Refreshing Materialized Views」
- Wikipedia日本語版「マテリアライズドビュー」
