Snowflake

Snowflake Search Optimization Service (SOS) 完全ガイド: Clustering Keysとの使い分け

2026-03-26
更新: 2026-03-27
NicheeLab編集部
目次
  1. SOSの仕組み
  2. SOSの有効化SQL
  3. 対応クエリパターン
  4. Clustering Keysとの使い分け
  5. コスト監視
  6. 設計パターン
  7. 試験で問われるポイント
  8. 問題で確認
  9. よくある質問

Search Optimization Service(SOS)は、Snowflakeの大規模テーブルに対するポイントルックアップクエリを 劇的に高速化するサーバーレス機能です。 内部的にSearch Access Pathと呼ばれる補助データ構造を構築し、 パーティションプルーニングだけでは到達できない精度でスキャン対象を絞り込みます。Enterprise Edition以上で利用可能です。

SOSの仕組み

通常のクエリ実行ではSnowflakeはマイクロパーティションのメタデータ(列の最小値・最大値)を参照してプルーニングを行います。SOSはこれに加えて、列の値とマイクロパーティションの対応関係を記録したSearch Access Pathを構築します。WHERE句で特定の値を検索すると、SOSのアクセスパスから該当するマイクロパーティションのみがピンポイントで特定され、スキャン量が数桁のオーダーで削減されます。

SOSの有効化SQL

テーブル全体に適用する場合と、特定の列・メソッドに限定する場合でSQL構文が異なります。

-- テーブル全体にSOSを有効化
ALTER TABLE analytics.customers
  ADD SEARCH OPTIMIZATION;

-- 特定の列に対してメソッドを指定して有効化
ALTER TABLE analytics.customers
  ADD SEARCH OPTIMIZATION ON
    EQUALITY(customer_id),
    EQUALITY(email),
    SUBSTRING(customer_name),
    EQUALITY(metadata:plan_type);

-- 特定の列のSOSを無効化
ALTER TABLE analytics.customers
  DROP SEARCH OPTIMIZATION ON
    SUBSTRING(customer_name);

-- テーブル全体のSOSを無効化
ALTER TABLE analytics.customers
  DROP SEARCH OPTIMIZATION;

-- SOSの状態確認
DESCRIBE SEARCH OPTIMIZATION ON analytics.customers;

対応クエリパターン

SOSが高速化できるクエリパターンは限定的です。以下の表は試験で問われるポイントでもあるため、正確に把握してください。

クエリパターン対応メソッドSQLの例備考
等値検索(=)EQUALITYWHERE id = 12345主キー検索に最適
IN句EQUALITYWHERE status IN ('A','B')複数値ルックアップ
部分文字列検索SUBSTRINGWHERE name LIKE '%tanaka%'前方一致も含む
VARIANT / OBJECTパス検索EQUALITYWHERE data:key = 'val'半構造化データ対応
GEOGRAPHY / GEOMETRY関数GEOST_DISTANCE(geo, ...) < 1000地理空間検索
範囲検索(BETWEEN / >=)-WHERE date BETWEEN '...' AND '...'SOSの対象外(Clustering Keysが有効)

Clustering Keysとの使い分け

SOSとClustering Keysは競合する機能ではなく、相互補完の関係にあります。

比較項目Search Optimization ServiceClustering Keys
最適なクエリ等値/IN/部分文字列/VARIANT検索範囲フィルタ(BETWEEN/>=/<=)
内部構造Search Access Path(補助インデックス的構造)マイクロパーティションの物理的ソート
メンテナンスServerless Credit(自動)Automatic Clustering(Serverless Credit)
Edition要件Enterprise以上Enterprise以上
列の指定ON句で列+メソッドを個別指定可CLUSTER BY句で最大4列程度
併用併用可能。日付列をClustering Key、ID列にSOSが典型パターン

コスト監視

SOSのメンテナンスコストはDMLの頻度に比例します。高頻度INSERTのテーブルではコストが増大するため、定期的にモニタリングが必要です。

-- SOSのメンテナンスコスト履歴を確認
SELECT *
FROM TABLE(INFORMATION_SCHEMA.SEARCH_OPTIMIZATION_HISTORY(
  DATE_RANGE_START => DATEADD('DAY', -14, CURRENT_TIMESTAMP()),
  DATE_RANGE_END => CURRENT_TIMESTAMP()
));

-- ACCOUNT_USAGEからテーブル別コスト集計
SELECT
  TABLE_NAME,
  SUM(CREDITS_USED) AS total_credits,
  COUNT(*) AS maintenance_runs
FROM SNOWFLAKE.ACCOUNT_USAGE.SEARCH_OPTIMIZATION_HISTORY
WHERE START_TIME >= DATEADD('DAY', -30, CURRENT_TIMESTAMP())
GROUP BY TABLE_NAME
ORDER BY total_credits DESC;

設計パターン

