マテリアライズドビューの使用¶

マテリアライズドビューの利点¶

マテリアライズドビューのSnowflakeの実装は、多くのユニークな特性を提供します。

• マテリアライズドビューは、同じサブクエリの結果を繰り返し使用するクエリのパフォーマンスを向上させることができます。

• マテリアライズドビューは、Snowflakeによって自動的かつ透過的に維持されます。バックグラウンドサービスは、ベーステーブルに変更が加えられた後、マテリアライズドビューを更新します。これは、アプリケーションレベルでマテリアライズドビューに相当するものを手動で維持するよりも効率的で、エラーが発生しにくくなります。

• ベーステーブルで実行された DML の量に関係なく、マテリアライズドビューを介してアクセスされるデータは常に最新です。マテリアライズドビューが最新になる前にクエリが実行されると、Snowflakeはマテリアライズドビューを更新するか、マテリアライズドビューの最新部分を使用して、必要な新しいデータをベーステーブルから取得します。

マテリアライズドビューまたは通常のビューを作成するタイミングの決定¶

一般に、マテリアライズドビューと通常のビューのどちらを作成するかを決定するときは、次の基準を使用します。

• 次の すべて に当てはまる場合は、マテリアライズドビューを作成します。

  • ビューからのクエリ結果は頻繁に変更されない。これは、ほとんどの場合、ビューの基になる/ベーステーブルが頻繁に変更されないこと、または少なくともマテリアライズドビューで使用されるベーステーブル行のサブセットが頻繁に変更されないことを意味します。

  • ビューの結果が頻繁に使用される（通常、クエリ結果の変更の頻度よりも大幅に多い）。

  • クエリは多くのリソースを消費します。通常、これはクエリが多くの処理時間またはクレジットを消費することを意味しますが、クエリが中間結果のために多くのストレージスペースを消費することも意味します。

• 次の いずれか が当てはまる場合は、通常のビューを作成します。

  • ビューの結果は頻繁に変更される。

  • 結果の使用頻度が低い（結果の変更の割合と比較して）。

  • クエリはリソースを集中的に使用しないため、再実行するのにコストはかかりません。

これらの基準は単なるガイドラインです。マテリアライズドビューにより、頻繁に使用されない場合でも、特に結果がビューの使用よりも頻繁に変更されない場合でも、利点を得られる可能性があります。

また、通常のビューを使用するかマテリアライズドビューを使用するかを決定する際に考慮すべき他の要因があります。

たとえば、マテリアライズドビューを格納するコストは要因の1つです。結果があまり頻繁に使用されない場合（変更よりも頻繁に使用されたとしても）、追加のストレージコストがパフォーマンスの向上に見合わない可能性があります。

テーブル、通常のビュー、キャッシュされた結果との比較¶

マテリアライズドビューは、いくつかの点でテーブルに似ており、他の点では通常の（つまり非マテリアライズド）ビューに似ています。さらに、マテリアライズドビューにはキャッシュされた結果といくつかの類似点があります。特に、両方とも将来の再利用のためにクエリ結果を保存できるためです。

このセクションでは、以下を含む、特定の領域におけるこれらのオブジェクトの類似点と相違点について説明します：

• クエリのパフォーマンス。

• クエリのセキュリティ。

• クエリのロジックの複雑性軽減。

• データクラスタリング（クエリパフォーマンスに関連）。

• ストレージとメンテナンスのコスト。

Snowflakeは、クエリの実行後、短時間クエリ結果をキャッシュします。状況によっては、同じクエリが再実行され、クエリがアクセスするテーブルに何も変更がなければ、Snowflakeはクエリを再実行せずに同じ結果を単に返すことができます。これは最速かつ最も効率的な再利用の形式ですが、柔軟性が最も低くなります。詳細については、 保存済みのクエリ結果の使用 をご参照ください。

マテリアライズドビューとキャッシュされたクエリ結果の両方により、クエリのパフォーマンスが向上します：

• マテリアライズドビューは、キャッシュされた結果よりも柔軟性がありますが、一般的には低速です。

• マテリアライズドビューは、「キャッシュ」（つまり、ビューのクエリ結果）のためにテーブルよりも高速です。さらに、データが変更された場合、変更されていないデータには「キャッシュ」を使用し、変更されたデータにはベーステーブルを使用できます。

通常のビューはデータをキャッシュしないため、キャッシュによってパフォーマンスを向上させることはできません。ただし、場合によっては、ビューはSnowflakeがより効率的なクエリプランを生成するのに役立ちます。また、マテリアライズドビューと通常のビューの両方で、行レベルまたは列レベルでデータを公開または非表示にできるため、データセキュリティが強化されます。

次の表に、テーブル、通常のビュー、キャッシュされたクエリ結果、およびマテリアライズドビューの主な類似点と相違点を示します：

マテリアライズドビューの使用例¶

このセクションでは、マテリアライズドビューの概念的な概要も提供する、一般的な使用シナリオをいくつか説明します。

• 毎日、サブクエリ S を含むクエリ Q を実行するとします。 S がリソースを集中的に使用し、週に1回しか変更されないデータをクエリする場合、 S を実行し、結果を CT という名前のテーブルにキャッシュすることで、外部クエリ Q のパフォーマンスを改善できます：

  • テーブルは週に一度だけ更新します。

  • 残りの時間では、 Q を実行すると、テーブルに格納されている S のサブクエリ結果が参照されます。

  これは、サブクエリ S の結果が予測どおりに変化する限り（例: 毎週同時刻）、正しく機能します。

  ただし、 S の結果が予期せず変更される場合、結果をテーブルにキャッシュすることは危険です。サブクエリ S の結果が古い場合（したがって、キャッシュテーブル CT の結果が古い場合）、メインクエリ Q が古い結果を返すことがあります。

  理想的には、まれにしか変更されないが、変更のタイミングが予測できない結果のための特別なタイプのキャッシュが必要です。別の見方をすると、必要に応じてサブクエリ S を強制的に再実行（およびキャッシュテーブル CT を更新）したいと考えています。

  マテリアライズドビューは、両方の長所の近似を実装します。マテリアライズドビューのクエリを定義すると、クエリの結果は（内部テーブルに格納されているように）キャッシュされますが、Snowflakeは、マテリアライズドビューを定義するテーブルが更新されるとキャッシュを更新します。したがって、サブクエリの結果は、高速パフォーマンスのためにすぐに利用できます。

