はじめに

こんにちは！DJ.mashiです。今回はBigQueryのMaterialized View(以後、マテビュー)を利用する機会がありました。RDB(PostgreSQL)とは異なる部分も多く自分なりに情報の整理と検証を実施しました。その内容を備忘のため記載します。

RDB(PostgreSQL)のマテビューについて

クエリの結果をキャッシュします。ある時点のSELECT文のスナップショットのようなイメージです。
Viewと比較して考えます。Viewは、SELECTで参照するテーブルへ更新があれば、以後そのViewへのSELECT結果も更新影響を受けます(注1)。
しかし、マテビューではある時点のSELECT文の結果がキャッシュされますので参照するテーブル更新の影響を受けません。代わりに、マテビューの内容を更新するrefleshが存在し、refleshを実行することでキャッシュの内容が再取得される仕組みが多いです。
また、DB次第ですが、例えばPostgreSQLではマテビューに対し索引を付与できたりします。

注1)同一トランザクションを前提にしています。

BigQueryのマテビューについて

クエリの結果をキャッシュする点は同様です。また、refleshも存在します。

ソース：BQ.REFRESH_MATERIALIZED_VIEW

しかし、ソーステーブルへの更新があった際にもリフレッシュをせずとも最新データをクエリできる仕様なのか、良いように検索してくれそうな記述があります。

マテリアライズド ビューは最新のデータを返します。ベーステーブルに対する変更によってマテリアライズド ビューが無効になる可能性がある場合、データはベーステーブルから直接読み取られます。ベーステーブルを変更してもマテリアライズド ビューが無効にならない場合、残りのデータはマテリアライズド ビューから読み取られ、ベーステーブルからは変更のみが読み取られます。

ソース：マテリアライズド ビューの概要

本当に最新のデータ読み取ってくれるのか？検証します。

上述のマテビューの説明を読み取る限り、最新のデータを読み取ってくれそうです。

説明を読む限りの雰囲気はRDBの「部分インデックス」に近いものがあるのかな？という所感です。但し索引ではないので、データ件数が少なくても動作が期待できるでしょうか？

検証には、下記データを用います。群馬県と神奈川県のデータを利用します。
読み仮名データの促音・拗音を小書きで表記しないもの

検証．最新のデータを読み取れるか

以下の工程で検証しました。

1. ソーステーブルの作成=>群馬県と神奈川県のデータを投入するT_zipcodeの作成
2. マテビューの作成=>神奈川県だけを抽出するMV_zipcode_kanagawaの作成
3. ソーステーブルへ投入=>群馬県のデータをT_zipcodeへ投入
4. T_zipcodeの全件検索=>群馬県のデータのみ表示されることを確認
5. MV_zipcode_kanagawaの全件検索=>何も表示されないことを確認
6. ソーステーブルへ投入=>神奈川県のデータをT_zipcodeへ投入
7. T_zipcodeの全件検索=>群馬県と神奈川県のデータが表示されることを確認
8. MV_zipcode_kanagawaの全件検索=>神奈川県のデータが表示されることを確認

検証結果は上述の通り、最新のデータを読み取れました。

工程で用いたクエリは下記になります。一部マスキング実施しています。

-- 初期化、テーブル構築
DROP TABLE IF EXISTS `djmashi.T_zipcode`;
CREATE OR REPLACE TABLE `djmashi.T_zipcode` (
dtCode INTEGER,
oldZipCode STRING,
ZipCode STRING,
addressKana1 STRING,
addressKana2 STRING,
addressKana3 STRING,
address1 STRING,
address2 STRING,
address3 STRING,
FLG1 STRING,
FLG2 STRING,
FLG3 STRING,
FLG4 STRING,
FLG5 STRING,
FLG6 STRING,
);
-- マテビュー構築
DROP MATERIALIZED VIEW `djmashi.MV_zipcode_Kanagawa` ;
CREATE MATERIALIZED VIEW `djmashi.MV_zipcode_Kanagawa` AS (
SELECT
ZipCode,
addressKana1,
addressKana2,
addressKana3,
address1,
address2,
address3,
FROM
`djmashi.T_zipcode`
WHERE
address1 = '神奈川県'
);
-- 群馬県のデータをソーステーブルである「T_zipcode」へ取り込み
LOAD DATA INTO `djmashi.T_zipcode` (
dtCode INTEGER,
oldZipCode STRING,
ZipCode STRING,
addressKana1 STRING,
addressKana2 STRING,
addressKana3 STRING,
address1 STRING,
address2 STRING,
address3 STRING,
FLG1 STRING,
FLG2 STRING,
FLG3 STRING,
FLG4 STRING,
FLG5 STRING,
FLG6 STRING,
)
FROM FILES (
SKIP_LEADING_ROWS=0,
format = 'CSV',
quote='"',
uris = ['gs://※省略//10gumma/10GUMMA.CSV']
);
-- 群馬県の表示を確認
SELECT * FROM djmashi.T_zipcode;
-- 神奈川県のデータはまだ取り込んでいないため0件
SELECT * FROM djmashi.MV_zipcode_Kanagawa;
-- 神奈川県のデータをソーステーブルである「T_zipcode」へ取り込み
LOAD DATA INTO `djmashi.T_zipcode` (
dtCode INTEGER,
oldZipCode STRING,
ZipCode STRING,
addressKana1 STRING,
addressKana2 STRING,
addressKana3 STRING,
address1 STRING,
address2 STRING,
address3 STRING,
FLG1 STRING,
FLG2 STRING,
FLG3 STRING,
FLG4 STRING,
FLG5 STRING,
FLG6 STRING,
)
FROM FILES (
SKIP_LEADING_ROWS=0,
format = 'CSV',
quote='"',
uris = ['gs://※省略/14KANAGA/14KANAGA.CSV']
);
-- 群馬県と神奈川県の表示を確認
SELECT * FROM djmashi.T_zipcode;
-- 神奈川県の表示を確認
SELECT * FROM djmashi.MV_zipcode_Kanagawa;</pre>

上記クエリの実行結果はBigQueryのコンソール上で下記でした。

少し、マテビューの読み込みに要する処理されたバイト数が大きい気がします。

実はこれにはマテビューの仕様が関わっておりマニュアルに下記記載があります。

自動更新はベスト エフォート ベースで行われます。BigQuery では、ベーステーブルの変更後 5 分以内に更新の開始が試行されます（前回の更新が 30 分以上前に行われた場合）。しかし、更新がその時点で開始されることや、いつ更新が完了するかが保証されるわけではありません。

注: マテリアライズド ビューのクエリはベーステーブルの最新の状態を反映しますが、ビューが最近更新されていない場合は、クエリのコストやレイテンシが予想より大きくなる可能性があります。

マテリアライズド ビューを管理する

以上の記載がありました。そのため、恐らくマテビューにはまだ最新のキャッシュがあるわけではなくソーステーブルを参照したのかもしれません。

まとめとその他調べた事柄

• BigQueryのマテビューは自動で更新される
• BigQueryのマテビューが更新される前はソーステーブルを参照することもある。その際はコストやレイテンシが大きくなることもある。
• （デフォルトでは）上記の挙動のためRDBのようなイメージでソーステーブルの最新データにアクセスする必要がない場合は一工夫が必要
• BigQueryのマテビューも、Refleshコマンドや自動更新オフなどの設定も利用することができる

次回は、BigQueryでRDBのようなマテビューとして利用する方法を整理したいと思います。