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

Snowflake logo in black (no text) Enterprise Editionの機能

マテリアライズドビューにはEnterprise Editionが必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。

マテリアライズドビューは、クエリ仕様（ビュー定義の SELECT ）から派生した事前に計算されたデータセットであり、後で使用するために保存されます。データは事前に計算されているため、マテリアライズドビューのクエリは、ビューのベーステーブルに対してクエリを実行するよりも高速です。このパフォーマンスの違いは、クエリが頻繁に実行される場合、または非常に複雑な場合に顕著になります。その結果、マテリアライズドビューは、特に頻繁に実行され、大規模なデータセットで実行される、高価な集計、射影、および選択操作を高速化できます。

注釈

マテリアライズドビューは、一般的な繰り返しのクエリパターンで構成される、ワークロードのクエリパフォーマンスを向上させるように設計されています。ただし、中間結果を具体化すると、 追加コスト が発生します。そのため、マテリアライズドビューを作成する前に、これらの結果を十分頻繁に再利用して得られる節約分が、コストを相殺できるかどうかを検討する必要があります。

このトピックの内容:

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

マテリアライズドビューは、次の場合に特に役立ちます。

  • クエリ結果に、ベーステーブル（ビューが定義されているテーブル）と関連する少数の行や列が含まれる場合。

  • クエリ結果には、次のような重要な処理が必要な結果が含まれます：

    • 半構造化データの分析。

    • 計算に時間がかかる集計。

  • クエリは外部テーブル（つまり、外部ステージのファイルに格納されているデータセット）上にあり、ネイティブデータベーステーブルのクエリに比べてパフォーマンスが低下する可能性があります。

  • ビューのベーステーブルが頻繁に変更されない場合。

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

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

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

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

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

重要

マテリアライズドビューの自動メンテナンスはクレジットを消費します。詳細については、 マテリアライズドビューのメンテナンスコスト （このトピック内）をご参照ください。

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

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

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

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

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

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

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

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

    • 結果は頻繁に使用されません（結果が変更される割合と比較して）。

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

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

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

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

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

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

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

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

  • クエリセキュリティ。

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

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

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

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

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

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

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

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

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

パフォーマンスの利点

セキュリティ上の利点

クエリロジックを簡素化

クラスタリングをサポート

ストレージを使用

メンテナンスにクレジットを使用

注意

通常のテーブル

✔

✔

通常のビュー

✔

✔

キャッシュされたクエリ結果

✔

データが変更されておらず、クエリが決定的関数のみを使用する場合（例えば、 CURRENT_DATEではない場合）にのみ使用されます。

マテリアライズドビュー

✔

✔

✔

✔

✔

✔

通常、ストレージとメンテナンスの要件により、 コストが増加 します。

外部テーブル

データは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 プランまたはクエリプロファイルにリストされます。この情報を使用して、どのクエリが既存のマテリアライズドビューからメリットを得ることができるかを実験して理解することができます。

Snowflakeのマテリアライズドビューについて

次のセクションでは、マテリアライズドビューがSnowflakeでどのように表現されるかを説明します。

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

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

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

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

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

アクセス制御権限

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

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

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

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

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

マテリアライズドビューのスキーマに対する権限

マテリアライズドビューはストレージスペースを消費します。マテリアライズドビューを作成するには、マテリアライズドビューを含むスキーマに対する CREATE MATERIALIZED VIEW 権限が必要です。次のようなステートメントを実行する必要があります。

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

GRANT ステートメントの詳細については、 GRANT <権限> ... TO ROLE をご参照ください。

マテリアライズドビューの権限

マテリアライズドビューは、他のデータベースオブジェクト（テーブル、ビュー、 UDFsなど）と同様に、ロールによって所有され、他のロールに付与できる権限を持っています。

マテリアライズドビューに対して次の権限を付与できます。

  • SELECT

非マテリアライズドビューと同様に、マテリアライズドビューはそのベーステーブルの権限を自動的に継承しません。マテリアライズドビューの権限は、そのビューを使用するロールに明示的に付与する必要があります。

注釈

このルールの例外は、クエリオプティマイザーが、マテリアライズドビューを使用するようにベーステーブルに対するクエリを書き換える場合です（クエリオプティマイザーがマテリアライズドビューを使用する方法 で説明のとおり）。この場合、ユーザーがクエリの結果にアクセスするのに、マテリアライズドビューを使用する権限は必要ありません。

マテリアライズドビューによってアクセスされるデータベースオブジェクトの権限

マテリアライズドビューにアクセスするユーザーは、マテリアライズドビュー以外の場合と同様に、ビューが参照する基になるオブジェクトではなく、ビューに対する権限のみが必要です。

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

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

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

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

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

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

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

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

マテリアライズドビューの作成と使用

