非同期マテリアライズドビュー

このトピックでは、非同期マテリアライズドビューの理解、作成、使用、および管理方法について説明します。

同期マテリアライズドビューと比較して、非同期マテリアライズドビューはマルチテーブルジョインとより多くの集計関数をサポートします。非同期マテリアライズドビューのリフレッシュは手動またはスケジュールされたタスクによってトリガーされます。また、マテリアライズドビュー全体ではなく一部のパーティションをリフレッシュすることもでき、リフレッシュのコストを大幅に削減します。さらに、非同期マテリアライズドビューはさまざまなクエリの書き換えシナリオをサポートし、自動的かつ透明なクエリアクセラレーションを可能にします。

同期マテリアライズドビュー（ロールアップ）のシナリオと使用法については、同期マテリアライズドビュー（ロールアップ） を参照してください。

概要

データベースのアプリケーションは、大規模なテーブルに対して複雑なクエリを実行することがよくあります。これらのクエリは、数十億行を含むテーブルに対するマルチテーブルジョインや集計を含みます。これらのクエリを処理するには、システムリソースと結果を計算する時間の観点から高コストです。

CelerData の非同期マテリアライズドビューは、これらの問題に対処するために設計されています。非同期マテリアライズドビューは、1つ以上のベーステーブルから事前計算されたクエリ結果を保持する特別な物理テーブルです。ベーステーブルに対して複雑なクエリを実行すると、CelerData は関連するマテリアライズドビューから事前計算された結果を返し、これらのクエリを処理します。この方法により、繰り返しの複雑な計算を回避できるため、クエリパフォーマンスが向上します。このパフォーマンスの違いは、クエリが頻繁に実行される場合や十分に複雑な場合に顕著です。

さらに、非同期マテリアライズドビューは、データウェアハウス上に数学モデルを構築するのに特に役立ちます。これにより、上位層のアプリケーションに統一されたデータ仕様を提供し、基盤となる実装を隠したり、ベーステーブルの生データのセキュリティを保護したりできます。

CelerData におけるマテリアライズドビューの理解

CelerData は、単一テーブルのみに構築できる同期マテリアライズドビューを提供します。同期マテリアライズドビュー、またはロールアップは、データの新鮮さを保ち、リフレッシュコストを低く抑えます。しかし、非同期マテリアライズドビューと比較すると、同期マテリアライズドビューには多くの制限があります。クエリを加速または書き換えるために同期マテリアライズドビューを構築したい場合、集計演算子の選択肢が限られています。

次の表は、CelerData における非同期マテリアライズドビュー（ASYNC MV）と同期マテリアライズドビュー（SYNC MV）のサポートする機能の観点からの比較を示しています。

	単一テーブル集計	マルチテーブルジョイン	クエリの書き換え	リフレッシュ戦略	ベーステーブル
ASYNC MV	はい	はい	はい	定期的にトリガーされるリフレッシュ 手動リフレッシュ	複数のテーブルから: Default Catalog External catalogs 既存のマテリアライズドビュー 既存のビュー
SYNC MV (Rollup)	集計関数の選択肢が限られている	いいえ	はい	データロード中の同期リフレッシュ	Default Catalog の単一テーブル

基本概念

• ベーステーブル

  ベーステーブルは、マテリアライズドビューの駆動テーブルです。

  CelerData の非同期マテリアライズドビューでは、ベーステーブルは default catalog の CelerData 内部テーブル、外部カタログのテーブル、または既存の非同期マテリアライズドビューやビューであることができます。CelerData は、すべてのテーブルタイプ に対して非同期マテリアライズドビューの作成をサポートしています。

• リフレッシュ

  非同期マテリアライズドビューを作成すると、そのデータはその時点でのベーステーブルの状態のみを反映します。ベーステーブルのデータが変更された場合、マテリアライズドビューをリフレッシュして変更を同期させる必要があります。

  現在、CelerData は 2 つの一般的なリフレッシュ戦略をサポートしています: ASYNC（タスクによって定期的にトリガーされるリフレッシュ）と MANUAL（ユーザーによって手動でトリガーされるリフレッシュ）。

