すべてのプロダクト
Search
ドキュメントセンター

PolarDB:具体化されたビュー

最終更新日:May 31, 2024

PostgreSQLのマテリアライズドビューは、ビューと同様にルールシステムを使用しますが、結果はテーブルのような形式で保持されます。 主な違い:

CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM mytab;

と:

CREATE TABLE mymatview AS SELECT * FROM mytab;

は、マテリアライズドビューを後で直接更新できないこと、およびマテリアライズドビューの作成に使用されるクエリは、ビューのクエリが格納されるのとまったく同じ方法で格納されるため、マテリアライズドビューの新しいデータを次のように生成できます。

新鮮な素材化されたビューmymatview;

PostgreSQLシステムカタログのマテリアライズドビューに関する情報は、テーブルまたはビューの場合とまったく同じです。 したがって、パーサーにとって、マテリアライズドビューは、テーブルやビューのような関係です。 マテリアライズド・ビューがクエリで参照されると、データは、テーブルからのように、マテリアライズド・ビューから直接返されます。ルールは、マテリアライズド・ビューの入力にのみ使用されます。

マテリアライズドビューに格納されたデータへのアクセスは、多くの場合、基になるテーブルに直接またはビューを介してアクセスするよりもはるかに高速ですが、データは常に最新であるとは限りません。 売上を記録するテーブルを考えてみましょう。

CREATE TABLE請求書 (
        invoice_no整数PRIMARY KEY,
        seller_no integer, -- 営業担当者のID
        invoice_date date, -- 販売日
        invoice_amt numeric(13,2) -- 販売額
    );

過去の売上データをすばやくグラフ化したい場合は、要約したいと思うかもしれませんが、現在の日付の不完全なデータを気にしないかもしれません。

MATERIALIZEDビューを作成sales_summary AS
      SELECT
          seller_no、
          invoice_date,
          sum(invoice_amt):: sales_amtとしての数値 (13,2)
        請求書から
        WHERE invoice_date < CURRENT_DATE
        GROUP BY
          seller_no、
          invoice_date
        ORDER BY
          seller_no、
          invoice_date;

    ユニークなインデックスを作成sales_summary_seller
      ON sales_summary (seller_no、invoice_date); 

このマテリアライズドビューは、営業担当者向けに作成されたダッシュボードにグラフを表示するのに役立ちます。 ジョブは、このSQLステートメントを使用して毎晩統計を更新するようにスケジュールできます。

REFRESH MATERIALIZED VIEW sales_summary;

具体化されたビューの別の用途は、外部データラッパーを介してリモートシステムからもたらされるデータへのより高速なアクセスを可能にすることである。 file_fdwを使用した簡単な例をタイミングとともに以下に示しますが、これはローカルシステム上のキャッシュを使用しているため、リモートシステムへのアクセスと比較したパフォーマンスの違いは通常、ここに示すよりも大きくなります。 マテリアライズドビューにインデックスを配置する機能も活用していますが、file_fdwはインデックスをサポートしていません。この利点は、他の種類の外部データアクセスには適用されない場合があります。

セットアップ:

拡張ファイル_fdwを作成します。
    CREATE SERVER local_file FOREIGN DATA WRAPPER file_fdw;
    FOREIGN TABLEワードの作成 (ワードテキストはNULLではありません)
      SERVER local_file
      オプション (ファイル名 '/usr/share/dict/words');
    CREATE MATERIALIZED VIEW wrd AS SELECT * FROM words;
    ユニークなインデックスを作成するwrd_word ON wrd (word);
    拡張の作成pg_trgm;
    CREATE INDEX wrd_trgm ON wrd USING gist (word gist_trgm_ops);
    真空分析wrd; 

それでは、単語をスペルチェックしましょう。 file_fdwを直接使用する:

SELECT count(*) WHERE word = 'caterpiler';

     集計
    -------
         0
    (1行) 

EXPLAIN ANALYZEでは、次のことがわかります。

集計 (コスト=21763.99 .. 21764.00行=1幅=0) (実際の時間=188.180 .. 188.181行=1ループ=1)
       -> 外国語のスキャン (コスト=0.00 .. 21761.41行=1032幅=0) (実際の時間=188.177 .. 188.177行=0ループ=1)
             フィルター :( word = 'caterpiler'::text)
             フィルターによって削除された行: 479829
             外部ファイル: /usr/share/dict/words
             外国のファイルサイズ: 4953699
     計画時間: 0.118 ms
     実行時間: 188.273 ms 

代わりにマテリアライズドビューを使用すると、クエリがはるかに高速になります。

集計 (コスト=4.44 .. 4.45行=1幅=0) (実際の時間=0.042 .. 0.042行=1ループ=1)
       -> インデックスのみwrdでwrd_wordを使用してスキャン (コスト=0.42 .. 4.44行=1幅=0) (実際の時間=0.039 .. 0.039行=0ループ=1)
             Index Cond :( word = 'caterpiler'::text)
             ヒープフェッチ: 0
     計画時間: 0.164 ms
     実行時間: 0.117 ms 

いずれにせよ、言葉のつづりが間違っているので、私たちが望んでいたかもしれないものを探しましょう。 再びfile_fdwpg_trgmを使用します。

単語から単語を選択する <-> 単語で注文する <-> 「キャタピラー」LIMIT 10;

         ワード
    ---------------
     食料品
     キャタピラー
     キャタピラー
     毛虫
     キャタピラーの
     キャタピラー
     仕出し屋
     仕出し屋の
     食料調達
     仕出し料理
    (10行) 
制限 (コスト=11583.61 .. 11583.64行=10幅=32) (実時間=1431.591 .. 1431.594行=10ループ=1)
       -> 並べ替え (コスト=11583.61 .. 11804.76行=88459幅=32) (実際の時間=1431.589 .. 1431.591行=10ループ=1)
             ソートキー :( word <-> 'caterpier'::text)
             ソート方法: top-N heapsortメモリ: 25kB
             -> 外国語のスキャン (コスト=0.00 .. 9672.05行=88459幅=32) (実際の時間=0.057 .. 1286.455行=479829ループ=1)
                   外部ファイル: /usr/share/dict/words
                   外国のファイルサイズ: 4953699
     計画時間: 0.128 ms
     実行時間: 1431.679 ms 

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

制限 (コスト=0.29 .. 1.06行=10幅=10) (実時間=187.222 .. 188.257行=10ループ=1)
       -> wrdでwrd_trgmを使用したインデックススキャン (コスト=0.29 .. 37020.87行=479829幅=10) (実際の時間=187.219 .. 188.252行=10ループ=1)
             注文: (word <-> 'caterpier'::text)
     計画時間: 0.196 ms
     実行時間: 198.640 ms 

ローカルデータベースへのリモートデータの定期的な更新を許容できる場合、パフォーマンス上のメリットは大きくなります。