BigQuery Materialized View

気になり

2021/11/10 まだ CREATE OR REPLACE 使えない

実体化されたビューはテーブルごとに最大 20 個

アイコン

https://gyazo.com/edfbd4304fb254f0a433dcf3f8894b0c

作成クエリパーツ

code:create

CREATE MATERIALIZED VIEW t

PARTITION BY c

AS SELECT q

code:freq_cap

CREATE MATERIALIZED VIEW t

OPTIONS (enable_refresh = true, refresh_interval_minutes = 60)

手動更新の実行

CALL BQ.REFRESH_MATERIALIZED_VIEW('project-id.my_dataset.my_mv_table')

パーティショニング

ベーステーブルのパーティショニングカラムを加工した値でパーティショニングできる

ベーステーブルは日別パーティションを使用して transaction_time という名前の TIMESTAMP 列でパーティション分割されています。マテリアライズド ビューでは transaction_hour という名前の列を定義し、TIMESTAMP_TRUNC 関数を使用して値を最も近い時間に切り捨てます。マテリアライズド ビューは transaction_hour でグループ化およびパーティション分割されます。

Dataform との相性悪い

Materialized View が参照する元テーブルが削除(再作成)されたら更新に失敗する

MERGE でやっていくしかない?

あるいは冪等でないのでそもそも載せない / CREATE IF NOT EXISTS にする(これも微妙だが...)

ID でユニークにするやつマテビューにする?

通常フルスキャンが必要ならフルスキャンぶんのコストが掛かりそうなイメージだが...

ベーステーブルが変更されると、各マテリアライズド ビューは自動更新（再計算）されますが、システム定義の間隔（現在は 30 分）より短い頻度になることはありません

とはいえ streaming しているテーブルで30分おきにフルスキャンかかったらまあまあ金かかる

Materialized views do not support analytic functions or WITH OFFSET

はい...

このへんも JOIN する前に考えておく

同じデータセットという制約なくなった?

前はベーステーブルと同じデータセットである必要があった気がするが...

クエリの自動書き換え（またはスマートな調整）では、同じデータセットのマテリアライズド ビューのみが考慮されます。

2021/11/10 別データセットに作れた

マテリアライズド ビューを持つベーステーブルにクエリを実行すると、マテリアライズド ビューに格納されたキャッシュ結果を使用するように、クエリ オプティマイザーによって自動的にクエリが書き換えられる場合があります。この書き換え処理は、ベーステーブルとマテリアライズド ビューが同じデータセットにある場合にのみ実行できます。クエリプランには、マテリアライズド ビューを使用するようにクエリが書き換えられたことが示されます。 クエリの書き換えに複数のマテリアライズド ビューを使用できる場合、スキャンする行の推定数が最も少ないマテリアライズド ビューが使用されます。

同じデータセットにあるとこの機能が使われる

クエリの書き換えを無効にするには、ベーステーブルに対するクエリに "WHERE RAND()<1" フィルタを追加します。RAND() は非決定論的関数であるため、クエリは書き換えられません。RAND()<1 は常に true と評価されるため、クエリ結果には影響しません。