• クエリの書き換え

  クエリの書き換えとは、マテリアライズドビューが構築されたベーステーブルに対してクエリを実行する際に、システムがマテリアライズドビューの事前計算された結果をクエリに再利用できるかどうかを自動的に判断することを意味します。再利用できる場合、システムは関連するマテリアライズドビューからデータを直接ロードし、時間とリソースを消費する計算やジョインを回避します。

  CelerData は、Default Catalog または Hive catalog、Hudi catalog、Iceberg catalog などの外部カタログに作成された SPJG タイプの非同期マテリアライズドビューに基づく自動かつ透明なクエリの書き換えをサポートしています。

マテリアライズドビューを作成するタイミングを決定する

データウェアハウス環境で次のような要求がある場合、非同期マテリアライズドビューを作成できます。

• 繰り返しの集計関数を使用したクエリの加速

  データウェアハウスのほとんどのクエリが集計関数を含む同じサブクエリを含んでおり、これらのクエリが計算リソースの大部分を消費しているとします。このサブクエリに基づいて、非同期マテリアライズドビューを作成できます。このビューはサブクエリのすべての結果を計算して保存します。マテリアライズドビューが構築された後、CelerData はサブクエリを含むすべてのクエリを書き換え、マテリアライズドビューに保存された中間結果をロードし、これらのクエリを加速します。

• 複数テーブルの定期的なジョイン

  データウェアハウスで複数のテーブルを定期的にジョインして新しいワイドテーブルを作成する必要があるとします。これらのテーブルに対して非同期マテリアライズドビューを構築し、固定時間間隔でリフレッシュタスクをトリガーする ASYNC リフレッシュ戦略を設定できます。マテリアライズドビューが構築された後、クエリ結果はマテリアライズドビューから直接返され、JOIN 操作による遅延が回避されます。

• データウェアハウスのレイヤリング

  データウェアハウスに大量の生データが含まれており、クエリには複雑な ETL 操作が必要な場合、データウェアハウス内のデータを階層化するために複数の非同期マテリアライズドビューを構築し、クエリを一連の単純なサブクエリに分解できます。これにより、繰り返しの計算を大幅に削減し、さらに重要なことに、DBA が問題を簡単かつ効率的に特定するのに役立ちます。それに加えて、データウェアハウスのレイヤリングは、生データと統計データを分離し、機密性の高い生データのセキュリティを保護します。

• データレイクでのクエリの加速

  ネットワーク遅延やオブジェクトストレージのスループットのために、データレイクのクエリは遅くなることがあります。しかし、データレイクの上に非同期マテリアライズドビューを構築して生データをフィルタリングすることで、クエリパフォーマンスを向上させることができます。CelerData は、外部ソースからのデータが変更されるたびにマテリアライズドビューを自動的にリフレッシュし、データの一貫性を確保します。さらに、CelerData の SQL オプティマイザは、既存のマテリアライズドビューを使用するようにクエリをインテリジェントに書き換え、クエリを手動で変更する手間を省きます。

非同期マテリアライズドビューを作成する

CelerData の非同期マテリアライズドビューは、次のベーステーブルに基づいて作成できます。

• CelerData のすべてのテーブルタイプの内部テーブル
• Hive catalog、Hudi catalog、Iceberg catalog のテーブル
• 既存の非同期マテリアライズドビュー
• 既存のビュー

始める前に

ベーステーブルの準備

次の例では、2 つのベーステーブルを使用します。

• テーブル goods は、アイテム ID item_id1、アイテム名 item_name、アイテム価格 price を記録します。
• テーブル order_list は、注文 ID order_id、クライアント ID client_id、アイテム ID item_id2、注文日 order_date を記録します。

カラム goods.item_id1 はカラム order_list.item_id2 と同等です。

次のステートメントを実行してテーブルを作成し、データを挿入します。

CREATE TABLE goods(
    item_id1          INT,
    item_name         STRING,
    price             FLOAT
) DISTRIBUTED BY HASH(item_id1);

INSERT INTO goods
VALUES
    (1001,"apple",6.5),
    (1002,"pear",8.0),
    (1003,"potato",2.2);

CREATE TABLE order_list(
    order_id          INT,
    client_id         INT,
    item_id2          INT,
    order_date        DATE
) DISTRIBUTED BY HASH(order_id);

