【テクニカル・上級編】外部キー制約 – Cloud Spanner

Cloud Spannerの外部キー制約：分散トランザクションの深淵と「見えないコスト」

Cloud Spannerが「外部キー（Foreign Key）をサポートした」というニュースは、多くのエンジニアにとって福音だった。しかし、分散データベースの極北であるSpannerにおいて、外部キーを安易に定義することは、アーキテクチャの根幹を揺るがす諸刃の剣となり得る。

今日は、ドキュメントの表面的な記述の裏側にある、Spannerの分散トランザクションモデルと、外部キーが引き起こす「見えないオーバーヘッド」について、チーフアーキテクトの視点から解き明かそう。

—

1. 外部キーは「単なる制約」ではない

従来のRDBMSにおいて、外部キーは参照整合性を維持するためのメタデータに過ぎない。しかし、Spannerのような分散環境において、外部キー制約を付与するということは、「分散トランザクションのガードレールを動的に構築する」という重い処理を意味する。

Spannerの外部キーは、以下の二重のチェックを強制する。
1. INSERT/UPDATE時の参照先確認: 参照先テーブルの存在確認。
2. DELETE/UPDATE時の参照元確認: `ON DELETE CASCADE` や `RESTRICT` をトリガーとした、関連行の探索と整合性維持。

これらはすべて、Spannerの分散ロックマネージャとトランザクションプロトコル（2PC）の管理下にある。つまり、外部キーを貼ることで、トランザクションが触れるべきスプリット（Split）が増え、ネットワークホップ数とロック競合のリスクが幾何級数的に増大するのだ。

2. `ON DELETE CASCADE` の真のコスト

特に注意すべきは `ON DELETE CASCADE` である。単一ノードのMySQLであれば、ストレージエンジン内でのポインタ追跡で済むかもしれない。だが、Spannerでこれを実行すると何が起きるか？

分散ロックの爆発: 親レコードを削除した際、その子レコードを特定するために「子テーブルのインデックス（または主キー）」に対して、分散環境下でRead-Modify-Writeが発生する。
トランザクションの肥大化: 子テーブルが別スプリット（別のノード）に存在する場合、親の削除処理は即座に分散トランザクションへと昇格する。大規模なデータセットで連鎖削除が発生すると、そのトランザクションの生存期間が長くなり、システム全体のスループットを低下させる。

— 危険なCASCADEの例
— 親テーブルの削除が、遠隔地にある子テーブルへの「書き込みロック」を要求し続ける
ALTER TABLE Orders
ADD CONSTRAINT FK_CustomerOrder
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
ON DELETE CASCADE;

アーキテクトとして忠告する。高頻度で更新されるテーブルに対して、安易に `ON DELETE CASCADE` を使用してはならない。 削除の連鎖は、アプリケーション層で非同期的に処理する「論理削除」や「バッチ削除」に置き換えるのが、高負荷システムにおける定石だ。

3. パフォーマンスを最適化する「スプリット・アフィニティ」

Spannerの真髄は「インターリーブ（Interleave）」にある。外部キー制約を正しく扱うための究極の最適化は、参照関係にあるテーブル同士を物理的に同じスプリットに配置することだ。

— インターリーブによる物理的近接化
— 子テーブルを親テーブルの配下に置くことで、外部キーチェックのオーバーヘッドを
— 同一ノード内、あるいは同一スプリット内のメモリ操作にまで抑え込む
CREATE TABLE Customers (
CustomerID INT64 NOT NULL,
…
) PRIMARY KEY (CustomerID);

CREATE TABLE Orders (
CustomerID INT64 NOT NULL,
OrderID INT64 NOT NULL,
…
) PRIMARY KEY (CustomerID, OrderID),
INTERLEAVE IN PARENT Customers ON DELETE CASCADE;

インターリーブを活用すれば、外部キーのチェックは「分散トランザクション」から「ローカルトランザクション」へと昇華する。もし君が外部キー制約を多用する設計をしているなら、それはインターリーブの設計とセットでなければならない。さもなくば、それは単なるボトルネック製造機となる。

4. 伝説のエンジニアからの提言：制約か、コードか

結局のところ、Spannerにおいて外部キーを定義する目的は何か？

1. データ整合性の保証: ビジネスロジックが複雑で、整合性をDBレベルで担保せざるを得ない場合。
2. クエリプランナーへのヒント: 外部キーがあることで、オプティマイザは効率的な結合順序を選択できる。

しかし、これらのメリットと引き換えに、書き込みパフォーマンスの低下と、デッドロックの可能性を受け入れなければならない。

私の設計指針:

読み取りが主体のマスタデータ: 積極的に外部キーを付与し、オプティマイザを利かせる。
書き込みが激しいトランザクションテーブル: 外部キーによる制約は避け、アプリケーションコードレベルで整合性を保証する（またはSpannerのインターリーブ機能で物理的に最適化する）。

結論

Cloud Spannerにおける外部キーは、単なる「便利な機能」ではない。それは、君たちのシステムの「分散境界」を定義する強力なツールだ。

ドキュメントを読み、機能を理解しただけで満足してはならない。パケットが飛び交い、ロックが競合し、スプリットが再配置されるその先にある「見えない挙動」を想像せよ。それこそが、世界最高峰のエンジニアが持つべき視座である。

Spannerは、君が正しく設計すれば、期待以上のスケールを返す。しかし、設計を怠れば、その分散アーキテクチャの重みで自らのシステムを押し潰すだろう。

次にテーブルを `ALTER` する時、その制約がスプリットの境界を跨いでいないか、今一度自問してほしい。