リフレッシャブルmaterialized viewはどのような場合に使用すべきですか？
リフレッシャブルmaterialized viewでは、非正規化のようなタスクを実行するバッチ処理を実行できます。リフレッシャブルmaterialized view間には依存関係を作成でき、あるビューが別のビューの結果に依存し、その完了後にのみ実行されるようにできます。これにより、スケジュールされたワークフローや、dbt job のような単純なDAGを置き換えられます。リフレッシャブルmaterialized view間の依存関係の設定方法について詳しくは、CREATE VIEW の Dependencies セクションを参照してください。
リフレッシャブルmaterialized viewをリフレッシュするにはどうすればよいですか？
SYSTEM REFRESH VIEW 句を使用できます。
リフレッシャブルmaterialized view が最後にリフレッシュされたのはいつですか？
system.view_refreshes システムテーブルをクエリします。
リフレッシュ間隔を変更するにはどうすればよいですか？
ALTER TABLE...MODIFY REFRESH構文を使用します。
APPEND を使用して新しい行を追加する
APPEND 機能を使うと、ビュー全体を置き換えるのではなく、テーブルの末尾に新しい行を追加できます。
この機能の用途の 1 つは、ある時点における値のスナップショットを取得することです。たとえば、Kafka、Redpanda、またはその他のストリーミングデータプラットフォームからのメッセージストリームが events テーブルに取り込まれている状況を考えてみましょう。
uuidカラムには、4096個の値があります。合計数が最も多いものを見つけるには、次のクエリを実行できます。
uuid の件数を 10 秒ごとに取得し、events_snapshot という新しいテーブルに保存するとします。events_snapshot のスキーマは次のようになります。
uuid について、events_snapshot をクエリして時間ごとの件数を取得できます。
例
Stack Overflow
votes、users、badges、posts、postlinks。
そのガイドでは、次のクエリを使って postlinks データセットを posts テーブルに非正規化する方法を示しました。
posts_with_links テーブルに一回限りで挿入する方法を示しましたが、本番環境ではこの処理を定期的に実行したいところです。
posts テーブルと postlinks テーブルは、どちらも更新される可能性があります。そのため、インクリメンタルmaterialized view を使ってこの join を実装しようとするより、このクエリを一定間隔、たとえば1時間ごとに実行するようスケジュールし、その結果を post_with_links テーブルに保存するだけで十分な場合があります。
ここで役立つのがリフレッシャブルmaterialized view で、次のクエリで作成できます。
ここでの構文はインクリメンタルmaterialized viewと同一ですが、
REFRESH句を含める点が異なります。IMDb
actors、directors、genres、movie_directors、movies、roles の各テーブルを取り込みました。
次に、以下のクエリを使用して、各俳優の概要を映画出演数の多い順に集計できます。