Cloud Spannerの集計処理：分散データベースの「物理」を理解した者だけが辿り着く最適解
Cloud Spannerを単なる「SQLが動く分散DB」だと思っているなら、今すぐその認識を改めた方がいい。
Spannerは、世界中に散らばるノード群が協調して動く巨大な分散システムだ。RDBMSの感覚で安易に `GROUP BY` を発行すれば、ネットワークの遅延とCPUの飽和があなたを待っている。
今日は、Spannerにおける集計処理の「裏側」と、シニアエンジニアとして設計レビューの場で必ず指摘する「避けるべき罠」について話そう。
—
1. 集計処理の「分散」という現実
Spannerにおいて、データは Split（スプリット） という単位で物理的に分割され、ノード間で再配置される。
`SELECT count(), sum(amount) FROM Orders GROUP BY user_id`
このクエリを投げた時、何が起きているか想像できるか？
Spannerのクエリエンジンは、各Splitでローカル集計（Partial Aggregate）を行い、その結果を「コーディネーターノード」に集約して最終的な計算を行う。
この「分散→集約」のステップが、データ量が増えた瞬間にボトルネックになる。特に、キーの偏り（ホットスポット）がある場合、特定のノードに処理が集中し、システム全体が悲鳴を上げる。
—
2. 実務で直面する「やってはいけない」アンチパターン
罠①：非効率なグループ化による中間結果の肥大化
`GROUP BY` に指定するカラムにカーディナリティ（値の多様性）が高いものを選ぶと、コーディネーターノードがメモリ不足に陥る。
— 危険：タイムスタンプ単位など、カーディナリティが高すぎるカラムでのGROUP BY
SELECT timestamp_trunc(created_at, MILLISECOND), count()
FROM Transactions
GROUP BY 1;
対策： 集計粒度を適切に設計せよ。バッチ処理で済むなら、集計専用のテーブルを別途作成し、段階的に集計（Aggregation Pipeline）を行うのがSpannerの正攻法だ。
罠②：ストリーム集計の過信
Spannerは強力だが、リアルタイム性が求められるダッシュボードで、数千万行のテーブルを毎回フルスキャンして集計するのはコストの無駄だ。
設計指針： 「読み取り時集計」か「書き込み時集計」かを見極めろ。
高頻度で更新されるデータなら、インクリメンタルな集計テーブルを保持するカウンター設計を検討すべきだ。
—
3. パフォーマンスを最大化する「実践テクニック」
① クエリプランを確認せよ
`EXPLAIN ANALYZE` を使え。これは義務だ。
`Distributed Union` がどこで発生し、どの程度の行数が各ノードから転送されているかを確認しろ。もし `Distributed Union` が頻発しているなら、テーブルのインターリーブ（Interleave）設計を見直す必要がある。
② 集計時のインデックス活用
Spannerのインデックスは、それ自体が独立したテーブルだ。集計対象のカラムをインデックスに含める（`STORING` 句を使う）ことで、メインテーブルへのアクセスを回避し、メモリ消費を劇的に抑えられる。
— 推奨：集計に必要なカラムをインデックスに含める（Covering Index）
CREATE INDEX idx_orders_user_amount
ON Orders (user_id)
STORING (amount);
このインデックスがあれば、`SELECT user_id, sum(amount) FROM Orders GROUP BY user_id` はテーブル本体を一切触らず、インデックスのみで完結する。これが「Spannerを知る者」のクエリ設計だ。
—
4. チーフアーキテクトからの助言
Spannerで集計を行う際、最も重要なのは「Where句による絞り込み」だ。
全データを舐めるような集計は、Spannerであってもコストとレイテンシの観点から許容されるべきではない。
1. 時間軸での切り出し： 常に `WHERE created_at > …` のような条件を入れ、スキャン範囲を最小化する。
2. テーブル設計の最適化： 集計ロジックをアプリケーション側に引き取るのではなく、Spannerの分散特性を活かせるようにキー設計を工夫せよ。
最後に一つだけ伝えておく。
「速いクエリは、書くものではなく、設計するものである。」
あなたの書いたその `GROUP BY` が、1年後のデータ量でも耐えうるか？ ネットワークを跨ぐデータ転送量は最小化されているか？
この視点を持ってコードに向き合えば、君の作るシステムは必ず強固なものになる。
健闘を祈る。何かあればまた聞きに来るといい。
コメント