このセクションでは、マテリアライズドビューの作成と使用に関する情報を提供します。

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

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

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

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

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

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

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

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

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

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

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

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

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

次の点に注意してください。

  • 可能な場合はいつでも、マテリアライズドビューで参照されるベーステーブルの完全修飾名を使用してください。これにより、ベーステーブルをビューから別のスキーマに移動する（またはその逆）など、ビューを無効にする可能性のある変更からビューが隔離されます。

    ベーステーブルの名前を修飾しないで、テーブルまたはビューを別のスキーマに移動すると、参照は無効になります。

  • ビュー定義でベーステーブルを複数回参照している場合は、ベーステーブルへのすべての参照で、同じ修飾子を使用してください。たとえば、完全修飾名を使用する場合は、ベーステーブルへのすべての参照で、完全修飾名が使用されていることを確認します。

  • マテリアライズドビュー（例: WHERE column_1 BETWEEN Y and Z）の作成時にフィルターを指定すると、オプティマイザーは、同じフィルターまたはより制限されたフィルターを持つベーステーブルに対するクエリにマテリアライズドビューを使用できます。次にいくつかの例を示します。

    • 以下は、包摂範囲の簡単な例です。この例では、クエリのフィルターがマテリアライズドビューのフィルターと一致しません。ただし、クエリのフィルターは、マテリアライズドビューにある行のみを選択するため、オプティマイザーはテーブル全体ではなく、マテリアライズドビューのスキャンを選択できます。

      -- Example of a materialized view with a range filter
create materialized view v1 as
    select * from table1 where column_1 between 100 and 400;

      -- Example of a query that might be rewritten to use the materialized view
select * from table1 where column_1 between 200 and 300;

    • この例は、 OR 包摂を示しています。マテリアライズドビューには、後続のクエリに必要なすべての行が含まれています。

      値Xまたは値Yのいずれかを持つすべての行を含むマテリアライズドビューを定義します。

      create materialized view mv1 as
    select * from tab1 where column_1 = X or column_1 = Y;

      値Y（マテリアライズドビューに含まれている）のみを検索するクエリを定義します。

      select * from tab1 where column_1 = Y;

      上記のクエリは、次のように内部的に書き換えることができます。

      select * from mv1 where column_1 = Y;

    • この例は、 OR 包摂の別の例です。マテリアライズドビューの定義に明示的な OR はありません。ただし、 IN 句は一連の OR 式と同等であるため、オプティマイザーは、上記の OR 包摂の例を書き直した場合と同じ方法でこのクエリを書き直すことができます。

      create materialized view mv1 as
    select * from tab1 where column_1 in (X, Y);

      値Y（マテリアライズドビューに含まれている）のみを検索するクエリを定義します。

      select * from tab1 where column_1 = Y;

      上記のクエリは、次のように内部的に書き換えることができます。

      select * from mv1 where column_1 = Y;

    • この例では、 AND 包摂を使用しています。

      条件が column_1 = X であるすべての行を含むマテリアライズドビューを作成します。

      create materialized view mv2 as
    select * from table1 where column_1 = X;

      クエリを作成します。

      select column_1, column_2 from table1 where column_1 = X AND column_2 = Y;

      クエリは次のように書き換えられます。

      select * from mv2 where column_2 = Y;

      マテリアライズドビューの定義では、すべての行が column_1 = X と一致する必要があるため、書き換えられたクエリには式 column_1 = X を含める必要さえありません。

    • 次の例は、集計包摂を示しています。

      マテリアライズドビューは以下で定義されています。

      create materialized view mv4 as
    select column_1, column_2, sum(column_3) from table1 group by column_1, column_2;

      次のクエリは、上記で定義されたマテリアライズドビューを使用できます。

      select column_1, sum(column_3) from table1 group by column_1;

      クエリは次のように書き換えられます。

      select column_1, sum(column_3) from mv4 group by column_1;

      書き換えられたクエリは、column_2による追加のグループ化を活用しませんが、その追加のグループ化によってブロックされることもありません。

  • CREATE MATERIALIZED VIEW ステートメントは、完了までにかなりの時間を要する場合があります。

    マテリアライズドビューが最初に作成されると、Snowflakeは CTAS （CREATE TABLE ... AS ....）と同等の操作を実行します。

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

注釈

これらは現在の制限です。それらのいくつかは、将来のバージョンで削除または変更される可能性があります。

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

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

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

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

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

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

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

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

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

    • ウィンドウ関数。

    • HAVING 句。

    • ORDER BY 句。

    • LIMIT 句。

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

    • GROUP BY GROUPING SETS

    • GROUP BY ROLLUP

    • GROUP BY CUBE

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

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

    注釈

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

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

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

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

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

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

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

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

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

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

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

      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);

      式「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);

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

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

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

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

    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;

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

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

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

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

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