INSERT INTO order_list
VALUES
    (10001,101,1001,"2022-03-13"),
    (10001,101,1002,"2022-03-13"),
    (10002,103,1002,"2022-03-13"),
    (10002,103,1003,"2022-03-14"),
    (10003,102,1003,"2022-03-14"),
    (10003,102,1001,"2022-03-14");

次の例のシナリオでは、各注文の合計を頻繁に計算する必要があります。これには、2 つのベーステーブルの頻繁なジョインと集計関数 sum() の集中的な使用が必要です。さらに、ビジネスシナリオでは、データを 1 日間隔でリフレッシュする必要があります。

クエリステートメントは次のとおりです。

SELECT
    order_id,
    sum(goods.price) as total
FROM order_list INNER JOIN goods ON goods.item_id1 = order_list.item_id2
GROUP BY order_id;

マテリアライズドビューを作成する

特定のクエリステートメントに基づいてマテリアライズドビューを作成するには、CREATE MATERIALIZED VIEW を使用します。

テーブル goods、order_list、および前述のクエリステートメントに基づいて、次の例では各注文の合計を分析するためのマテリアライズドビュー order_mv を作成します。マテリアライズドビューは 1 日間隔で自動的にリフレッシュされるように設定されています。

CREATE MATERIALIZED VIEW order_mv
DISTRIBUTED BY HASH(`order_id`)
REFRESH ASYNC START('2022-09-01 10:00:00') EVERY (interval 1 day)
AS SELECT
    order_list.order_id,
    sum(goods.price) as total
FROM order_list INNER JOIN goods ON goods.item_id1 = order_list.item_id2
GROUP BY order_id;

NOTE

• 非同期マテリアライズドビューを作成する際には、バケッティング戦略を指定する必要があります。
• 非同期マテリアライズドビューには、ベーステーブルとは異なるパーティショニングおよびバケッティング戦略を設定できます。
• 非同期マテリアライズドビューは、より長いスパンでの動的パーティショニング戦略をサポートしています。たとえば、ベーステーブルが 1 日間隔でパーティション化されている場合、マテリアライズドビューを 1 か月間隔でパーティション化するように設定できます。
• 非同期マテリアライズドビューを作成するために使用されるクエリステートメントには、マテリアライズドビューのパーティションキーとバケットキーを含める必要があります。
• マテリアライズドビューを作成するために使用されるクエリステートメントは、rand()、random()、uuid()、sleep() などのランダム関数をサポートしていません。
• 非同期マテリアライズドビューは、さまざまなデータタイプをサポートしています。詳細については、CREATE MATERIALIZED VIEW - サポートされるデータタイプ を参照してください。

• 非同期マテリアライズドビューのリフレッシュメカニズムについて

  現在、CelerData は 2 つの ON DEMAND リフレッシュ戦略をサポートしています: 手動リフレッシュと固定時間間隔での定期リフレッシュ。

  非同期マテリアライズドビューは、さまざまな非同期リフレッシュメカニズムをさらにサポートしています。

  • マテリアライズドビューに多くの大きなパーティションがある場合、各リフレッシュは大量のリソースを消費する可能性があります。CelerData はリフレッシュタスクの分割をサポートしています。リフレッシュする最大パーティション数を指定でき、CelerData は指定された最大パーティション数以下のバッチサイズでリフレッシュを実行します。この機能により、大規模な非同期マテリアライズドビューが安定してリフレッシュされ、データモデリングの安定性と堅牢性が向上します。
  • 非同期マテリアライズドビューのパーティションの有効期限（TTL）を指定して、マテリアライズドビューが占有するストレージサイズを削減できます。
  • リフレッシュ範囲を指定して、最新のいくつかのパーティションのみをリフレッシュし、リフレッシュのオーバーヘッドを削減できます。

  詳細については、CREATE MATERIALIZED VIEW - パラメータ の PROPERTIES セクションを参照してください。既存の非同期マテリアライズドビューのメカニズムを変更するには、ALTER MATERIALIZED VIEW を使用できます。

• ネストされたマテリアライズドビューについて

  CelerData はネストされた非同期マテリアライズドビューの作成をサポートしています。既存の非同期マテリアライズドビューに基づいて非同期マテリアライズドビューを構築できます。各マテリアライズドビューのリフレッシュ戦略は、上位または下位のマテリアライズドビューには影響しません。現在、CelerData はネストのレベル数を制限していません。実稼働環境では、ネストのレイヤー数が 3 を超えないことを推奨します。

