Spannerの深淵：インターリーブ（Interleave）がもたらす物理配置の極致と、その「見えない壁」
Cloud Spannerを単なる「分散RDBMS」と呼ぶ者は、その真髄を理解していない。Spannerとは、Googleのグローバル・インフラ上で「物理的なデータの近接性（Locality）」をソフトウェア定義で制御するための、極めて高度なストレージ・エンジンである。
特に、`INTERLEAVE IN PARENT`という機能は、単なる階層構造の定義ではない。これはColossus上のSSTableレベルで、親レコードと子レコードを物理的に隣接させ、単一のノード（あるいはスプリット）内でのI/Oコストを極限まで排除するための最適化メカニズムだ。
しかし、この最適化には「見えない境界線」が存在する。今回は、ドキュメントの表面をなぞるだけでは決して到達できない、アーキテクチャの制約と設計の極意について語ろう。
—
1. 物理配置の真実：インターリーブは「空間の局所性」である
インターリーブされたテーブルは、Spannerのストレージ層において、親キーの後に子キーが続くように並べ替えられた単一のデータ空間を構成する。これにより、親IDを指定したスキャン処理において、子テーブルへのアクセスは「同じディスク・ページ（あるいは近傍）」への読み取りとなる。
制限の正体：階層の深さとメモリ・オーバーヘッド
公式ドキュメントには「階層は最大6レベルまで」という制約があるが、なぜこれほど厳しいのか？
理由は、「スプリット（Split）境界の管理コスト」にある。
Spannerはデータを一定の閾値で「スプリット」という単位で分割し、Paxosグループでレプリケーションする。階層が深くなればなるほど、親レコードの更新に伴う子レコードの物理的な移動、あるいはスプリット境界の再計算における複雑度が指数関数的に増大する。
- 極限の知見: 深い階層は、書き込みのトランザクションにおいて、意図しない「範囲ロック」の拡大を招く。特定の親配下に多数の子レコードが集中する場合、スプリットが適切に分割されず、単一のスプリットに負荷が集中する「ホットスポット問題」を誘発しやすくなる。物理設計において階層は「浅く」あるべきだ。
—
2. 削除の連鎖（ON DELETE CASCADE）という名の不可逆操作
インターリーブ設計において最も恐ろしいのは、親テーブル削除時の挙動だ。`ON DELETE CASCADE`を指定した場合、子テーブルのレコードはSpanner側で自動的に、しかも「同一トランザクション内」で処理される。
— 親を削除した瞬間、インターリーブされた数百万の子レコードが
— 物理的に連続した領域から抹消される。
— これは非常に強力だが、リスクと隣り合わせだ。
DELETE FROM Parents WHERE ParentId = ‘critical_id’;
アーキテクトが知るべき「内部ロックの罠」
この削除処理は、大規模なデータセットに対して実行されると、膨大な行ロックを獲得し、長時間にわたってトランザクションログを圧迫する。
- 回避不能な事実: `ON DELETE CASCADE`は、Spannerの分散トランザクションにおいて「巨大なアトミック操作」を強いる。もし子テーブルが数千万行規模であれば、その削除トランザクションはタイムアウトや競合で撃沈するだろう。
- 現場の解法: 大規模なデータ削除が必要な場合は、`CASCADE`に頼るな。アプリケーション層でバッチ処理を切り分け、子レコードを小さなチャンクで論理削除、あるいは非同期で削除する設計に倒すべきだ。Spannerの物理設計において、`CASCADE`は「小規模・確定的な親子関係」にのみ許された特権である。
—
3. インターリーブ設計の「破壊的」な最適化戦略
インターリーブを採用すべきか否かの判断基準は、単なる「JOIN回避」ではない。
採用すべきケース
- 読み取りの局所性（Locality）がすべて: 親と子を常にセットで取得し、その頻度が極めて高い場合。
- 物理的サイズ: 子テーブルのレコードサイズが小さく、親レコードとセットで単一のスプリット（数GB単位）に収まる予測が立つ場合。
絶対に避けるべきケース
- ホットスポット: 親テーブルに対して頻繁な更新（カウンタ更新など）がある場合。
- 不均衡な増殖: 子テーブルの数が、親テーブルに対して予測不能なほど膨らむ場合。
—
最後に：エンジニアへの提言
Spannerのインターリーブは、SQLの便利機能ではない。それは、データが物理的にどう配置されるかという「ストレージの形状」を定義する行為だ。
もしあなたがインターリーブを多用して設計を複雑にしているなら、一度立ち止まって考えてほしい。その複雑性は、単一ノード内でのI/O削減という「たかだか数ミリ秒の最適化」のために、将来のシステム拡張性や可用性を犠牲にしていないか？
真のアーキテクトは、Spannerの強力な分散性能（スケーラビリティ）を信じ、インターリーブという「物理制約」に縛られることを避ける勇気を持っている。データ配置の最適化は、論理的なデータモデリングの後に来るべき、最後の手段であることを忘れるな。
この深淵を覗き込み、なおもインターリーブを設計に組み込むのであれば、その結果はすべて、Paxosのコンセンサスが証明してくれるだろう。
コメント