SELECT * FROM mv1;

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

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

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

  • マテリアライズドビューのメンテナンスはバックグラウンドプロセスによって実行され、ユーザーがタイミングを予測することはできません。メンテナンスが遅れると、ビューが最新の場合よりもクエリの実行が遅くなる可能性があります。ただし、結果は常に正しいものになります。マテリアライズドビューの一部のマイクロパーティションが古い場合、Snowflakeはそれらのパーティションをスキップし、ベーステーブルのデータを検索します。

  • マテリアライズドビューが最後に更新された時間を確認するには、コマンド SHOW MATERIALIZED VIEWS の出力の REFRESHED_ON 列と BEHIND_BY 列を確認します。

  • ビューのメンテナンスを中断する場合は、メンテナンスを再開するまでビューをクエリしないでください。

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

  • 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 リソースモニターの操作 によってモニターされません。

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

Snowflakeでは、ベーステーブルへの変更は、そのテーブルに基づいてマテリアライズドビューに自動的に伝播されません。

  • ベーステーブルに列が追加された場合、それらの新しい列はマテリアライズドビューに自動的に反映されません。これは、マテリアライズドビューが SELECT * （例： CREATE MATERIALIZED VIEW AS SELECT * FROM table2 ... ）で定義されていた場合でも同様です。マテリアライズドビューの列は、マテリアライズドビューが定義されたときに定義されます。マテリアライズドビューがクエリされるたびに SELECT * は動的に解釈されません。混乱を避けるために、Snowflakeは、マテリアライズドビューの定義で SELECT * を使用しないことをお勧めします。

  • 既存の列が変更または削除されるようにベーステーブルが変更された場合、そのベーステーブルのすべてのマテリアライズドビューが中断されます。マテリアライズドビューは使用または維持できません。（これは、変更または削除された列がマテリアライズドビューの一部ではない場合でも当てはまります。）そのマテリアライズドビューは RESUME できません。再度使用する場合は、再作成する必要があります。ドロップして新しいマテリアライズドビューを作成し、 GRANT および REVOKE コマンドを実行してマテリアライズドビューの権限を再作成できますが、マテリアライズドビューを再作成する最も効率的な方法は通常、 CREATE OR REPLACE MATERIALIZED VIEW <ビュー名> ... COPY GRANTS ... 実行してマテリアライズドビューを単一のコマンドに置き換えることです。

  • ALTER TABLE ... ADD <列> は、そのベーステーブルで作成されたマテリアライズドビューを中断しません。

  • ベーステーブルがドロップされると、マテリアライズドビューは中断されます（ただし、自動的にはドロップされません）。ほとんどの場合で、マテリアライズドビューをドロップする必要があります。何らかの理由でベーステーブルを再作成し、以前と同じ定義でマテリアライズドビューを再作成する場合は、最初にベーステーブルを再作成し、次に CREATE OR REPLACE MATERIALIZED VIEW <ビュー名> ... COPY GRANTS ... を使用してビューを置き換えます。

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

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

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

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

マテリアライズドビューのメンテナンスコスト

マテリアライズドビューは、ストレージリソースとコンピューティングリソースの両方のコストに影響します。

  • ストレージ: 各マテリアライズドビューにはクエリ結果が保存され、アカウントの月間ストレージ使用量が増加します。

  • コンピューティングリソース：マテリアライズドビューが古くなるのを防ぐために、Snowflakeはマテリアライズドビューの自動バックグラウンドメンテナンスを実行します。ベーステーブルが変更されると、テーブルで定義されているすべてのマテリアライズドビューは、Snowflakeが提供する計算リソースを使用するバックグラウンドサービスによって更新されます。

    これらの更新はかなりのリソースを消費する可能性があり、その結果、クレジットの使用状況が増加します。ただし、Snowflakeは、実際に使用されたリソースに対してのみアカウントに請求することにより、効率的なクレジット使用状況を保証します。請求は1秒単位で計算されます。

コストの見積もりと管理

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

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

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

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

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

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

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

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

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

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

ちなみに

マテリアライズドビューを維持するコストが心配な場合、Snowflakeはこの機能をゆっくりと開始し（つまり、選択したテーブルにいくつかのマテリアライズドビューのみを作成すること）長期にわたりコストを監視することをお勧めします。

コストの表示

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

Snowsight

アカウント管理者として、 Admin » Usage をクリックします。

Classic Web Interface

アカウント管理者として、 Account Account tab » Billing & Usage をクリックします。

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

SQL

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

例：

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

注釈

リソースモニター は、仮想ウェアハウスのクレジット使用状況を制御します。ただし、これらを使用して、 Snowflake logo in blue (no text) MATERIALIZED_VIEW_MAINTENANCE ウェアハウスを含む、Snowflake提供のウェアハウスのクレジット使用状況を制御することはできません。

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

