【テクニカル・上級編】インターリーブテーブル – Cloud Spanner

物理層の支配：Cloud Spannerにおけるインターリーブ（Interleave）の真髄

Cloud Spannerを単なる「強力なRDB」と呼ぶ者は、その真のポテンシャルを見誤っている。Spannerは分散システムであり、物理的なデータ配置こそがレイテンシの命運を分ける。

多くのエンジニアが「JOINを速くするため」という教科書的な理解でインターリーブを利用するが、それは表層に過ぎない。なぜインターリーブが分散システムにおける「物理的な一撃」となり得るのか。その内部アーキテクチャの核心に切り込む。

—

1. スプリット（Split）を跨ぐコストの正体

Spannerのデータは「スプリット」という単位で物理的に切り出され、ノード間で再配置される。通常、親子関係にあるテーブルであっても、これらは物理的に別のスプリットに存在する可能性がある。

JOINが発生した際、データが別のノード（あるいは別のディスク領域）にあれば、ネットワークI/Oを伴うRPCが発生し、分散トランザクションのオーバーヘッドが重くのしかかる。これが大規模トラフィックにおいてP99レイテンシを悪化させる最大の要因だ。

2. インターリーブがもたらす「局所性の極致」

インターリーブを定義した瞬間、Spannerは親テーブルの行と、それに関連する子テーブルの行を、同一のスプリット内に物理的に隣接して格納するよう制御する。

物理的レイアウトの最適化:

インターリーブされたデータは、SSTable（Sorted String Table）上で親行の直後に子行が配置される。これにより、ディスクI/Oの観点では「シーケンシャルに近いランダムアクセス」を実現し、メモリ上ではキャッシュヒット率を劇的に向上させる。

ネットワークI/Oの完全排除:

同一スプリット内にデータが物理配置されるということは、親テーブルのPKを指定した子テーブルの検索が、単一のノード、単一のディスク・スキャンで完結することを意味する。分散システムでありながら、単一ノードDBのような高速性を物理的に保証する仕組み。これがインターリーブの真骨頂だ。

—

3. 実装の深淵：スキーマ定義と物理設計の勘所

単に`INTERLEAVE IN PARENT`と書けば良いわけではない。この設計は、Spannerの分散スケーラビリティに対する「賭け」でもある。

— 親テーブル：Users
CREATE TABLE Users (
UserId INT64 NOT NULL,
UserName STRING(MAX),
) PRIMARY KEY (UserId);

— 子テーブル：UserProfiles
— インターリーブにより、UserId毎に物理的に近接配置される
CREATE TABLE UserProfiles (
UserId INT64 NOT NULL,
ProfileId INT64 NOT NULL,
Data STRING(MAX),
) PRIMARY KEY (UserId, ProfileId),
INTERLEAVE IN PARENT Users ON DELETE CASCADE;

【極限の知見：設計の注意点】

Hotspottingのリスク: インターリーブは強力だが、親テーブルの特定のキーにアクセスが集中すれば、そのスプリットを抱えるノードがCPU/IO負荷のボトルネックになる。インターリーブしたからといって、キー設計の重要性が減るわけではない。むしろ、親のキーを適切にシャーディング（Bit-reversed sequence等）しなければ、物理的局所性の代償としてシステム全体のホットスポットを招く。
サイズ制限: インターリーブされた行の合計サイズが極端に大きくなると、スプリットの分割効率に悪影響を及ぼす。子テーブルが肥大化しすぎるケースでは、インターリーブを外すか、さらなるパーティショニングを検討すべきだ。

—

4. 実行計画における最適化の挙動

インターリーブが効いている場合、`Query Optimizer`は物理結合（Nested Loop Join）を非常にアグレッシブに選択する。

— このクエリは、インターリーブにより実質的に単一ノード内のデータスキャンに変換される
SELECT u.UserName, p.Data
FROM Users u
JOIN UserProfiles p ON u.UserId = p.UserId
WHERE u.UserId = 1001;

クエリ実行計画（`EXPLAIN`）を見ると、`Distributed Union`や`Cross-site Join`のようなネットワークを跨ぐオペレータが消滅し、`Scan` -> `Local Lookup` のような極めて単純で高速なパスが生成されることが確認できるはずだ。この瞬間、Spannerは分散データベースから、物理メモリ上のデータ構造を辿るような高速実行エンジンへと変貌を遂げる。

—

アーキテクトへの提言

インターリーブは「物理的なデータ配置をアプリケーションのアクセスパターンに同期させる」という、データベースチューニングの最後にして最強の武器だ。

しかし、これは同時に、「データアクセスパターンの固定化」を意味する。未来の機能拡張や、アクセスパターンの変化に対して柔軟性を失う諸刃の剣である。本当にそのテーブルは親子関係として物理的に結合すべきか？読み取り頻度は？更新頻度は？

これらを問い続けた先にある、無駄のないデータ配置こそが、Spannerを極めるということだ。分散データベースの裏側にある「物理」を制御せよ。それが伝説的なエンジニアの流儀である。