【実務・中級編】トランザクションタイムスタンプオーラクル – Cloud Spanner

Cloud Spannerの「神の視点」：TrueTimeとトランザクションタイムスタンプ・オーラクルを使いこなす

Cloud Spannerを単なる「リレーショナルなNoSQL」だと思っているなら、今すぐその認識を改めた方がいい。Spannerの本質は、Googleが物理法則（光速と時刻の不確実性）という制約を、原子時計とGPSという暴力的なまでのインフラでねじ伏せ、「グローバルな順序付け」を数学的に保証した点にある。

本稿では、Spannerの核となる「トランザクションタイムスタンプ」と、それを支えるTrueTimeの仕組みを、設計者の視点から解剖する。

—

1. TrueTime：なぜ「時刻のズレ」を許容できるのか

分散システムにおいて、ノード間の時刻同期は悪夢だ。NTPは数ミリ秒から数十ミリ秒の誤差を生む。しかし、Spannerはこれを「誤差を隠蔽する」のではなく、「誤差を仕様として扱う」という逆転の発想で解決した。

TrueTime APIが返すのは、単なる時刻 `t` ではなく、「[earliest, latest] というインターバル（不確実性区間）」だ。

Waitルール: コミットタイムスタンプ `s` を決定する際、Spannerは `s > TrueTime.now().latest` となるまで待機する。
意味: これにより、「物理的に未来の時刻」で書き込まれることは絶対にあり得ない。この「待機」こそが、外部整合性（External Consistency）を担保する代償だ。

エンジニアへの教訓:
この「待機」はパフォーマンスに直結する。トランザクションのコミット待機時間は、TrueTimeの不確実性（デフォルトで最大7ms程度）に依存する。これを理解せずに「なぜレイテンシが安定しないのか」と悩むのは、物理学と戦っているのと同じだ。

—

2. トランザクションタイムスタンプ・オーラクル：順序付けの魔術

Spannerでは、書き込みが発生するとTrueTimeに基づいてトランザクションタイムスタンプが割り振られる。これが「グローバルな順序」となる。

強力な武器：`commit_timestamp` カラムの活用

Spannerのテーブル設計で、`commit_timestamp` を活用できているか？これを主キーの一部やインデックスに組み込むことで、アプリケーション側で「複雑な時刻管理ロジック」を書く必要がなくなる。

— 注文履歴テーブルの設計例
CREATE TABLE Orders (
OrderId INT64 NOT NULL,
UserId INT64 NOT NULL,
Amount INT64 NOT NULL,
— 変更があった瞬間のコミット時刻をSpannerが自動生成
CommitTime TIMESTAMP OPTIONS (allow_commit_timestamp = true)
) PRIMARY KEY (OrderId);

— 読み取り時にこのタイムスタンプを使うことで
— 「その瞬間の状態」を矛盾なくスナップショット読み取りできる
SELECT FROM Orders WHERE CommitTime > ‘2023-10-01T00:00:00Z’;

—

3. 実務で「刺さる」設計パターンとアンチパターン

◎ 賢い設計：読み取り専用トランザクションでの活用

分析クエリやバッチ処理を行う際、`STALENESS` を活用せよ。Spannerはグローバルに整合したスナップショットを過去の任意の時刻（最大1時間前）で読み取れる。

Pythonクライアントでのスナップショット読み取り例
過去15秒時点の整合性が取れたデータを読み取る（読み取り専用なのでロック競合なし）
with database.snapshot(exact_staleness=datetime.timedelta(seconds=15)) as snapshot:
results = snapshot.execute_sql(“SELECT FROM Orders”)

この設計を知っているか否かで、システムの可用性とパフォーマンスは劇的に変わる。

× 致命的なアンチパターン：アプリケーションでのタイムスタンプ生成

「アプリケーション側で `time.now()` を取得してカラムに入れる」設計は、Spannerにおいては最大の愚行だ。
ノード間のクロックズレにより、トランザクションの論理的な順序が崩れる。必ずSpanner側で `spanner.commit_timestamp()` を生成させること。これこそが、グローバルな一貫性を担保する唯一の道だ。

—

4. パフォーマンスの境界線：スプリットとホットスポット

トランザクションタイムスタンプによる順序付けは、裏を返せば「主キーの先頭に順序性のある値（タイムスタンプ）を置くとホットスポットが発生する」というSpannerの物理的制約と向き合う必要がある。

ホットスポット回避: タイムスタンプを主キーの先頭にするのは避けろ。`UUID` や `bit-reversed sequence` を使い、書き込みを複数のスプリット（データ分割単位）に分散させよ。
読み取りの最適化: 順序付けが必要なクエリに対しては、`ORDER BY` ではなく、適切なセカンダリインデックスを作成する。Spannerはインデックスも透過的に分散管理する。

—

結論：Spannerを使いこなすという哲学

Cloud Spannerは「速いデータベース」ではない。「正しい順序で、かつグローバルに整合した状態を維持し続ける、極めて稀有なデータベース」だ。

TrueTimeという物理的基盤の上に、トランザクションタイムスタンプという論理的秩序を構築する。この仕組みを理解したあなたは、もう「DBのロック競合」や「分散トランザクションの不整合」に夜も眠れない日々を送る必要はない。

設計レビューの際は、こう問いかけてほしい。
「そのトランザクションは、本当にグローバルな順序付けを必要としているか？もしそうなら、TrueTimeの不確実性を設計の味方につけられているか？」

これに答えられるエンジニアこそが、真にSpannerを飼い慣らせるアーキテクトだ。