• それほど抽象的ではない例として、大規模な薬局の小さな支店を経営しており、その支店が合計数万の FDA承認済みの医薬品の中から数百の医薬品を在庫しているとします。

  また、各顧客が服用するすべての医薬品の完全なリストがあり、それらの顧客のほとんどすべてが在庫のある医薬品のみを注文していると仮定します（つまり、特別注文はまれです）。

  このシナリオでは、在庫のある医薬品の相互作用のみをリストするマテリアライズドビューを作成できます。顧客がこれまでに使用したことのない医薬品を注文したときに、その医薬品と顧客が服用している他のすべての医薬品の両方がマテリアライズドビューでカバーされている場合は、 FDA データベース全体で薬物相互作用を確認する必要はありません。マテリアライズドビューの確認のみで済むため、検索が高速になります。

• マテリアライズドビューを単独で使用することも、結合して使用することもできます。

  薬局の例を続けて、各顧客が服用するすべての薬をリストした1つのテーブルがあるとします。そのテーブルを薬物相互作用のマテリアライズドビューに結合して、顧客が現在服用している薬のどれが新しい薬と相互作用する可能性があるのかを調べることができます。

  マテリアライズドビューにあるかどうかに関係なく、外部結合を使用して、顧客の医薬品の すべて を確実にリストすることができます。外部結合により、現在の医薬品のいずれかがマテリアライズドビューにないことが示される場合は、包括的な薬物相互作用テーブルでクエリを再実行できます。

クエリオプティマイザーがマテリアライズドビューを使用する方法¶

ビューを使用するために、 SQL ステートメントでマテリアライズドビューを指定する必要はありません。クエリオプティマイザーは、ベーステーブルまたは通常のビューに対するクエリを自動的に書き換えて、代わりにマテリアライズドビューを使用します。

たとえば、マテリアライズドビューに、ベーステーブルに対するクエリで必要なすべての行と列が含まれているとします。オプティマイザーは、ベーステーブルではなくマテリアライズドビューを使用するように、クエリを書き換えることを決定できます。これにより、特にベーステーブルに大量の履歴データが含まれている場合、クエリを劇的に高速化できます。

別の例として、マルチテーブル結合の場合、オプティマイザーは、結合にあるテーブルの1つのために、テーブルではなくマテリアライズドビューの使用を決定する場合があります。

マテリアライズドビューは、サブクエリのデータソースとしても使用できます。

オプティマイザーが、マテリアライズドビューを暗黙的に使用することを選択した場合、マテリアライズドビューは、ベーステーブルではなく EXPLAIN プランまたはクエリプロファイルにリストされます。この情報を使用して、どのクエリが既存のマテリアライズドビューからメリットを得ることができるかを実験して理解することができます。

マテリアライズドビューの DDL コマンド¶

マテリアライズドビューは、ファーストクラスのデータベースオブジェクトです。Snowflakeには、マテリアライズドビューを作成および管理するための次の DDL コマンドが用意されています：

• CREATE MATERIALIZED VIEW

• ALTER MATERIALIZED VIEW

• DROP MATERIALIZED VIEW

• DESCRIBE MATERIALIZED VIEW

• SHOW MATERIALIZED VIEWS

マテリアライズドビューの DML 操作¶

Snowflakeは、マテリアライズドビューで標準の DML （例： INSERT、 UPDATE、 DELETE）を許可しません。Snowflakeでは、ユーザーがマテリアライズドビューを切り捨てることはできません。

詳細については、 マテリアライズドビューの使用における制約 （このトピック内）をご参照ください。

アクセス制御権限¶

マテリアライズドビューに関連する3種類の権限があります。

• マテリアライズドビューを含むスキーマに対する権限。

• マテリアライズドビュー自体に対する直接の権限。

• マテリアライズドビューがアクセスする、データベースオブジェクト（例: テーブル）に対する権限。

標準コマンドを使用して、マテリアライズドビューに対する権限の付与および取り消しができます。

• GRANT <権限>

• REVOKE <権限>

GRANT CREATE MATERIALIZED VIEW ON SCHEMA <schema_name> TO ROLE <role_name>;

マテリアライズドビューの保護¶

マテリアライズドビューはセキュアビューにすることができます。

セキュアビューに関するほとんどの情報は、セキュアマテリアライズドビューに適用されます。安全なマテリアライズドビューが安全な非マテリアライズドビューと異なる場合がいくつかあります。違いは次のとおりです：

• ビューがセキュアかどうかを確認するコマンド。

  • 非マテリアライズドビューの場合は、 SHOW VIEWS コマンドの出力の IS_SECURE 列を確認してください。

  • マテリアライズドビューの場合は、 SHOW MATERIALIZED VIEWS コマンドの出力の IS_SECURE 列を確認してください。

セキュアビューの詳細については、 セキュアビューの使用 をご参照ください。

安全なマテリアライズドビューを作成するための構文は、 CREATE MATERIALIZED VIEW に文書化されています。

マテリアライズドビューの作成計画¶

マテリアライズドビューの作成を決定する場合は、ビューの必要性を判断するために分析を行うことを検討してください。

1. 頻繁または高価なクエリのフィルター、予測、および集計を調べます。

2. クエリプロファイルと EXPLAIN コマンドを使用して、既存のマテリアライズドビューが、自動クエリ書き換え機能ですでに使用されているかどうかを確認します。クエリに適合する既存のビューがある場合は、新しいマテリアライズドビューを作成する必要がないことに気付く場合があります。

3. マテリアライズドビューを追加する前に、現在のクエリのコストとパフォーマンスを記録して、新しいマテリアライズドビューの作成後に違いを評価できるようにします。