• 外部カタログマテリアライズドビューについて

  CelerData は、Hive catalog、Hudi catalog、Iceberg catalog に基づく非同期マテリアライズドビューの作成をサポートしています。外部カタログマテリアライズドビューは、一般的な非同期マテリアライズドビューと同様に作成されますが、以下の使用制限があります。

  • 外部カタログのベーステーブルとマテリアライズドビューの間の厳密な一貫性は保証されません。

  • 現在、外部リソースに基づく非同期マテリアライズドビューの構築はサポートされていません。

  • 現在、CelerData は Iceberg catalog および Hudi catalog のベーステーブルのデータ変更を認識できないため、リフレッシュタスクがトリガーされるたびにすべてのパーティションがデフォルトでリフレッシュされます。一部のパーティションのみをリフレッシュしたい場合は、REFRESH MATERIALIZED VIEW ステートメントを使用して手動でマテリアライズドビューをリフレッシュし、リフレッシュしたいパーティションを指定できます。

  • CelerData は、頻繁にアクセスされる Hive catalog のキャッシュされたメタデータを定期的にリフレッシュしてデータ変更を認識することができます。Hive メタデータキャッシュのリフレッシュは、以下の FE パラメータを通じて設定できます。

    設定項目	デフォルト	説明
    enable_background_refresh_connector_metadata	true	定期的な Hive メタデータキャッシュのリフレッシュを有効にするかどうか。これを有効にすると、CelerData は Hive クラスターのメタストア（Hive Metastore または AWS Glue）をポーリングし、頻繁にアクセスされる Hive catalog のキャッシュされたメタデータをリフレッシュしてデータ変更を認識します。true は Hive メタデータキャッシュのリフレッシュを有効にし、false は無効にします。この項目は FE 動的パラメータです。ADMIN SET FRONTEND CONFIG コマンドを使用して変更できます。
    background_refresh_metadata_interval_millis	600000 (10 分)	2 つの連続した Hive メタデータキャッシュリフレッシュの間隔。単位: ミリ秒。この項目は FE 動的パラメータです。ADMIN SET FRONTEND CONFIG コマンドを使用して変更できます。
    background_refresh_metadata_time_secs_since_last_access_secs	86400 (24 時間)	Hive メタデータキャッシュリフレッシュタスクの有効期限。アクセスされた Hive catalog に対して、指定された時間を超えてアクセスされていない場合、CelerData はそのキャッシュされたメタデータのリフレッシュを停止します。アクセスされていない Hive catalog に対して、CelerData はそのキャッシュされたメタデータをリフレッシュしません。単位: 秒。この項目は FE 動的パラメータです。ADMIN SET FRONTEND CONFIG コマンドを使用して変更できます。

非同期マテリアライズドビューを手動でリフレッシュする

非同期マテリアライズドビューのリフレッシュ戦略に関係なく、REFRESH MATERIALIZED VIEW を使用してリフレッシュできます。CelerData は、パーティション名を指定して非同期マテリアライズドビューの特定のパーティションをリフレッシュすることをサポートしています。CelerData は、リフレッシュタスクが成功または失敗したときにのみ SQL ステートメントが返される同期呼び出しをサポートしています。

-- 非同期呼び出し（デフォルト）でマテリアライズドビューをリフレッシュします。
REFRESH MATERIALIZED VIEW order_mv;
-- 同期呼び出しでマテリアライズドビューをリフレッシュします。
REFRESH MATERIALIZED VIEW order_mv WITH SYNC MODE;

非同期呼び出しを介して送信されたリフレッシュタスクを CANCEL REFRESH MATERIALIZED VIEW を使用してキャンセルできます。

非同期マテリアライズドビューをクエリする

作成した非同期マテリアライズドビューは、クエリステートメントに従った完全な事前計算結果を含む実質的な物理テーブルです。したがって、マテリアライズドビューが最初にリフレッシュされた後、直接クエリできます。

MySQL > SELECT * FROM order_mv;
+----------+--------------------+
| order_id | total              |
+----------+--------------------+
|    10001 |               14.5 |
|    10002 | 10.200000047683716 |
|    10003 |  8.700000047683716 |
+----------+--------------------+
3 rows in set (0.01 sec)

NOTE

