を触り始めた人が最初に戸惑うのは、既存の の常識がいくつも通用しない点だと思います。索引を作らない、テーブル領域を設計しない、なのに費用は使った時間で決まる。
これらはすべて、保管と計算を切り離したという一点から派生しています。初回はそこを押さえます。ここが腑に落ちると、以降の話が全部つながります。
製品の宣伝はしません。できること・できないこと・向かない用途を並べます。仕様は変わりうるので、判断の枠組みを中心に書き、具体的な数値は公式資料の確認を前提とします。
1. 分離とは何か
従来型のデータベースでは、データを保管しているマシンが計算も行います。両者が同じ場所にあるため、片方だけを増やすことができません。分析処理を増やしたければ、データごと大きなマシンに移すことになります。
Snowflake は、データをクラウドストレージに置き、計算は独立した が行います。両者は必要なときだけ結びつきます。ここから、いくつもの帰結が生まれます。
| 分離の帰結 | 何ができるようになったか |
|---|---|
| 計算だけを増減できる | 重い処理のときだけ大きくし、終われば戻す |
| 計算を用途別に分けられる | 分析とバッチが互いに干渉しない |
| 止めれば課金が止まる | 使わない時間の費用がゼロになる |
| 同じデータを複数から見られる | 複製せずに、別々の計算資源から参照できる |
| 保管を安価に持てる | 計算しない古いデータを持ち続けやすい |
2行目が実務では特に効きます。従来型では、重いバッチが走ると分析画面も遅くなりました。いわゆる相互干渉です（データ基盤トラブル事件簿 EP.01 に事例があります）。分離されていれば、用途ごとに計算資源を分けるだけで解決します。
2. 課金が特殊に見える理由
費用は大きく分けて保管と計算です。このうち計算が という単位で計られ、仮想ウェアハウス が動いている時間とサイズで決まります。
ここで重要なのは、クエリの重さではなく、起動している時間で課金されるという点です。軽いクエリを1本流すだけでも、ウェアハウスが起動していればその時間ぶんがかかります。逆に、止まっていれば何本クエリを書いても費用は発生しません。
従来の感覚では、重い処理を軽くすれば費用が下がります。しかしここでは、起動している時間が費用を決めます。1時間に1本しか流していないのに1時間ずっと起動していたら、その1時間ぶんかかります。止め方の設計のほうが効きます（EP.4 で扱います）。
この構造から、同じ処理量でも運用次第で費用が大きく変わることになります。連載でコストの話が繰り返し出てくるのは、性能と費用が同じ変数（起動時間）に紐づいているためです。
3. 索引がない代わりに何があるか
Snowflake には、利用者が作る索引がありません。代わりに機能するのが です。データは自動的に区画へ分割され、各区画に含まれる値の範囲が記録されています。
検索条件と突き合わせて、該当しない区画をまるごと読み飛ばす。これが です。索引を辿るのではなく、読まなくてよい塊を除外するという発想です。
-- 実行後、クエリ履歴で「読んだ区画数 / 全区画数」を確認するSELECT query_id, partitions_scanned, partitions_total, ROUND(100.0 * partitions_scanned / NULLIF(partitions_total, 0), 1) AS 読んだ割合, bytes_scanned, total_elapsed_time / 1000 AS 秒FROM snowflake.account_usage.query_historyWHERE start_time >= DATEADD(hour, -1, CURRENT_TIMESTAMP()) AND partitions_total > 0ORDER BY 読んだ割合 DESC, bytes_scanned DESCLIMIT 20;読んだ割合が 100% に近いのに、返る行が少ないなら、読み飛ばしが効いていません。これは EP.3 で扱う典型的な調査の入口になります。列に関数を適用している、条件が並び順と噛み合っていない、といった原因が見つかります。
並び順を意図的に保ちたい場合に使うのが ですが、維持のための処理が継続的に発生します。効果と費用の釣り合いを見る必要があり、EP.5 で改めて扱います。
4. 列で持つということ
もう一つの前提が です。データを行ではなく列ごとにまとめて保管しています。集計で使う列だけを読めばよいので、分析用途では圧倒的に有利です。
| 処理 | 向き | 理由 |
|---|---|---|
| 数百万行の集計（数列のみ） | 非常に向く | 必要な列だけ読める |
| 条件に合う少数行の全項目取得 | 普通 | 全列を集める必要がある |
| 1行の更新を高頻度で行う | 向かない | 列ごとに散っているため効率が悪い |
| 1件ずつの参照を大量に行う | 向かない | 1件あたりの固定コストが効く |
下2行が重要です。業務システムの裏側として使うものではありません。1件ずつの読み書きが多い用途は、従来型のデータベースの領分です。ここを取り違えると、遅くて高い構成になります。
-- 効く: 3億行あっても、使う2列しか読まないSELECT region, SUM(amount)FROM ordersWHERE order_date >= '2026-01-01'GROUP BY region;
-- 効きにくい: 全列を集める必要があるSELECT * FROM orders WHERE id = 12345;
-- 最も向かない: 1行の更新を高頻度で繰り返すUPDATE orders SET status = 'shipped' WHERE id = 12345;1つ目は、行数がどれだけ増えても使う列の量しか読みません。2つ目は1行しか返しませんが、全列を各所から集める必要があり、行で持つ設計ほど有利ではありません。3つ目のような更新を業務システムの頻度で繰り返す用途は、そもそも設計思想の外にあります。
書き込みが1件ずつ・読み取りも1件ずつなら従来型。まとめて入れて、まとめて集計するなら Snowflake 側。両方が必要なら、業務用のデータベースから定期的に取り込む構成が基本形になります。
5. 何を設計することになるのか
索引もテーブル領域も設計しないなら、何を設計するのか。実際には設計対象が移っただけで、やることは減っていません。
- 1計算資源の分け方 — 誰の処理をどのウェアハウスに載せるか（EP.2）
- 2止め方 — いつ止め、いつ起こすか。費用に直結する（EP.4）
- 3データの並び順 — 読み飛ばしが効く配置か（EP.5）
- 4権限の構造 — 誰が何を見られるか（EP.8）
- 5復旧の備え — どこまで戻せるようにしておくか（EP.6）
1番目と2番目が、従来にはなかった設計項目です。計算資源を自由に分けられるようになった代わりに、分け方を決める仕事が生まれました。ここを決めずに使い始めると、全員が1つのウェアハウスを共有し、干渉と費用の両方で困ることになります。
6. この連載で扱うこと
以降は、ウェアハウスのサイズ設計（EP.2）、費用の可視化（EP.3）、止め方（EP.4）、並び順（EP.5）、復旧（EP.6）、検証環境（EP.7）、権限（EP.8）、データ共有（EP.9）、 の使いどころ（EP.10）、 との組み合わせ（EP.11）と進み、コスト最適化のまとめ（EP.12）で締めます。
DWH の選定そのものについては 壊れないデータ基盤の作り方 EP.02 を参照してください。この連載は選んだあとの話に集中します。
すべては保管と計算の分離から派生する。費用はクエリの重さではなく起動時間で決まる。索引の代わりに区画の読み飛ばしが効き、設計対象は並び順に移った。列で持つため、1件ずつの読み書きには向かない。新しく生まれた設計項目は計算資源の分け方と止め方です。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。