4. テーブルをクラスタリングするメリットがない、非常に選択的なフィルターを持つクエリを見つけた場合、同じフィルターを含むマテリアライズドビューは、クエリが大量のデータをスキャンしないようにするために役立ちます。

   同様に、集計を使用するクエリ、または評価に非常にコストのかかる式（たとえば、高価な関数呼び出し、または半構造化データに対するコストの高い操作）を含むクエリを見つけた場合、同じ式を使用するマテリアライズドビューまたは集計はメリットを提供できます。

5. 元のクエリに対して EXPLAIN コマンドを実行するか、クエリを実行してクエリプロファイルを確認し、新しいマテリアライズドビューが使用されているかどうかを確認します。

6. 結合されたクエリ および マテリアライズドビューのコスト をモニターし、パフォーマンスまたはコストのメリットがマテリアライズドビューのメンテナンスのコストを正当化できるかどうかを評価します。

   ベーステーブルのクエリコストも調べます。オプティマイザーがクエリを書き換えてマテリアライズドビューを使用できる場合は、クエリのコンパイルにより多くの時間とリソースが消費される可能性があります。（オプティマイザーには、考慮すべき多くの可能性あり。）

7. マテリアライズドビューがクエリを簡略化する場合や、パフォーマンスを向上させることがわかっている場合は、いつでもマテリアライズドビューを直接参照できます。ただし、ほとんどの場合、ベーステーブルにクエリを実行するだけで、自動クエリ書き換え機能がこれを実行します。

マテリアライズドビューの作成¶

CREATE MATERIALIZED VIEW コマンドを使用して、マテリアライズドビューを作成します。例については、 基本的な例: マテリアライズドビューの作成 （このトピック内）をご参照ください。

マテリアライズドビューを作成するときは、以下の点に注意してください。

• マテリアライズドビューで許可されていない列名の処理

• ベーステーブルへの参照

• クエリ最適化のためのフィルターの指定

CREATE OR REPLACE MATERIALIZED VIEW mv AS
  SELECT SYSTEM$ALPHA AS col1, ...

マテリアライズドビューの作成に関する制限¶

マテリアライズドビューの作成には、次の制限が適用されます。

• マテリアライズドビューは単一のテーブルのみをクエリできます。

• 自己結合を含む結合はサポートされていません。

• マテリアライズドビューは次をクエリできません。

  • マテリアライズドビュー。

  • 非マテリアライズドビュー。

  • UDTF （ユーザー定義テーブル関数）。

• マテリアライズドビューには以下を含めることはできません。

  • UDFs （この制限は、外部関数を含むすべてのタイプのユーザー定義関数に適用されます）。

  • ウィンドウ関数。

  • HAVING 句。

  • ORDERBY 句。

  • LIMIT 句。

  • SELECT リスト内にないGROUP BY キー。マテリアライズドビューの GROUP BY キーはすべて、 SELECT リストの一部である必要があります。

  • GROUP BY GROUPING SETS

  • GROUP BY ROLLUP。

  • GROUP BY CUBE。

  • マテリアライズドビュー内のサブクエリのネスト。

  • MINUS、 EXCEPT、 または INTERSECT セット演算子。

• 多くの集計関数は、マテリアライズドビューの定義では許可されていません。

  • マテリアライズドビューで サポートされている 集計関数は次のとおりです。

    • APPROX_COUNT_DISTINCT （HLL）

    • AVG （ PIVOT で使用される場合を除く）。

    • BITAND_AGG。

    • BITOR_AGG。

    • BITXOR_AGG

    • COUNT

    • COUNT_IF。

    • MAX。

    • MIN。

    • STDDEV, STDDEV_SAMP。

    • STDDEV_POP。

    • SUM.

    • VARIANCE （VARIANCE_SAMP、 VAR_SAMP）

    • VARIANCE_POP （VAR_POP）

    その他の集計関数は、マテリアライズドビューでは サポートされていません。

  注釈

  マテリアライズドビューで許可される集計関数には、まだ次のいくつかの制限があります。

  • 集計関数はネストできません。

  • 複雑な式（例: (sum(salary)/10)）で使用される集計関数は、クエリの最も外側のレベルでのみ使用でき、サブクエリやインラインビューでは使用できません。

    たとえば、次は許可されています。

    create materialized view mv1 as
        select
            sum(x) + 100
          from t;
    

    Copy

    たとえば、次は許可されて いません。

    create materialized view mv2 as
        select
            y + 10
          from (
            select
              sum(x) as y
            from t
          );
    

    Copy

  • DISTINCT は集約関数と組み合わせることはできません。

  • マテリアライズドビューでは、集計関数 AVG、 COUNT、 COUNT_IF、 MIN、 MAX および SUM を集計関数として使用できますが、ウィンドウ関数としては使用できません。マテリアライズドビューでは、これらの関数を OVER 句と合わせて使用することはできません。

    OVER ( [ PARTITION BY <expr1> ] [ ORDER BY <expr2> ] )
    

    Copy

  • 集計関数がサブクエリ内にある場合、マテリアライズドビューは、そのサブクエリの集計列の上に式を作成できません。たとえば、次のマテリアライズドビューの定義を考えます。

    create or replace materialized view mv1 as
        select c1 + 10 as c1new, c2
            from (select sum(c1) as c1, c2 from t group by c2);
    

    Copy

    式「c1 + 10」は、サブクエリ内の集計関数の上部にある式であるため、エラーメッセージが表示されます。

    等号演算子も式としてみなされることに注意してください。つまり、サブクエリの集計関数を表す列を使用する CASE 式も禁止されます。

    この制限を回避するには、式のないマテリアライズドビューを作成し、次に式を含む非マテリアライズドビューを作成します。次に例を示します。

    create or replace materialized view mv1 as
        select c1, c2
            from (select sum(c1) as c1, c2 from t group by c2);
    
    create or replace view expr_v1 as
        select c1 + 10 as c1new, c2
            from (select c1, c2 from mv1);
    

    Copy

• マテリアライズドビューで使用される関数は決定論的でなければなりません。たとえば、 CURRENT_TIME または CURRENT_TIMESTAMP の使用は許可されていません。