非同期マテリアライズドビューを直接クエリできますが、ベーステーブルに対するクエリから得られる結果と一致しない場合があります。

非同期マテリアライズドビューでクエリを書き換える

CelerData は、SPJG タイプの非同期マテリアライズドビューに基づく自動かつ透明なクエリの書き換えをサポートしています。SPJG タイプのマテリアライズドビューとは、プランに Scan、Filter、Project、Aggregate タイプのオペレーターのみを含むマテリアライズドビューを指します。SPJG タイプのマテリアライズドビューのクエリの書き換えには、単一テーブルクエリの書き換え、ジョインクエリの書き換え、集計クエリの書き換え、ユニオンクエリの書き換え、およびネストされたマテリアライズドビューに基づくクエリの書き換えが含まれます。

現在、CelerData は、Default Catalog または Hive catalog、Hudi catalog、Iceberg catalog などの外部カタログに作成された非同期マテリアライズドビューに対するクエリの書き換えをサポートしています。Default Catalog のデータをクエリする際、CelerData は、ベーステーブルとデータが一致しないマテリアライズドビューを除外することで、書き換えられたクエリと元のクエリの結果の強い一貫性を保証します。マテリアライズドビューのデータが期限切れになると、そのマテリアライズドビューは候補として使用されません。外部カタログのデータをクエリする際、CelerData は外部カタログのデータ変更を認識できないため、結果の強い一貫性を保証しません。

クエリの書き換えを有効にする

• Default Catalog マテリアライズドビューに基づくクエリの書き換えを有効にする

  CelerData は、非同期マテリアライズドビューのクエリの書き換えをデフォルトで有効にしています。この機能は、セッション変数 enable_materialized_view_rewrite を使用して有効または無効にできます。

  SET GLOBAL enable_materialized_view_rewrite = { true | false };

• [実験的] 外部カタログマテリアライズドビューに基づくクエリの書き換えを有効にする

  非同期マテリアライズドビューを使用して外部カタログのデータをクエリする際に結果の強い一貫性を保証しないため、外部カタログマテリアライズドビューに基づくクエリの書き換えはデフォルトで無効になっています。マテリアライズドビューを作成する際にプロパティ "force_external_table_query_rewrite" = "true" を追加することで、この機能を外部カタログマテリアライズドビューに対して有効にできます。

  例:

  CREATE MATERIALIZED VIEW ex_mv_par_tbl
  PARTITION BY emp_date
  DISTRIBUTED BY hash(empid)
  PROPERTIES (
  "force_external_table_query_rewrite" = "true"
  ) 
  AS
  select empid, deptno, emp_date
  from `hive_catalog`.`emp_db`.`emps_par_tbl`
  where empid < 5;

集計ロールアップでクエリを書き換える

CelerData は、集計ロールアップを使用してクエリを書き換えることをサポートしています。つまり、CelerData は GROUP BY a 句を持つ集計クエリを、GROUP BY a,b 句を持つ非同期マテリアライズドビューを使用して書き換えることができます。

次の例では、CelerData はクエリ 1 と 2 をマテリアライズドビュー order_agg_mv を使用して書き換えることができます。

CREATE MATERIALIZED VIEW order_agg_mv
DISTRIBUTED BY HASH(`order_id`) BUCKETS 12
REFRESH ASYNC START('2022-09-01 10:00:00') EVERY (interval 1 day)
AS
SELECT
    order_id,
    order_date,
    bitmap_union(to_bitmap(client_id))  -- uv
FROM order_list 
GROUP BY order_id, order_date;

-- クエリ 1
SELECT
    order_date,
    bitmap_union(to_bitmap(client_id))  -- uv
FROM order_list 
GROUP BY order_date;

-- クエリ 2
SELECT
    order_date,
    count(distinct client_id) 
FROM order_list 
GROUP BY order_date;

特定の集計関数のみが集計ロールアップを使用したクエリの書き換えをサポートしています。前の例では、マテリアライズドビュー order_agg_mv が count(distinct client_id) の代わりに bitmap_union(to_bitmap(client_id)) を使用している場合、CelerData は集計ロールアップを使用してクエリを書き換えることができません。

次の表は、元のクエリの集計関数とマテリアライズドビューを構築するために使用される集計関数の対応を示しています。ビジネスシナリオに応じて、対応する集計関数を選択してマテリアライズドビューを構築できます。

