Cloud Spannerのトランザクション管理：分散原子性の深淵を覗く
世の中の「分散データベース」を標榜するシステムの多くは、可用性と整合性のトレードオフという名の免罪符を盾に、データの正当性を犠牲にしてきた。しかし、Cloud Spannerは違う。TrueTimeという物理的な「時間」のインフラを武器に、分散環境下で直列化可能性（Serializability）を担保するという、データベース工学における「聖杯」を実装しきった。
今回は、Spannerのトランザクション管理という、その心臓部の鼓動を解剖する。
—
1. TrueTimeと分散トランザクションのパラダイムシフト
Spannerのトランザクションを語る上で避けて通れないのが、Googleのデータセンター内に張り巡らされた原子時計とGPS受信機による「TrueTime」だ。
通常の分散システムでは、ノード間のクロック同期は不可能であり、順序制御のために膨大な通信コスト（Paxosの往復など）を払う必要がある。しかし、Spannerは `[earliest, latest]` という不確実性区間（$\epsilon$）を持つタイムスタンプを定義することで、「時刻が特定の時刻を過ぎたことを物理的に保証する」という離れ業をやってのけた。
この恩恵は絶大だ。読み取り専用トランザクションにおいて、リーダーへの通信を待たずに、特定のタイムスタンプで「整合性の取れたスナップショット」をローカルで切り出すことが可能になる。
2. 読み取り専用（ReadOnly）トランザクションの最適化：鎖からの解放
多くのエンジニアは、読み取り専用トランザクションを単なる「SELECT文」と混同している。だが、SpannerにおけるReadOnlyトランザクションは、システムの高スループットを維持するための戦略的ツールだ。
- Snapshot Read: `read_timestamp` を指定することで、過去の任意の時点、あるいは現在までの整合性が保証された「スナップショット」を読み取れる。
- Stalenessの許容: もしアプリケーションが「最新であること」を強制しないのであれば、`exact_staleness` を指定せよ。これにより、リーダーノードへアクセスせず、近くのレプリカから読み出すことができる。これはレイテンシの劇的な低減を意味する。
— 15秒前のスナップショットを読み取る（レプリカ負荷を抑える最適化）
— 厳密な整合性が不要なレポートバッチなどで極めて強力
SET READ_ONLY_STALENESS = ’15s’;
SELECT FROM Transactions WHERE UserID = 1024;
3. 読み書き（ReadWrite）トランザクションの内部：楽観的ロックの極致
SpannerのReadWriteトランザクションは、2相コミット（2PC）とPaxosを融合させた高度な代物だ。
1. バッファリング: トランザクション中の書き込みは、クライアント側のメモリ（または一時的なバッファ）に保持され、コミット時に初めてサーバーへ送られる。
2. ロック獲得: サーバーサイドでは、書き込み対象の行に対して排他ロックを獲得する。
3. Paxosによる合意: 変更ログはPaxosグループを通じてレプリカ間で合意形成される。
ここで重要なのは、「トランザクション中に他のトランザクションが書き込みを行おうとすると、待機（Block）が発生する」という点だ。高頻度な更新が特定のキー（ホットスポット）に集中すると、Paxosの合意形成待ちとロック待ちのダブルパンチでパフォーマンスは崩壊する。
アーキテクトとしての助言:
インクリメント処理に `UPDATE` を使うのは愚策だ。データモデルを工夫し、ホットスポットを物理的に分散させるか、`Mutation` のシーケンスを最小化してロック保持時間を削り取れ。
4. パケットトランザクション（Partitioned DML）の危険な誘惑
大規模なデータ修正を行う際、通常のReadWriteトランザクションで挑むのは自殺行為だ。数百万行の更新はトランザクションのタイムアウトを招く。ここで登場するのが `Partitioned DML` だ。
これはトランザクションを複数の独立した分割（パーティション）に切り分け、それぞれを個別にコミットする。
— Partitioned DMLの実行例
— 内部的には大規模な並列処理として分解される
— 注意：原子性は行単位でしか保証されない
EXECUTE PARTITIONED DML
UPDATE Users SET Status = ‘Inactive’ WHERE LastLogin < '2023-01-01';
極限の知見:
Partitioned DMLは「全か無か」の原子性を保証しない。一部のパーティションでエラーが起きても、他のパーティションは更新されたままになる可能性がある。整合性がビジネス上のクリティカルな要件であるならば、これを使ってはならない。これは、あくまで「非整合性を許容できる大規模データバッチ」のための劇薬である。
—
最後に：データベースは「物理」である
Spannerを使いこなすということは、分散システムにおけるネットワークの物理的な距離と、TrueTimeの不確実性区間を脳内にインストールすることと同義だ。
「なぜこのクエリが遅いのか？」と悩んだとき、ドキュメントを読み返す前に、Paxosグループのトポロジーと、そのトランザクションがTrueTimeの不確実性をどれだけ消費しているかを想像してほしい。
データベースは魔法ではない。エンジニアの意図を正確に反映する、精密な機械だ。その機械の限界を理解した者だけが、Spannerという最強のエンジンを真の意味で御することができる。
次回の講義では、クエリ実行計画の内部構造と、インデックスのカーディナリティがPaxosのパフォーマンスに与える相関関係について深く切り込もう。準備はいいか。
コメント