• セッションレベルのパラメーター TIMESTAMP_TYPE_MAPPING など、パラメーターの設定ごとに異なる結果を生成する関数を使用してマテリアライズドビューを定義しないでください。

  たとえば、ビューが次のように定義されているとします。

  create materialized view bad_example (ts1) as
      select to_timestamp(n) from t1;
  

  Copy

  TO_TIMESTAMP(n) からの戻り値のデータ型はパラメーター TIMESTAMP_TYPE_MAPPING に依存するため、マテリアライズドビューの内容は、ビューが作成されたときの TIMESTAMP_TYPE_MAPPING の値に依存します。

  マテリアライズドビューが作成されると、その各列を定義する式が評価され、保存されます。列の定義が特定のセッション変数に依存しており、セッション変数が変更された場合、式は再評価されず、マテリアライズドビューは更新されません。マテリアライズドビューがセッション変数の特定の値に依存しており、セッション変数の値が変更されている場合は、マテリアライズドビューに対するクエリに失敗します。

  この問題を回避するには、セッション変数に依存しない値に式を強制します。以下の例は、 TIMESTAMP_TYPE_MAPPING パラメーターとは関係なく、出力を特定のデータ型にキャストします。

  create materialized view good_example (ts1) as
      select to_timestamp(n)::TIMESTAMP_NTZ from t1;
  

  Copy

  これは、 マテリアライズド ビューに特有の問題です。非マテリアライズドビューは、現在のパラメーター設定に基づいて動的に出力を生成するため、結果が古くなることはありません。

• マテリアライズドビューの定義で、 FLATTEN 関数の出力から SEQ 列を選択することはサポートされていません。

  マテリアライズドビューから選択された場合、 SEQ 列の値は、いかなる順序も保証されません。マテリアライズドビュー定義でこの列を選択すると、出力が不確定になる場合があります。

• マテリアライズドビューは、 Time Travel機能 を使用して作成することはできません。

基本的な例: マテリアライズドビューの作成¶

このセクションには、マテリアライズドビューの作成と使用の基本的な例が含まれています。

CREATE OR REPLACE MATERIALIZED VIEW mv1 AS
  SELECT My_ResourceIntensive_Function(binary_col) FROM table1;

SELECT * FROM mv1;

Copy

より詳細な例は、（このトピック）の 例 にあります。

マテリアライズドビューのメンテナンス方法について¶

マテリアライズドビューを作成した後、バックグラウンドプロセスが自動的にデータをマテリアライズドビューに保持します。次の点に注意してください。

• マテリアライズドビューのメンテナンスはバックグラウンドプロセスで実行され、そのタイミングはベーステーブルとマテリアライズドビューの作業負荷に基づいて最適化されます。

  • このプロセスでは、 DML 操作によってベーステーブルに加えられた変更（挿入、更新、および削除）によって、マテリアライズドビューが更新されます。

    さらに、ベーステーブルのクラスタリングによってマテリアライズドビューがリフレッシュされることもあります。 マテリアライズドビューとそのベーステーブルをクラスタリングするためのベストプラクティス をご参照ください。

  • ベーステーブルに行が挿入されると、プロセスは「リフレッシュ」操作を実行して、マテリアライズドビューに新しい行を挿入します。

  • ベーステーブルで行が削除されると、プロセスはマテリアライズドビューに対して「圧縮」操作を実行し、これらの行をマテリアライズドビューから削除します。

• マテリアライズドビューが最後にリフレッシュされた時刻を確認するには、 SHOW MATERIALIZED VIEWS コマンドを実行します。

  出力の REFRESHED_ON と BEHIND_BY 列を確認します。

  • REFRESHED_ON 列と COMPACTED_ON 列は、それぞれリフレッシュ操作と圧縮操作によって処理されたベーステーブルにある最後の DML 操作のタイムスタンプを示しています。

  • BEHIND_BY 列は、マテリアライズドビューの更新がベーステーブルの更新より遅れている時間量を示します。

• メンテナンスが遅れると、ビューが最新の場合よりもクエリの実行が遅くなる可能性がありますが、結果は常に最新のものになります。

  マテリアライズドビューの一部のマイクロパーティションが古い場合、Snowflakeはそれらのパーティションをスキップし、ベーステーブルからのデータを検索します。

• バックグラウンドプロセスで特定のユーザーエラーが発生した場合（例: ビューに対するクエリの結果が「ゼロ除算」エラーになった場合）、プロセスはマテリアライズドビューを無効にします。

  無効なマテリアライズドビューをクエリするとエラーになります。エラーメッセージには、マテリアライズドビューが無効になった理由が含まれます。例:

  Failure during expansion of view 'MY_MV':
    SQL compilation error: Materialized View MY_MV is invalid.
    Invalidation reason: Division by zero
  

  この問題が発生した場合は、エラーメッセージに記載されている問題を解決し（例: 「ゼロ除算」エラーが発生した行を削除）、 ALTER MATERIALIZED VIEW ... RESUME コマンドを使用してマテリアライズドビューを再開します。

マテリアライズドビューのメンテナンスの中断および再開¶

マテリアライズドビューのメンテナンスと使用を中断する必要がある場合は、 SUSPEND パラメーターを指定して ALTER MATERIALIZED VIEW コマンドを実行します。

ALTER MATERIALIZED VIEW <name> SUSPEND

ビューのメンテナンスを中断すると、メンテナンスを再開するまでビューはクエリできません。

マテリアライズドビューのメンテナンスと使用を再開するには、 RESUME パラメーター指定して ALTER MATERIALIZED VIEW コマンドを実行します。

ALTER MATERIALIZED VIEW <name> RESUME

例については、 マテリアライズドビューの更新の中断 をご参照ください。

マテリアライズドビューに関する情報の表示¶

次のコマンドとビューは、マテリアライズドビューに関する情報を提供します。

• SHOW VIEWS コマンドは、マテリアライズドビューと通常ビューの両方に関する情報を返します。