元のクエリでサポートされる集計関数	マテリアライズドビューでサポートされる集計ロールアップの関数
sum	sum
count	count
min	min
max	max
avg	sum / count
bitmap_union, bitmap_union_count, count(distinct)	bitmap_union
hll_raw_agg, hll_union_agg, ndv, approx_count_distinct	hll_union
percentile_approx, percentile_union	percentile_union

対応する GROUP BY カラムを持たない DISTINCT 集計は、集計ロールアップを使用して書き換えることができません。ただし、集計ロールアップ DISTINCT 集計関数を持つクエリが GROUP BY カラムを持たず、等価述語を持つ場合、CelerData は等価述語を GROUP BY 定数式に変換できるため、関連するマテリアライズドビューによって書き換えることができます。

次の例では、CelerData はマテリアライズドビュー order_agg_mv1 を使用してクエリを書き換えることができます。

CREATE MATERIALIZED VIEW order_agg_mv1
DISTRIBUTED BY HASH(`order_id`) BUCKETS 12
REFRESH ASYNC START('2022-09-01 10:00:00') EVERY (interval 1 day)
AS
SELECT
    order_date,
    count(distinct client_id) 
FROM order_list 
GROUP BY order_date;


-- クエリ
SELECT
    order_date,
    count(distinct client_id) 
FROM order_list WHERE order_date='2023-07-03';

View Delta Join シナリオでクエリを書き換える

CelerData は現在、Delta Join を使用した非同期マテリアライズドビューに基づくクエリの書き換えをサポートしています。これは、クエリされたテーブルがマテリアライズドビューのベーステーブルのサブセットであることを意味します。たとえば、table_a INNER JOIN table_b の形式のクエリは、table_a INNER JOIN table_b INNER JOIN/LEFT OUTER JOIN table_c の形式のマテリアライズドビューによって書き換えることができます。ここで、table_b INNER JOIN/LEFT OUTER JOIN table_c は Delta Join です。この機能により、クエリの柔軟性を維持し、ワイドテーブルの構築にかかる大きなコストを回避しながら、クエリを透明に加速できます。CelerData は、Hive Catalog の View Delta Join シナリオでのクエリの書き換えをサポートしています。

View Delta Join クエリは、次の要件が満たされている場合にのみ書き換えることができます。

• Delta Join は Inner Join または Left Outer Join でなければなりません。

• Delta Join が Inner Join の場合、ジョインするキーは対応する Foreign/Primary/Unique Key であり、NOT NULL でなければなりません。

  たとえば、マテリアライズドビューが A INNER JOIN B ON (A.a1 = B.b1) INNER JOIN C ON (B.b2 = C.c1) の形式であり、クエリが A INNER JOIN B ON (A.a1 = B.b1) の形式である場合、B INNER JOIN C ON (B.b2 = C.c1) は Delta Join です。B.b2 は B の Foreign Key であり、NOT NULL でなければならず、C.c1 は C の Primary Key または Unique Key でなければなりません。

• Delta Join が Left Outer Join の場合、ジョインするキーは対応する Foreign/Primary/Unique Key でなければなりません。

  たとえば、マテリアライズドビューが A INNER JOIN B ON (A.a1 = B.b1) LEFT OUTER JOIN C ON (B.b2 = C.c1) の形式であり、クエリが A INNER JOIN B ON (A.a1 = B.b1) の形式である場合、B LEFT OUTER JOIN C ON (B.b2 = C.c1) は Delta Join です。B.b2 は B の Foreign Key であり、C.c1 は C の Primary Key または Unique Key でなければなりません。

上記の制約を実装するには、テーブルを作成する際に unique_constraints および foreign_key_constraints プロパティを使用してテーブルの Unique Key 制約と Foreign Key 制約を定義する必要があります。詳細については、CREATE TABLE - PROPERTIES を参照してください。

CAUTION

Unique Key 制約と Foreign Key 制約は、クエリの書き換えにのみ使用されます。テーブルにデータがロードされる際に Foreign Key 制約のチェックは保証されません。テーブルにロードされるデータが制約を満たしていることを確認する必要があります。

次の例では、テーブル lineorder を作成する際に複数の Foreign Key を定義しています。

