【入門編】テーブルのインターリーブ – Cloud Spanner

こんにちは！Cloud Spannerの世界へようこそ。
チーフアーキテクトの私です。

今回は、Cloud Spannerのパフォーマンスを劇的に引き出すための奥義、「テーブルのインターリーブ（親子関係の同居）」についてお話しします。

「なんだか難しそうな名前だな…」と思いましたか？
大丈夫。専門用語はできるだけ使わずに、身近な例え話からゆっくり紐解いていきます。ここをクリアすれば、Cloud Spannerの基本はバッチリマスターできますよ。それでは、一緒に見ていきましょう！

—

1. なぜ通常のデータベースは「バラバラ」に置かれるのか？

まず、普段私たちが使っている一般的なデータベース（例えば、よくあるリレーショナルデータベース）を想像してみてください。

例えば、「お客様（親）」という台帳と、「そのお客様の注文履歴（子）」という台帳があったとします。
普通のデータベースは、几帳面に別のファイル（別の場所）にこれらを保管します。

お客様のデータ保管庫：東京倉庫
注文履歴のデータ保管庫：大阪倉庫

これだと、あるお客様の注文履歴を見たいとき、いちいち「大阪倉庫」まで荷物を取りに行かなければなりませんよね。データ量が増えてくると、この「倉庫を行き来する時間（ネットワークの通信コスト）」が、システムを遅くする大きな原因になってしまいます。

2. Spannerの「インターリーブ」とは、同じ段ボール箱に詰めること

ここで登場するのが、Cloud Spannerのインターリーブ（Interleave）という機能です。

インターリーブを直訳すると「交互に織り込む」ですが、Cloud Spannerの世界では「親データと、それに紐づく子データを、物理的にまったく同じ場所（同じスプリット／同じハードディスクの隣同士）に並べて保管する技術」を指します。

日常の例えで考えてみましょう。

通常の方法：

「山田さん」という顧客カードはAのファイルボックスに入れ、「山田さんの過去の買い物メモ」は、はるか遠くのBのファイルボックスにしまう。

インターリーブの方法：

「山田さん」という大きな仕切り板のすぐ後ろに、その人専用の買い物メモをペタペタと隙間なく貼り付けて、一つの大きな段ボール箱（物理的なストレージ）にまとめてしまう。

こうすればどうでしょう？
Cloud Spannerが「山田さんのデータと、その注文履歴を見せて！」と言われたとき、あちこちの倉庫を探し回る必要がありません。目の前にある段ボール箱をパカッと開けるだけで、親も子も一瞬で揃って手に入ります。これが、インターリーブによる結合（JOIN）性能が爆発的に速くなる理由です。

—

3. インターリーブの設計：親子関係を作ってみよう

それでは、実際にCloud Spannerでこの仕組みをどう作るのか、SQLのイメージを見てみましょう。（難しい構文は気にせず、雰囲気を感じてくださいね）

まずは「親テーブル（お客様）」を作ります。

— 親テーブル：お客様情報
CREATE TABLE Customers (
CustomerID INT64, — お客様ID（これが親の目印）
CustomerName STRING(100), — お客様の名前
) PRIMARY KEY(CustomerID);

次に、この親にぴったりくっつく「子テーブル（注文履歴）」を作ります。ここで魔法の言葉 `INTERLEAVE IN PARENT` を使います。

— 子テーブル：注文履歴（親であるCustomersにインターリーブする）
CREATE TABLE Orders (
CustomerID INT64, — 親と同じお客様ID（誰の注文か）
OrderID INT64, — 注文ID
OrderDate DATE, — 注文日
) PRIMARY KEY(CustomerID, OrderID),
— ここがポイント！親テーブルの真隣に配置してね、という指示
INTERLEAVE IN PARENT Customers ON DELETE CASCADE;

最後の `ON DELETE CASCADE` は、「もし親（お客様）のデータを消したら、それに紐づく子（注文履歴）のデータも一緒に片付けてね」というお片付けのルールです。家族のような深い結びつきですね。

—

4. 使うときの注意点（ここがプロの知見！）

このインターリーブ、魔法のように素晴らしい機能ですが、設計する上での「絶対的なルール」があります。

それは、「親の主キー（目印）が、子の主キーの先頭に含まれていなければならない」というルールです。

先ほどの例を思い出してください。

親の主キー：`CustomerID`
子の主キー：`CustomerID`, `OrderID`

子の主キーの「一番最初（左側）」に、親のIDが必ず入っていますよね。
これは人間社会で例えるなら、「『山田家』の子供という情報が、名札の苗字に必ず入っていること」と同じです。「佐藤家」の棚に「山田家の太郎くん」の荷物を挟み込むことはできないのと同じように、Spannerでも「誰の子供なのか」が構造上ハッキリしていないと、同じ段ボール箱に綺麗に並べることができないのです。

まとめ

いかがでしたでしょうか？

インターリーブとは：親と子のデータを物理的に同じ場所に同居させる仕組み。
メリット：倉庫を行き来する必要がないため、結合クエリ（JOIN）が圧倒的に高速になる。
コツ：子の主キーの先頭に、親の主キーを含めるように設計する。

Cloud Spannerは、世界中の膨大なデータを扱うモンスター級のデータベースですが、こうした基本の物理構造（どうやってデータを箱に詰めるか）をイメージできるようになると、設計が急に楽しく、そして美しくなります。

ここをクリアしたあなたなら、もうSpannerの基本マスターです！自信を持って次のステップへ進んでくださいね。