• INFORMATION_SCHEMA.TABLES ビュー は、マテリアライズドビューを表示します。 TABLE_TYPE 列には「MATERIALIZED VIEW」が表示されます。マテリアライズドビューには直接挿入できないため、 IS_INSERTABLE 列は常に「NO」です。

  注釈

  INFORMATION_SCHEMA.VIEWS ビュー はマテリアライズドビューを表示しません。マテリアライズドビューは、 INFORMATION_SCHEMA.TABLES で表示されます。

マテリアライズドビューの使用における制約¶

マテリアライズドビューの使用には、次の制限が適用されます。

• マテリアライズドビューが定義されているベーステーブルと一貫性を保つために、マテリアライズドビュー自体では、ほとんどの DML 操作を実行できません。たとえば、マテリアライズドビューに行を直接挿入することはできません（もちろん、ベーステーブルには行を挿入できます）。禁止されている DML 操作は次のとおりです：

  • COPY

  • DELETE

  • INSERT

  • MERGE

  • UPDATE

  マテリアライズドビューの切り捨てはサポートされていません。

• CREATE MATERIALIZED VIEW ... CLONE... コマンドを使用して、マテリアライズドビューを直接クローンすることはできません。ただし、マテリアライズドビューを含むスキーマまたはデータベースをクローンすると、マテリアライズドビューがクローンされ、新しいスキーマまたはデータベースに含まれます。

• Snowflakeは、 Time Travel機能 を使用して 過去の時点 でマテリアライズドビューをクエリすることをサポートしていません（例: マテリアライズドビューをクエリするときに AT 句 を使用する）。

  ただし、Time Travelを使用して、 マテリアライズドビューを含んでいるデータベースまたはスキーマを過去の時点でクローン することはできます。詳細については、 マテリアライズドビューおよびTime Travel をご参照ください。

• マテリアライズドビューは、Snowflake リソースモニターの操作 によってモニターされません。

マテリアライズドビューにおけるベーステーブルの変更による影響¶

次のセクションでは、ベーステーブルの変更によってマテリアライズドビューがどのような影響を受けるかを説明します。

• ベーステーブルへの列の追加

• ベーステーブルの列の変更またはドロップ

• ベーステーブルの名前変更またはスワップ

• ベーステーブルのドロップ

クローンされたスキーマとデータベースのマテリアライズドビュー¶

マテリアライズドビューが含まれたスキーマまたはデータベースをクローンすると、マテリアライズドビューがクローンされます。

マテリアライズドビューと対応するベーステーブルを（同一の CREATE SCHEMA ... CLONE または CREATE DATABASE ... CLONE 操作の一部として）同時にクローンする場合、クローンされたマテリアライズドビューは、クローンされたベーステーブルを参照します。

ベーステーブルをクローンせずにマテリアライズドビューをクローンする場合（例: テーブルがデータベース1.スキーマ1、ビューがデータベース1.スキーマ2にあり、データベース1すべてではなく、スキーマ2のみをクローン）、クローンビューは元のベーステーブルを参照します。

コストの見積もりと管理¶

マテリアライズドビューを維持するためのコストを見積もるツールはありません。一般的に、コストは次の要素に比例します：

• 各ベーステーブルで作成されるマテリアライズドビューの数、およびベーステーブルが変更されたときに各マテリアライズドビューで変更されるデータの量。ベーステーブルのマイクロパーティションを変更すると、再クラスタリングによるものか、ベーステーブルでの DML ステートメントの実行によるものかに関わらず、最終的にマテリアライズドビューのメンテナンスが必要になります。

• クラスタ化されているマテリアライズドビューの数。（テーブルまたはマテリアライズドビューの）クラスタリングを維持すると、コストが増加します。

  マテリアライズドビューがベーステーブルとは異なる方法でクラスター化されている場合、マテリアライズドビューで変更されたマイクロパーティションの数は、ベーステーブルで変更されたマイクロパーティションの数よりも大幅に多くなる可能性があります。

  たとえば、ベーステーブルがデータの挿入（追加）によって大幅に変更され、クラスタ化されていないため、ベーステーブルは主に行がテーブルに挿入された順序になっているとします。マテリアライズドビューが、郵便番号などの独立した列によってクラスター化されていると想像してください。新しく100行がベーステーブルに追加されると、それらは1つまたは2つの新しいマイクロパーティションに入れられ、ベーステーブル内の他のマイクロパーティションはそのまま残ります。ただし、これらの100行では、クラスター化されたマテリアライズドビューの100個のマイクロパーティションを書き換える必要がある場合があります。

  別の例として、削除を検討してください。クラスター化されていないベーステーブルの最も古い行を削除すると、最も古いマイクロパーティションのみが削除される可能性がありますが、マテリアライズドビューで、経過時間によってクラスター化されていないはるかに多数のマイクロパーティションへの変更が必要になる場合があります。

  （マテリアライズドビューのクラスタリングの詳細については、 マテリアライズドビューとクラスタリング をご参照ください。）

作成するビューの数、作成するテーブル、および各ビューの定義（そのビューの行と列の数を含む）を慎重に選択することにより、マテリアライズドビューの維持コストを制御できます。

また、マテリアライズドビューを中断または再開することにより、コストを制御できます。ただし、メンテナンスの中断は通常、コストを削減するのではなく、延期するだけです。メンテナンスが延期されているほど、より多くのメンテナンスを行う必要があります。

マテリアライズドビューを維持するためのベストプラクティス もご参照ください。

コストの表示¶

マテリアライズドビューを維持するための請求費用は、 Snowsight、 Classic Console、または SQL を使用して表示できます。

Snowsight:

適切な権限 を持つユーザーとして、 Admin » Cost Management » Consumption を選択します。

All Service Types フィルターを使用し、 Materialized View を選択します。

Classic Console:

アカウント管理者として、 Account » Billing & Usage を選択します。

クレジットコストは、Snowflakeが提供する MATERIALIZED_VIEW_MAINTENANCE という名前の仮想ウェアハウスで追跡されます。

SQL:

次のいずれかをクエリします。

• MATERIALIZED_VIEW_REFRESH_HISTORY テーブル関数（ Snowflake Information Schema 内）。

  例:

  SELECT * FROM TABLE(INFORMATION_SCHEMA.MATERIALIZED_VIEW_REFRESH_HISTORY());
  

  Copy