実務でSOSを導入する際の典型的な設計パターンを示します。

  • ユーザー検索テーブル: customer_idにEQUALITY、customer_nameにSUBSTRINGを設定。 日付列にはClustering Keysを設定して範囲検索を最適化
  • イベントログテーブル: event_typeにEQUALITY、jsonペイロードの特定パスにEQUALITYを設定。 event_timestampはClustering Keyで物理ソート
  • 位置情報テーブル: GEOGRAPHY型のlocation列にGEOを設定し、ST_DISTANCE/ST_WITHINの高速化

試験で問われるポイント

  • SOSが高速化するのは等値/IN/部分文字列/VARIANT/GEO検索であり、範囲検索は対象外
  • Enterprise Edition以上が必要(Standard Editionでは利用不可)
  • Clustering Keysとの併用が可能で、異なるクエリパターンをカバーする相互補完関係
  • ON句で列とメソッドを個別に指定でき、不要な列への適用は避けるべき
  • メンテナンスコストはServerless Creditとして課金され、DML頻度に比例する

問題で確認

SnowPro

問題 1

数十億行のトランザクションテーブルに対して、transaction_id(UUID)で頻繁に等値検索を行う必要があります。パフォーマンスを最適化するための最も適切なアプローチはどれですか?

  1. transaction_idをClustering Keyに設定して物理ソートを最適化する
  2. ALTER TABLE ADD SEARCH OPTIMIZATION ON EQUALITY(transaction_id) でSOSを有効化する
  3. transaction_idにユニーク制約を追加して検索を高速化する
  4. ウェアハウスのサイズを4XLARGEに変更してスキャン速度を向上させる

正解: B

UUIDのようなカーディナリティが極端に高い列でのポイントルックアップにはSOSが最適です。Clustering Keysはカーディナリティが高すぎる列では効果が薄く、メンテナンスコストに見合いません。ユニーク制約は検索高速化の機能ではなく、ウェアハウスサイズの拡大はフルスキャン量自体を減らせません。

よくある質問

Search Optimization ServiceとClustering Keysはどう使い分けますか?

Clustering Keysはデータの物理配置を制御してパーティションプルーニングを改善する機能で、範囲フィルタ(BETWEEN / >= / <=)や等値フィルタに有効です。一方SOSは、等値検索(= / IN)、部分文字列検索(LIKE '%keyword%')、VARIANT内のパス検索、GEOGRAPHY/GEOMETRY関数に特化した補助的なアクセス構造を構築します。両者は併用可能であり、Clustering Keysでカバーしきれない検索パターンにSOSを追加するのが基本設計です。

SOSを有効にするとストレージコストは増えますか?

はい。SOSは内部的に検索アクセスパス(Search Access Path)というデータ構造を構築するため、追加のストレージコストが発生します。またDMLが実行されるたびにアクセスパスのメンテナンスが必要で、これはServerless Creditとして課金されます。SEARCH_OPTIMIZATION_HISTORYテーブル関数でメンテナンスコストの推移を確認できます。

SOSは特定の列だけに適用できますか?

はい。ALTER TABLE ADD SEARCH OPTIMIZATION ON句で対象の列とメソッド(EQUALITY / SUBSTRING / GEO)を個別に指定できます。テーブル全体に適用する場合はON句を省略しますが、不要な列にまで適用するとメンテナンスコストが増大するため、実際にクエリで使用する列のみを指定するのが推奨です。

クラウドの基礎から読む

資格の話をしない、クラウドそのものの入門 8 章があります。登録なしで全部読めます。

第 0 部・無料

クラウド自体がはじめての方へ

サーバー・ネットワーク・データベースの前提知識なしで読める 8 章。登録不要・無料。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Snowflake

Snowflake資格一覧|全11試験(SnowPro)の難易度・費用

Snowflake認定資格(SnowPro)全11試験の一覧・難易度・費用・出題範囲を徹底解説。SnowparkとDat...

Snowflake

Snowflake試験の難易度ランキング|全11資格を徹底比較

Snowflake(SnowPro)認定全11試験の難易度をランキング形式で比較。学習時間・合格に必要なスキルから分析。...

Snowflake

Snowflake資格の勉強方法|効率的な学習ルートと合格のコツ

Snowflake認定資格(SnowPro)に最短で合格するための勉強方法。公式リソース・学習スケジュールを徹底ガイド。...

Snowflake

SnowPro Core試験完全解説|出題範囲・問題例・合格戦略

SnowPro Core Certification(COF-C03)を徹底解説。出題範囲・100問の試験形式・合格ライ...

Snowflake

SnowPro Platform Associate(SOL-C01)完全解説|現在は予約不可・試験内容と次の受験先

SnowPro Associate: Platform(SOL-C01)は2026年10月時点でSnowflakeの公式...

Snowflakeの記事一覧 (102件)
© 2026 NicheeLab All rights reserved.