CREATE TABLE `lineorder` (
  `lo_orderkey` int(11) NOT NULL COMMENT "",
  `lo_linenumber` int(11) NOT NULL COMMENT "",
  `lo_custkey` int(11) NOT NULL COMMENT "",
  `lo_partkey` int(11) NOT NULL COMMENT "",
  `lo_suppkey` int(11) NOT NULL COMMENT "",
  `lo_orderdate` int(11) NOT NULL COMMENT "",
  `lo_orderpriority` varchar(16) NOT NULL COMMENT "",
  `lo_shippriority` int(11) NOT NULL COMMENT "",
  `lo_quantity` int(11) NOT NULL COMMENT "",
  `lo_extendedprice` int(11) NOT NULL COMMENT "",
  `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
  `lo_discount` int(11) NOT NULL COMMENT "",
  `lo_revenue` int(11) NOT NULL COMMENT "",
  `lo_supplycost` int(11) NOT NULL COMMENT "",
  `lo_tax` int(11) NOT NULL COMMENT "",
  `lo_commitdate` int(11) NOT NULL COMMENT "",
  `lo_shipmode` varchar(11) NOT NULL COMMENT ""
) ENGINE=OLAP
DUPLICATE KEY(`lo_orderkey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`lo_orderkey`)
PROPERTIES (
-- Unique Key を unique_constraints で定義
"unique_constraints" = "lo_orderkey,lo_linenumber",
-- Foreign Key を foreign_key_constraints で定義
"foreign_key_constraints" = "
    (lo_custkey) REFERENCES customer(c_custkey);
    (lo_partkey) REFERENCES ssb.part(p_partkey);
    (lo_suppkey) REFERENCES supplier(s_suppkey);
    (lo_orderdate) REFERENCES dates(d_datekey)
"
);

クエリの書き換えを設定する

非同期マテリアライズドビューのクエリの書き換えは、次のセッション変数を通じて設定できます。

変数	デフォルト	説明
enable_materialized_view_union_rewrite	true	マテリアライズドビューのユニオンクエリの書き換えを有効にするかどうかを制御するブール値。
enable_rule_based_materialized_view_rewrite	true	ルールベースのマテリアライズドビューのクエリの書き換えを有効にするかどうかを制御するブール値。この変数は主に単一テーブルクエリの書き換えに使用されます。
nested_mv_rewrite_max_level	3	クエリの書き換えに使用できるネストされたマテリアライズドビューの最大レベル。タイプ: INT。範囲: [1, +∞)。値が 1 の場合、他のマテリアライズドビューに基づいて作成されたマテリアライズドビューはクエリの書き換えに使用されません。

クエリが書き換えられたかどうかを確認する

クエリが書き換えられたかどうかを確認するには、EXPLAIN ステートメントを使用してクエリプランを表示します。OlapScanNode セクションの TABLE フィールドに対応するマテリアライズドビューの名前が表示されている場合、クエリはマテリアライズドビューに基づいて書き換えられたことを意味します。

mysql> EXPLAIN SELECT 
    order_id, sum(goods.price) AS total 
    FROM order_list INNER JOIN goods 
    ON goods.item_id1 = order_list.item_id2 
    GROUP BY order_id;
+------------------------------------+
| Explain String                     |
+------------------------------------+
| PLAN FRAGMENT 0                    |
|  OUTPUT EXPRS:1: order_id | 8: sum |
|   PARTITION: RANDOM                |
|                                    |
|   RESULT SINK                      |
|                                    |
|   1:Project                        |
|   |  <slot 1> : 9: order_id        |
|   |  <slot 8> : 10: total          |
|   |                                |
|   0:OlapScanNode                   |
|      TABLE: order_mv               |
|      PREAGGREGATION: ON            |
|      partitions=1/1                |
|      rollup: order_mv              |
|      tabletRatio=0/12              |
|      tabletList=                   |
|      cardinality=3                 |
|      avgRowSize=4.0                |
|      numNodes=0                    |
+------------------------------------+
20 rows in set (0.01 sec)

非同期マテリアライズドビューを管理する

非同期マテリアライズドビューを変更する

非同期マテリアライズドビューのプロパティを ALTER MATERIALIZED VIEW を使用して変更できます。

• 非同期マテリアライズドビューの名前を変更する。

  ALTER MATERIALIZED VIEW order_mv RENAME order_total;