• MATERIALIZED_VIEW_REFRESH_HISTORY ビュー ビュー（ Account Usage 内）。

  MATERIALIZED_VIEW_REFRESH_HISTORY ビューに対して次のクエリを実行できます。

  クエリ: マテリアライズドビューのコスト履歴（日別、オブジェクト別）

  このクエリは、マテリアライズドビューの包括的リストと、過去30日間にサービスを介して消費したクレジット量を日別に表示します。クレジットの消費に不規則性があるか、一貫して消費量が多い場合は、さらに調査する必要があることを表します。

  SELECT TO_DATE(start_time) AS date,
    database_name,
    schema_name,
    table_name,
    SUM(credits_used) AS credits_used
  FROM snowflake.account_usage.materialized_view_refresh_history
  WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP())
  GROUP BY 1,2,3,4
  ORDER BY 5 DESC;
  

  Copy

  クエリ: マテリアライズドビュー履歴およびm日平均

  このクエリは、マテリアライズドビューによって消費された日次の平均クレジットを、前年の週別にグループ化して表示します。1年間の日次平均の異常を特定するのに役立ちます。これにより、消費の急増や予期しない変化をさらに調査することができます。

  WITH credits_by_day AS (
    SELECT TO_DATE(start_time) AS date,
      SUM(credits_used) AS credits_used
    FROM snowflake.account_usage.materialized_view_refresh_history
    WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP())
    GROUP BY 1
    ORDER BY 2 DESC
  )
  
  SELECT DATE_TRUNC('week',date),
    AVG(credits_used) AS avg_daily_credits
  FROM credits_by_day
  GROUP BY 1
  ORDER BY 1;
  

  Copy

マテリアライズドビューを作成するためのベストプラクティス¶

• ほとんどのマテリアライズドビューは、次のいずれかまたは両方を実行する必要があります：

  • データをフィルタリングします。これを実行するには：

    • 行をフィルタリングします（例: 非常に最近のデータのみが含まれるようにマテリアライズドビューを定義）。一部のアプリケーションでは、保存に最適なデータは異常なデータです。たとえば、ガスパイプラインの圧力をモニターしてパイプの故障の可能性を推定する場合、ベーステーブルにはすべての圧力データを保存し、マテリアライズドビューには異常に高い圧力測定値のみを保存します。同様に、ネットワークトラフィックをモニターしている場合、ベーステーブルにはすべてのモニター情報が保存される可能性がありますが、マテリアライズドビューには、異常で疑わしい情報（例: DOS （サービス拒否）攻撃を開始することが知られている IP アドレスからの情報）のみが保存される可能性があります。

    • 列をフィルタリングします（例: 「SELECT * ...」ではなく特定の列を選択）。通常、 SELECT * ... を使用してマテリアライズドビューを定義するには、高額な費用がかかります。また、将来のエラーにつながる可能性があります。後でベーステーブルに列が追加される場合（例: ALTER TABLE ... ADD COLUMN ...）、マテリアライズドビューには新しい列が自動的に組み込まれません。

  • リソースを集中的に使用する操作を実行し、結果を保存して、リソースを集中的に使用する操作を頻繁に実行する必要がないようにします。

• 同じベーステーブルに対して複数のマテリアライズドビューを作成できます。たとえば、最新のデータのみを含む1つのマテリアライズドビューと、異常なデータを格納する別のマテリアライズドビューを作成できます。その後、2つのテーブルを結合し、異常な履歴データと一致する最近のデータを表示する非マテリアライズドビューを作成して、増加している DOS （サービス拒否）攻撃などの異常な状況をすばやく検出できます。

  Snowflakeは、次の場合にのみ、異常なデータのマテリアライズドビューをお勧めします。

  • ベーステーブルがクラスタ化されていないか、異常なデータを含む列がベーステーブルのクラスタリングキーの一部ではない場合。

  • データは簡単に分離できるほど異常ではあるものの、ほとんど使用されないほど異常ではない場合。（データがほとんど使用されない場合、使用時に迅速にアクセスできるため、マテリアライズドビューを維持するためのコストは、パフォーマンス上のメリットとコスト節約を上回る可能性があります。）

マテリアライズドビューを維持するためのベストプラクティス¶

• Snowflakeは、ベーステーブルでDML操作をバッチ処理することをお勧めします。

  • DELETE: テーブルに最新の期間（例: 最新の日、週、月）のデータが格納されている場合は、古いデータを削除してベーステーブルをトリミングすると、ベーステーブルへの変更がマテリアライズドビューに反映されます。データがマイクロパーティション全体にどのように分散されているかによっては、マテリアライズドビューのバックグラウンド更新により多くの費用がかかる可能性があります。場合によっては、削除の頻度を減らすことでコストを削減できる場合があります（例えば、1時間ごとではなく1日ごと、または10分ごとではなく1時間ごと）。

    特定の量の古いデータを保持する必要がない場合は、コストと機能の最適なバランスを見つけるために実験する必要があります。

  • INSERT、 UPDATE、および MERGE ：ベーステーブルでこれらのタイプの DML ステートメントをバッチ処理すると、マテリアライズドビューを維持するコストを削減できます。

マテリアライズドビューとそのベーステーブルをクラスタリングするためのベストプラクティス¶

• ベーステーブルにマテリアライズドビューを作成し、マテリアライズドビューに頻繁にアクセスし、ベーステーブルには頻繁にアクセスしない場合は、通常、ベーステーブルのクラスタリングを回避する方が効率的です。

  クラスター化されたテーブルにマテリアライズドビューを作成する場合は、ベーステーブルのクラスタリングを削除することを検討してください。ベーステーブルのクラスター化を変更すると、最終的にマテリアライズドビューの更新が必要になり、マテリアライズドビューのメンテナンスコストが増加するためです。

• マテリアライズドビュー、特に頻繁に変更されるベーステーブルのマテリアライズドビューをクラスタリングすると、コストが増加します。必要以上にマテリアライズドビューをクラスタ化しないでください。

