第4章 パフォーマンス最適化・クエリ・変換(Performance & Transformation, 21%)
🎯 この節の学習目標
Snowflake には、ウェアハウスのサイズ調整(4-3)とは別に、ストレージ側・メタデータ側でクエリを速くする3つの機能があります。どれも「テーブルに仕掛けを追加してスキャンや計算を減らす」点は同じですが、効くクエリパターンがまったく違うため、症状に合わない機能を選ぶとコストだけが発生します。本節はこの3つの使い分けを軸に学びます。
検索最適化サービスは、Enterprise エディション以上で利用できる機能で、テーブルの背後に検索アクセスパスと呼ばれる補助構造を作り、ポイントルックアップ(選択行数がごく少ない検索)を高速化します。通常のプルーニングでは絞り込めない「値がどのマイクロパーティションにあるか」を直接特定できるようになるイメージです。
高速化される代表的なクエリパターンは次のとおりです。
💡 具体例:テーブル/列単位での有効化
-- テーブル全体の等価検索を最適化する
ALTER TABLE support_logs ADD SEARCH OPTIMIZATION;
-- 特定の列・検索方法に絞って有効化することもできる
ALTER TABLE support_logs ADD SEARCH OPTIMIZATION
ON EQUALITY(user_id), SUBSTRING(message);
問い合わせログの中から特定ユーザーの行だけを探す、といった「巨大テーブルからの数行の取り出し」が典型的な適用場面です。検索アクセスパスの構築・維持はサーバーレスで行われ、その分のサーバーレス課金(コンピュート)と追加ストレージ課金が発生します。
マテリアライズドビュー(materialized view)は、クエリ結果を事前計算して物理的に保存しておくビューです。こちらも Enterprise エディション以上の機能です。通常のビュー(クエリのたびに定義を実行する「保存されたSQL」)と違い、結果が実体化されているため参照が高速です。
| 特徴 | 内容 |
|---|---|
| 対象は単一テーブル | 定義クエリは1つのテーブルに対するもので、結合(JOIN)は不可。集計(GROUP BY)や一部の集計関数は使えるが、制約がある |
| 自動メンテナンス | 元テーブルが変更されると、Snowflakeがバックグラウンド(サーバーレス)で自動更新する。ユーザーによるリフレッシュ操作は不要 |
| 自動書き換え(自動利用) | ユーザーが元テーブルを参照するクエリを書いても、クエリオプティマイザが「マテリアライズドビューを使ったほうが速い」と判断すれば自動的に書き換えて利用する |
| 課金 | 自動メンテナンスのサーバーレスコンピュート課金+実体データのストレージ課金 |
-- 日次集計を事前計算しておく
CREATE MATERIALIZED VIEW daily_sales_mv AS
SELECT order_date, SUM(amount) AS total_amount, COUNT(*) AS cnt
FROM sales
GROUP BY order_date;
📝 試験のポイント
マテリアライズドビューの3点セット——①単一テーブルのみ(結合不可)、②メンテナンスはSnowflakeが自動(サーバーレス課金)、③オプティマイザが自動で利用(クエリの書き換え不要)——はそのまま出題ポイントです。更新が非常に多いテーブルではメンテナンスコストが利益を上回る、という判断軸もあわせて覚えておきましょう。
1-6 で学んだとおり、クラスタリングキーは「指定した列の値が近い行どうしが同じマイクロパーティションに集まる」ようにデータの物理配置を整える仕組みで、指定後は Automatic Clustering(サーバーレス)が並び替えを維持します。非常に大きなテーブルに対する範囲フィルタ・等価フィルタのプルーニング効率を改善します。
-- 日付列でのフィルタが多い大テーブルにクラスタリングキーを設定
ALTER TABLE sales CLUSTER BY (order_date);
ポイントルックアップの検索最適化サービスとは対照的に、クラスタリングは「ある程度の範囲を読むが、その範囲が全体のごく一部」というクエリ(例:1年分のデータから特定の1週間を抽出)に向きます。並び替えの維持にはサーバーレス課金が発生するため、更新の激しいテーブルではコストに注意が必要です。
4つの手段(3機能+ウェアハウスサイズ調整)を並べて比較します。この表が本節の核心です。
| 検索最適化サービス | マテリアライズドビュー | クラスタリングキー | WHサイズ調整 | |
|---|---|---|---|---|
| 対象クエリパターン | 等価・IN・部分文字列などのポイントルックアップ(返る行がごく少ない) | 繰り返し実行される集計・変換(単一テーブル) | 大テーブルの範囲フィルタ(日付範囲など) | あらゆる重いクエリ全般(スピル解消など) |
| エディション | Enterprise 以上 | Enterprise 以上 | 全エディション | 全エディション |
| 課金形態 | サーバーレス(構築・維持)+ストレージ | サーバーレス(自動更新)+ストレージ | サーバーレス(Automatic Clustering) | ウェアハウスのクレジット消費率が増加 |
| 設定単位 | テーブル/列・検索方法単位 | ビューとして定義 | テーブル単位(列・式を指定) | ウェアハウス単位 |
図:クエリパターン → 適する高速化機能の選択分岐
✅ この節のまとめ
問1. 数十億行のログテーブルに対して「WHERE session_id = '...'」のように特定IDの数行だけを取り出すクエリが多数実行されており、毎回テーブルの大部分がスキャンされて遅い。最も適切な機能はどれか。
正解:B
「巨大テーブルから等価条件でごく少数の行を探す」はポイントルックアップの典型で、検索最適化サービスの主対象です。Aのマテリアライズドビューは繰り返しの集計向けで、任意のIDによる検索には対応できません。Cの結果キャッシュは同一クエリの再実行にしか効かず、IDが毎回異なる検索には効きません。Dは同時実行の問題(キュー待ち)への対策で、スキャン量は減りません。
問2. マテリアライズドビューの説明として誤っているものはどれか。
正解:C
Snowflakeのマテリアライズドビューは単一テーブルに対する定義のみ可能で、結合(JOIN)は使えません。集計は可能ですが制約があります。A・B・Dはいずれも正しい説明で、特にBの「オプティマイザによる自動書き換え」は、既存クエリを修正しなくても恩恵を受けられるという重要な特徴です。
問3. 5年分・数TBの売上テーブルに対し、「直近1か月」「特定の四半期」など日付範囲で絞り込む分析クエリが中心だが、Query Profile ではほぼ全パーティションがスキャンされている。最も適切な対策はどれか。
正解:A
大テーブル+範囲フィルタ+プルーニング不良、という組み合わせはクラスタリングキーの典型的な適用場面です。日付列でクラスタリングすれば、範囲条件に合致しないマイクロパーティションが効率よく除外されます。Bの部分文字列検索の最適化は文字列のポイントルックアップ向けで、日付範囲には不適切です。Cはウェアハウス稼働中しか効かず、根本対策になりません。Dの通常のビューは定義を保存するだけで、性能は変わりません。
問4. 検索最適化サービス・マテリアライズドビュー・クラスタリングキーに共通する特徴として正しいものを2つ選べ。
正解:A、C
3機能とも維持管理はSnowflakeがサーバーレスで行い、使った分の課金が発生します。また、それぞれ効くクエリパターン(ポイントルックアップ/繰り返し集計/範囲フィルタ)が異なるため、症状の見極めが導入判断の前提です。Bは誤りで、検索最適化サービスとマテリアライズドビューは Enterprise 以上が必要です(クラスタリングキーは全エディション)。Dは誤りで、3機能ともクエリの書き換えは不要です(マテリアライズドビューもオプティマイザが自動利用します)。