メインコンテンツまでスキップ
に最終更新

同期マテリアライズドビューによる透過的な書き換え

同期マテリアライズドビュー（Sync-Materialized View）は、定義済みの SELECT 文の結果を保存する事前計算済みのテーブルです。元の明細データに対する任意のディメンションでの分析を可能にしながら、固定ディメンションの集計クエリを高速化します。

クエリの実行時、Doris は最適なマテリアライズドビューを自動的に選択し、そこから直接データを読み取ります。この処理はユーザーから見えず、「透過的な書き換え」と呼ばれます。ベーステーブルのデータが変更されると、Doris は手動操作なしでマテリアライズドビューとの整合性を自動的に維持します。

前提条件​

  • Doris 2.0 以降がデプロイされていること。
  • 明細データを格納するベーステーブルがすでに存在し、そのテーブルに対して固定ディメンションの集計クエリを繰り返し実行していること。
  • マテリアライズドビューの作成に必要なデータベースとテーブルの権限があること。
  • 本番環境への導入前に、対象クエリがマテリアライズドビューを利用するか確認できるテスト環境があること。

適用シナリオ​

シナリオ典型的な特徴
明細クエリと固定ディメンションの集計が併存する明細データと固定ディメンションの集計結果の両方を照会する必要がある
列・行のプルーニングクエリがテーブルの列や行の一部だけにアクセスする
時間のかかる演算子クエリに実行時間の長い集計など、負荷の高い処理が含まれる
異なるプレフィックスインデックスフィルタリングの高速化に異なるプレフィックスインデックスが必要である

一言でいうと、同期マテリアライズドビューは、整合性が自動的に維持される事前集計テーブルと、最適なビューを自動的に選択する透過的な書き換えを組み合わせたものです。

注意事項
  • Doris 2.0 以降ではマテリアライズドビューの機能が強化されています。本番環境への導入前に、対象クエリが想定したマテリアライズドビューを利用するか、テスト環境で確認してください。
  • 同じテーブルに形が似たマテリアライズドビューを複数作成しないでください。互いに競合し、クエリがビューを利用できなくなる可能性があります。

例：店舗別の売上集計​

各取引の取引 ID、販売担当者 ID、店舗 ID、販売日、取引金額を記録する売上明細テーブル sales_records があるとします。よくある分析の要件は、店舗別に売上金額を集計することです。

以下の手順では、マテリアライズドビュー store_amt を作成して store_id でグループ化した売上を合計し、クエリが透過的にこのビューへ書き換えられることを確認します。

ステップ 1：同期マテリアライズドビューを作成する​

  • 目的：店舗別の集計クエリの結果を事前計算する。

  • コマンド：

    CREATE MATERIALIZED VIEW store_amt AS
    SELECT store_id, SUM(sale_amt)
    FROM sales_records
    GROUP BY store_id;

  • 補足：コマンドの送信後、Doris は業務クエリをブロックせず、バックグラウンドでマテリアライズドビューを非同期に構築します。

ステップ 2：構築の進捗を確認する​

  • 目的：マテリアライズドビューの構築が完了したか確認する。

  • コマンド：

    SHOW ALTER TABLE MATERIALIZED VIEW FROM db_name;

  • 補足：State フィールドが FINISHED になれば、store_amt の作成は成功し、クエリから利用できる状態です。

ステップ 3：透過的な書き換えを発生させる​

  • 目的：集計の形式が一致するクエリで、マテリアライズドビューを自動的に利用する。

  • コマンド：

    SELECT store_id, SUM(sale_amt) FROM sales_records GROUP BY store_id;

  • 補足：SQL を変更しなくても、Doris は store_amt を自動的に選択し、事前集計済みのデータを直接読み取ります。

ステップ 4：マテリアライズドビューの利用を確認する​

  • 目的：透過的な書き換えが有効になっていることを確認する。

  • コマンド：

    EXPLAIN SELECT store_id, SUM(sale_amt) FROM sales_records GROUP BY store_id;

  • 補足：実行計画の末尾を確認してください。次の内容が表示されれば、store_amt が利用されています。

    TABLE: default_cluster:test.sales_records(store_amt), PREAGGREGATION: ON

透過的な書き換えとベーステーブルの直接照会の比較​

比較項目ベーステーブルを直接照会同期マテリアライズドビューへの透過的な書き換え
データソース明細データからその場で計算事前集計済みの結果を直接読み取る
集計クエリの性能データ量の影響を大きく受ける大幅に改善する
SQL の書き換えコストなしなし（自動選択）
データの整合性自然に保たれるDoris が自動的に維持する
メンテナンスコストなし競合を避けるためにビューの構成を計画する必要がある

よくある質問​

クエリがマテリアライズドビューを利用しないのはなぜですか？​

主な原因は次のとおりです。

  1. マテリアライズドビューの構築中で、State がまだ FINISHED になっていない。
  2. クエリの列、集計関数、またはグループ化キーが、マテリアライズドビューの定義と一致していない。
  3. 同じベーステーブルに形が似たマテリアライズドビューが複数あり、競合によって書き換えに失敗している。

調査方法：EXPLAIN を使用して実行計画の末尾にある TABLE: ...(materialized view name) の情報を確認し、実際にどのテーブルが利用されているかを確かめてください。

マテリアライズドビューの構築状態を確認するには？​

SHOW ALTER TABLE MATERIALIZED VIEW FROM db_name; を実行し、State フィールドを確認します。

  • PENDING / RUNNING：構築中です。
  • FINISHED：構築が完了し、クエリから利用できる状態です。
  • CANCELLED：構築に失敗したか、キャンセルされました。原因を調査し、ビューを再作成してください。

同じベーステーブルに複数のマテリアライズドビューを作成できますか？​

はい。ただし、形が似たビューは避けてください。似たビューが複数あると、透過的な書き換えで最適なビューを選択できず、クエリがビューを利用できなくなる可能性があります。まずテスト環境で、クエリが想定したビューを利用できることを確認してください。

マテリアライズドビューへ手動でデータを同期する必要はありますか？​

いいえ。ベーステーブルのデータが変更されると、Doris がマテリアライズドビューとの整合性を自動的に維持します。

まとめ​

  • 同期マテリアライズドビューは、事前集計テーブル、整合性の自動維持、透過的な書き換えを組み合わせたものです。
  • 明細クエリと固定ディメンションの集計が併存する場合に適しています。
  • 作成後は EXPLAIN でビューの利用状況を確認し、似たビュー同士の競合を避けてください。
  • 本番環境への導入前に、対象クエリがビューを利用するかテスト環境で確認してください。
Report issue