• テーブルのクラスタリングに関するほとんどすべての情報は、マテリアライズドビューのクラスタリングにも適用されます。テーブルのクラスタリングの詳細については、 クラスタリングキーを選択するための戦略 をご参照ください。

単純なマテリアライズドビュー¶

この最初の例は、単純なマテリアライズドビューと、ビューに対する単純なクエリを示しています。

テーブルを作成してデータをロードし、ビューを作成します。

CREATE TABLE inventory (product_ID INTEGER, wholesale_price FLOAT,
  description VARCHAR);
    
CREATE OR REPLACE MATERIALIZED VIEW mv1 AS
  SELECT product_ID, wholesale_price FROM inventory;

INSERT INTO inventory (product_ID, wholesale_price, description) VALUES 
    (1, 1.00, 'cog');

Copy

ビューからデータを選択します。

SELECT product_ID, wholesale_price FROM mv1;
+------------+-----------------+
| PRODUCT_ID | WHOLESALE_PRICE |
|------------+-----------------|
|          1 |               1 |
+------------+-----------------+

Copy

マテリアライズドビューの結合¶

マテリアライズドビューは、テーブルまたは別のビューと結合できます。この例では、前述の例に追加のテーブルを作成し、次にマテリアライズドビューをテーブルに結合して、利益を表示する非マテリアライズドビューを作成します。

CREATE TABLE sales (product_ID INTEGER, quantity INTEGER, price FLOAT);

INSERT INTO sales (product_ID, quantity, price) VALUES 
   (1,  1, 1.99);

CREATE or replace VIEW profits AS
  SELECT m.product_ID, SUM(IFNULL(s.quantity, 0)) AS quantity,
      SUM(IFNULL(quantity * (s.price - m.wholesale_price), 0)) AS profit
    FROM mv1 AS m LEFT OUTER JOIN sales AS s ON s.product_ID = m.product_ID
    GROUP BY m.product_ID;

Copy

ビューからデータを選択します。

SELECT * FROM profits;
+------------+----------+--------+
| PRODUCT_ID | QUANTITY | PROFIT |
|------------+----------+--------|
|          1 |        1 |   0.99 |
+------------+----------+--------+

Copy

マテリアライズドビューの更新の中断¶

次の例は、 mv1 マテリアライズドビューの使用（およびメンテナンス）を一時的に中断し、そのビューに対するクエリがマテリアライズドビューの中断中にエラーメッセージを生成することを示しています。

ALTER MATERIALIZED VIEW mv1 SUSPEND;
    
INSERT INTO inventory (product_ID, wholesale_price, description) VALUES 
    (2, 2.00, 'sprocket');

INSERT INTO sales (product_ID, quantity, price) VALUES 
   (2, 10, 2.99),
   (2,  1, 2.99);

Copy

マテリアライズドビューからデータを選択します。

SELECT * FROM profits ORDER BY product_ID;

Copy

出力:

002037 (42601): SQL compilation error:
Failure during expansion of view 'PROFITS': SQL compilation error:
Failure during expansion of view 'MV1': SQL compilation error: Materialized View MV1 is invalid.

再開:

ALTER MATERIALIZED VIEW mv1 RESUME;

Copy

マテリアライズドビューからデータを選択します。

SELECT * FROM profits ORDER BY product_ID;
+------------+----------+--------+
| PRODUCT_ID | QUANTITY | PROFIT |
|------------+----------+--------|
|          1 |        1 |   0.99 |
|          2 |       11 |  10.89 |
+------------+----------+--------+

Copy

マテリアライズドビューのクラスタリング¶

この例では、マテリアライズドビューを作成し、後でそれをクラスター化します。

これらのステートメントは、パイプラインのセグメントに関する情報を追跡する2つのテーブルを作成します（例: 天然ガス用）。

近い将来に故障する可能性が最も高いセグメントは、多くの場合、最も古いセグメント、腐食しやすい材料、または異常に高い圧力の期間を経験した材料でできているセグメントです。この例では、各パイプの年齢、圧力、および材料（鉄、銅、 PVC プラスチックなど）を追跡します。

CREATE TABLE pipeline_segments (
    segment_ID BIGINT,
    material VARCHAR, -- e.g. copper, cast iron, PVC.
    installation_year DATE,  -- older pipes are more likely to be corroded.
    rated_pressure FLOAT  -- maximum recommended pressure at installation time.
    );
    
INSERT INTO pipeline_segments 
    (segment_ID, material, installation_year, rated_pressure)
  VALUES
    (1, 'PVC', '1994-01-01'::DATE, 60),
    (2, 'cast iron', '1950-01-01'::DATE, 120)
    ;

CREATE TABLE pipeline_pressures (
    segment_ID BIGINT,
    pressure_psi FLOAT,  -- pressure in Pounds per Square Inch
    measurement_timestamp TIMESTAMP
    );
INSERT INTO pipeline_pressures 
   (segment_ID, pressure_psi, measurement_timestamp) 
  VALUES
    (2, 10, '2018-09-01 00:01:00'),
    (2, 95, '2018-09-01 00:02:00')
    ;

Copy

パイプラインセグメントはあまり頻繁に変更されず、最も古いパイプラインセグメントが最も故障する可能性が高いセグメントであるため、最も古いセグメントのマテリアライズドビューを作成します。

CREATE MATERIALIZED VIEW vulnerable_pipes 
  (segment_ID, installation_year, rated_pressure) 
  AS
    SELECT segment_ID, installation_year, rated_pressure
        FROM pipeline_segments 
        WHERE material = 'cast iron' AND installation_year < '1980'::DATE;

Copy

クラスタリングを追加したり、クラスタリングキーを変更したりできます。例えば、 installation_year でクラスタリングするには：

ALTER MATERIALIZED VIEW vulnerable_pipes CLUSTER BY (installation_year);

Copy

新しい圧力測定値は頻繁に（おそらく10秒ごとに）到着するため、圧力測定値のマテリアライズドビューを維持するには高額の費用がかかります。したがって、最近の圧力データの高度な性能（高速な取得）が重要であるにもかかわらず、 pipeline_pressures テーブルは、マテリアライズドビューなしで開始されます。

