やあ。Cloud Spannerという、少し癖があるけれど、一度使いこなせば最強の武器になるデータベースの世界へようこそ。
多くのエンジニアが「Spannerって難しそう…」と身構えるけれど、実はその本質はとてもシンプルなんだ。今日は、Spannerの性能を最大限に引き出すための「インターリーブ（Interleave）」という仕組みについて、君が明日から設計に自信を持てるように解説していくよ。
—
「インターリーブ」って何？：本棚の整理術に例えてみる
想像してみてほしい。君が巨大な図書館の司書だとしよう。
ある「本（親データ）」には、その本の「感想レビュー（子データ）」がたくさん付いているよね。
普通のデータベースなら、本とレビューは別々の場所に保管される。でも、Spannerのインターリーブを使うと、「本と、そのレビューを物理的に同じ棚の、すぐ隣に並べて置く」ことができるんだ。
これがどうして凄いの？
読者が「この本とレビューを全部持ってきて！」と言ったとき、司書は遠くの倉庫まで走る必要がない。「目の前の棚から一気に掴み取る」だけで済むから、爆速でデータが手に入るわけだ。これがインターリーブの本質だ。
でも、「制限」というルールを忘れてはいけない
この魔法のような仕組みには、いくつか守るべき「制約」がある。ここを理解せずに設計すると、後で大怪我をするから注意しよう。
1. 階層の深さは「欲張りすぎない」
インターリーブは「親の中に子を、その中に孫を…」と重ねていけるけれど、あまり深くしすぎると逆効果になる。
- 深さ制限の目安: 一般的には3〜4階層程度に留めるのが賢い。
- なぜ？: 階層が深すぎると、データの管理が複雑になりすぎて、かえって整理整頓（データの読み書き）に時間がかかるようになるからだ。欲張らず、本当に「セットで取得する頻度が高いデータ」だけをくっつけるのがコツだよ。
2. 親が消えれば、子も消える（カスケード削除の恐怖）
これが最も重要な注意点だ。インターリーブされたデータは、いわば「運命共同体」なんだ。
- 「本」という親テーブルを削除すると、紐付いている「レビュー」という子テーブルのデータは、一瞬にしてすべて消滅する。
- もし、「本は廃版になったけど、レビューのデータだけはアーカイブとして残しておきたい」という要件があるなら、インターリーブを使ってはいけない。
【設計のヒント】
> 「親データが消えるとき、子データは道連れで消えても困らないか？」
> この問いに「YES」と言い切れる関係性だけをインターリーブにする。これがアーキテクトの矜持だよ。
—
実践：テーブルを作るときのイメージ
SQLを書くときも、この「隣に置く」という意識が大切なんだ。
— 親テーブル：まずは本を定義
CREATE TABLE Books (
BookId INT64 NOT NULL,
Title STRING(MAX),
) PRIMARY KEY (BookId);
— 子テーブル：インターリーブで「Booksの中」に住まわせる
CREATE TABLE Reviews (
BookId INT64 NOT NULL,
ReviewId INT64 NOT NULL,
Comment STRING(MAX),
) PRIMARY KEY (BookId, ReviewId),
— ここがインターリーブの魔法！
— 「ReviewsはBooksの中に住むよ」と宣言している
INTERLEAVE IN PARENT Books ON DELETE CASCADE;
- `INTERLEAVE IN PARENT Books`: これで物理的に隣接配置される。
- `ON DELETE CASCADE`: 「親が消えたら子も消す」という覚悟のコードだ。
—
最後に：君へのアドバイス
「インターリーブを使えば何でも速くなる」というのは幻想だ。
本当に重要なのは、「君が扱うデータは、どんな単位で読み出されることが多いのか？」というアクセスパターンを想像すること。
1. セットで取得するならインターリーブする。
2. バラバラに管理したい、あるいは寿命が違うならインターリーブしない。
たったこれだけのことだけど、ここをクリアすれば、君はもうCloud Spannerの基本をマスターしたと言っても過言じゃない。
何か設計で迷ったら、いつでも聞いてくれ。データベースの設計は、まるで建築と同じ。土台がしっかりしていれば、どんなに高いビル（大規模システム）を建てても揺るがないからね。
さあ、次はどんなデータ構造を組み立ててみる？応援しているよ。
コメント