マテリアライズドビューでのクラスタリングキーの定義がサポートされており、多くの状況でパフォーマンスを向上させることができます。ただし、コストもかかります。

マテリアライズドビューとマテリアライズドビューが定義されているベーステーブルの両方をクラスター化する場合は、ベーステーブルのクラスター化に使用される列とは異なる列でマテリアライズドビューをクラスター化できます。

ほとんどの場合、テーブル上のマテリアライズドビューのサブセットをクラスタリングする方が、テーブル自体をクラスタリングするよりも費用効果が高い傾向があります。ベーステーブルのデータがマテリアライズドビューを通じてのみ（ほとんど）アクセスされ、（ほとんど）ベーステーブルから直接アクセスされない場合、ベーステーブルをクラスタリングすると、利益を追加せずにコストが追加されます。

ベーステーブルとマテリアライズドビューの両方をクラスタリングすることを検討している場合、Snowflakeは、マテリアライズドビューのみをクラスタリングすることから始め、ベーステーブルにクラスタリングを追加する前後にパフォーマンスとコストを監視することをお勧めします。

テーブルを作成してロードし、テーブルにクラスター化されたマテリアライズドビューを作成する場合、Snowflakeは、マテリアライズドビューを最後に作成することをお勧めします（できるだけ多くのデータをロードした後）。これにより、マテリアライズドビューが初めてロードされるときに、マテリアライズドビューのクラスタリングを維持するための余分な労力が回避されるため、初期データロードの費用を節約できます。

クラスタリングの詳細については、 Snowflakeテーブル構造について および 自動クラスタリング をご参照ください。

マテリアライズドビューのクラスタリングのコストの詳細については、 マテリアライズドビューのメンテナンスコスト と マテリアライズドビューのベストプラクティス をご参照ください。

マテリアライズドビューおよびTime Travel

現在、 Time Travel を使用して、マテリアライズドビューの 履歴データをクエリ することはできません。

ただし、次のことに注意してください：

マテリアライズドビューのベストプラクティス

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

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

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

      • 行をフィルタリングします（例: 非常に最近のデータのみが含まれるようにマテリアライズドビューを定義）。一部のアプリケーションでは、保存に最適なデータは異常なデータです。たとえば、ガスパイプラインの圧力をモニターしてパイプの故障の可能性を推定する場合、ベーステーブルにはすべての圧力データを保存し、マテリアライズドビューには異常に高い圧力測定値のみを保存します。同様に、ネットワークトラフィックをモニターしている場合、ベーステーブルにはすべてのモニター情報が保存される可能性がありますが、マテリアライズドビューには、異常で疑わしい情報（例: 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');

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

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

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

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

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;

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

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

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

次の例は、 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);

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

SELECT * FROM profits ORDER BY product_ID;

出力：

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;

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

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

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

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

これらのステートメントは、パイプラインのセグメントに関する情報を追跡する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')
    ;

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

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;

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

ALTER MATERIALIZED VIEW vulnerable_pipes CLUSTER BY (installation_year);

新しい圧力測定値は頻繁に（おそらく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
       ;

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

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 |
+------------+-------------------+------------------+-----+---------------+-----------------+

これは、腐食する材料でできている 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 を実行してビューを再開することを検討してください。

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

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

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

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

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

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

注釈

マテリアライズドビューが 無効 の場合、Snowflakeは、基になるテーブルからデータを読み取ってマテリアライズドビューを置き換えようとはしません。

これは、マテリアライズドビューが 有効ではあるが最新ではない 場合（例: マテリアライズドビューのバックグラウンド保守プロセスがまだ実行中の場合）の動作とは対照的です。ビューが有効ではあるが最新ではない場合、Snowflakeは マテリアライズドビューの使用 で説明されているようにベーステーブルから読み取ります。

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

考えられる原因

考えられる原因の1つは、ビュー定義の SELECT に失敗したため、更新に失敗したことです。

更新中に SELECT が失敗すると、更新は失敗します。ただし、更新はバックグラウンドで行われるため、更新の試行時にエラーメッセージは表示されません。

マテリアライズドビューのデータの一部またはすべてが古い場合、Snowflakeはベーステーブルから最新のデータを取得します。Snowflakeは、マテリアライズドビューが更新されなかったというエラーメッセージを発行しません。

したがって、リフレッシュも後続のクエリも、ビューの SELECT に失敗したことを必ずしも示しません。更新が失敗しているかどうかを検出するには、コマンド SHOW MATERIALIZED VIEWS を使用して、 refreshed_on という名前の列を探します。データが更新されない場合、 SELECT が失敗している可能性があります。

考えられる解決策

基になるテーブルが存在することを確認してください。ビューが定義されているテーブルをドロップしても、ビューをドロップしない場合、ビューは存在し続けます。

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

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

⇧
最上部に戻る