パフォーマンスが遅すぎる場合は、最近の圧力データのみを含むか、異常高圧時に関するデータのみを含む、マテリアライズドビューを作成できます。

マテリアライズドビューと pipeline_pressures テーブルの情報を結合する（非マテリアライズド）ビューを作成します。

CREATE VIEW high_risk AS
    SELECT seg.segment_ID, installation_year, measurement_timestamp::DATE AS measurement_date, 
         DATEDIFF('YEAR', installation_year::DATE, measurement_timestamp::DATE) AS age, 
         rated_pressure - age AS safe_pressure, pressure_psi AS actual_pressure
       FROM vulnerable_pipes AS seg INNER JOIN pipeline_pressures AS psi 
           ON psi.segment_ID = seg.segment_ID
       WHERE pressure_psi > safe_pressure
       ;

Copy

次に、リスクの高いパイプラインセグメントをリストします：

SELECT * FROM high_risk;
+------------+-------------------+------------------+-----+---------------+-----------------+
| SEGMENT_ID | INSTALLATION_YEAR | MEASUREMENT_DATE | AGE | SAFE_PRESSURE | ACTUAL_PRESSURE |
|------------+-------------------+------------------+-----+---------------+-----------------|
|          2 | 1950-01-01        | 2018-09-01       |  68 |            52 |              95 |
+------------+-------------------+------------------+-----+---------------+-----------------+

Copy

これは、腐食する材料でできている segment_id = 2 のパイプラインセグメントが古いことを示しています。このセグメントは、設置時の最大圧力定格よりも高い圧力を経験したことはありませんが、腐食の可能性があるため、その「安全限界」は時間とともに低下し、また、経験した最高圧力は、圧力測定時のパイプと同じくらい古いパイプに推奨された圧力よりも高いです。

共有データでのマテリアライズドビューの作成¶

共有データ上にマテリアライズドビューを作成できます。

アカウント1:

create or replace table db1.schema1.table1(c1 int);
create or replace share sh1;
grant usage on database db1 to share sh1;
alter share sh1 add accounts = account2;
grant usage on schema db1.schema1 to share sh1;
grant select on table db1.schema1.table1 to share sh1;

アカウント2：

create or replace database dbshared from share account1.sh1;
create or replace materialized view mv1 as select * from dbshared.schema1.table1 where c1 >= 50;

マテリアライズドビューの共有¶

Snowflakeのデータ共有機能を使用して、マテリアライズドビューを共有できます。

データ共有の詳細については、 Snowflakeでのデータ共有とコラボレーション をご参照ください。

コンパイルエラー： Failure during expansion of view '<名前>': SQL compilation error: Materialized View <名前> is invalid.¶

考えられる原因:

• マテリアライズドビューが中断された。ビューの中断と再開の詳細については、 ALTER MATERIALIZED VIEW をご参照ください。

• マテリアライズドビューのベーステーブルの変更により、マテリアライズドビューが無効になった。たとえば、次の場合にこのエラーが返されます。

  • ベーステーブルがドロップされた。

  • ベーステーブル列の列が削除された。

• バックグラウンドプロセスで特定の種類のエラー（例: 「ゼロ除算」エラー）が発生し、マテリアライズドビューのリフレッシュに失敗した。

考えられる解決策:

• ビューが中断されている場合、

  • ALTER MATERIALIZED VIEW ... RESUME を実行してビューを再開することを検討してください。

  • ベーステーブルに対してクエリを実行することを検討してください。ただし、これはマテリアライズドビューに対してクエリを実行するよりも多くのクレジットを消費し、時間がかかる可能性があります。

• ベーステーブルが変更またはドロップされている場合、

  • ベーステーブルがドロップされている場合は、マテリアライズドビューをドロップします。

  • ベーステーブルが変更されており（例: ビューによって参照される列をドロップしている）、マテリアライズドビューが新しいバージョンのテーブルでも引き続き役立つ場合は、マテリアライズドビューをドロップし、ベーステーブルに残っている列を使用して、マテリアライズドビューを再作成することを検討してください。

  • これら以外のエラーメッセージの原因が明らかでない場合は、マテリアライズドビューをドロップして再作成することを検討してください。

  • ベーステーブルに対してクエリを実行することを検討してください。ただし、これはマテリアライズドビューに対してクエリを実行するよりも多くのクレジットを消費し、時間がかかる可能性があります。

• バックグラウンドプロセスがエラーによってマテリアライズドビューのリフレッシュに失敗した場合は、エラーメッセージに、マテリアライズドビューが無効になった理由の詳細が含まれます。例:

  Failure during expansion of view 'MY_MV':
    SQL compilation error: Materialized View MY_MV is invalid.
    Invalidation reason: Division by zero
  

この問題が発生した場合は、エラーメッセージに記載されている問題に対処し、 ALTER MATERIALIZED VIEW ... RESUME コマンドを使用してマテリアライズドビューを再開します。

SHOW MATERIALIZED VIEWS コマンドは更新されていないマテリアライズドビューを表示する¶

考えられる原因:

考えられる原因の1つは、ビュー定義の SELECT ステートメントに失敗したため、リフレッシュに失敗したことです。

リフレッシュはバックグラウンドプロセスで実行されるため、リフレッシュ時にエラーメッセージが表示されることはありません。代わりに、マテリアライズドビューにクエリを実行したとき、または SHOW MATERIALIZED VIEWS を実行したときにエラーメッセージが表示されます。

考えられる解決策:

invalid 列が true の場合は、 invalid_reason 列でビューが無効となった理由を確認します。

場合によっては、マテリアライズドビューの定義で SELECT ステートメントを手動で実行するか、マテリアライズドビューの定義で参照されるテーブルでより単純な（より安価な） SELECT ステートメントを実行することで、問題をデバッグできる場合があります。

マテリアライズドビューの正確な定義がわからない場合は、 SHOW MATERIALIZED VIEWS の出力で見つけるか、 GET_DDL 関数を使用して見つけることができます。