• 非同期マテリアライズドビューのリフレッシュ間隔を 2 日に変更する。

  ALTER MATERIALIZED VIEW order_mv REFRESH ASYNC EVERY(INTERVAL 2 DAY);

非同期マテリアライズドビューを表示する

SHOW MATERIALIZED VIEWS を使用するか、Information Schema のシステムメタデータテーブルをクエリすることで、データベース内の非同期マテリアライズドビューを表示できます。

• データベース内のすべての非同期マテリアライズドビューを確認する。

  SHOW MATERIALIZED VIEWS;

• 特定の非同期マテリアライズドビューを確認する。

  SHOW MATERIALIZED VIEWS WHERE NAME = "order_mv";

• 名前に一致する特定の非同期マテリアライズドビューを確認する。

  SHOW MATERIALIZED VIEWS WHERE NAME LIKE "order%";

• Information Schema のメタデータテーブルをクエリして、すべての非同期マテリアライズドビューを確認する。

  SELECT * FROM information_schema.materialized_views;

非同期マテリアライズドビューの定義を確認する

SHOW CREATE MATERIALIZED VIEW を使用して、非同期マテリアライズドビューを作成するために使用されたクエリを確認できます。

SHOW CREATE MATERIALIZED VIEW order_mv;

非同期マテリアライズドビューの実行ステータスを確認する

tasks および task_runs メタデータテーブルをクエリすることで、非同期マテリアライズドビューの実行（構築またはリフレッシュ）ステータスを確認できます。

次の例では、最も最近作成されたマテリアライズドビューの実行ステータスを確認します。

1. テーブル tasks で最も最近のタスクの TASK_NAME を確認します。

   mysql> select * from information_schema.tasks  order by CREATE_TIME desc limit 1\G;
   *************************** 1. row ***************************
     TASK_NAME: mv-59299
   CREATE_TIME: 2022-12-12 17:33:51
     SCHEDULE: MANUAL
     DATABASE: ssb_1
   DEFINITION: insert overwrite hive_mv_lineorder_flat_1 SELECT `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_linenumber`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_custkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_partkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderpriority`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_ordtotalprice`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_revenue`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`p_mfgr`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`s_nation`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`c_city`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`c_nation`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderdate`
   FROM `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`
   WHERE `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderdate` = '1997-01-01'
   EXPIRE_TIME: NULL
   1 row in set (0.02 sec)

2. 見つかった TASK_NAME を使用して、テーブル task_runs で実行ステータスを確認します。

   mysql> select * from information_schema.task_runs where task_name='mv-59299' order by CREATE_TIME \G;
   *************************** 1. row ***************************
       QUERY_ID: d9cef11f-7a00-11ed-bd90-00163e14767f
       TASK_NAME: mv-59299
     CREATE_TIME: 2022-12-12 17:39:19
     FINISH_TIME: 2022-12-12 17:39:22
           STATE: SUCCESS
       DATABASE: ssb_1
     DEFINITION: insert overwrite hive_mv_lineorder_flat_1 SELECT `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_linenumber`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_custkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_partkey`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderpriority`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_ordtotalprice`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_revenue`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`p_mfgr`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`s_nation`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`c_city`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`c_nation`, `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderdate`
   FROM `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`
   WHERE `hive_ci`.`dla_scan`.`lineorder_flat_1000_1000_orc`.`lo_orderdate` = '1997-01-01'
     EXPIRE_TIME: 2022-12-15 17:39:19
     ERROR_CODE: 0
   ERROR_MESSAGE: NULL
       PROGRESS: 100%
   2 rows in set (0.02 sec)

非同期マテリアライズドビューを削除する

DROP MATERIALIZED VIEW を使用して非同期マテリアライズドビューを削除できます。

DROP MATERIALIZED VIEW order_mv;

関連するセッション変数

次の変数は、非同期マテリアライズドビューの動作を制御します。

• analyze_mv: リフレッシュ後にマテリアライズドビューを分析するかどうか、およびその方法。 有効な値は、空の文字列（分析しない）、sample（サンプル統計収集）、および full（完全統計収集）です。デフォルトは sample です。
• enable_materialized_view_rewrite: マテリアライズドビューの自動書き換えを有効にするかどうか。 有効な値は true（デフォルト）および false です。