【テクニカル・上級編】パーティション化DML – Cloud Spanner

Cloud Spannerの深淵：Partitioned DMLという名の「最後の手段」

Cloud Spannerにおけるトランザクションは、ACID特性を完全に担保するために設計されている。しかし、数億行に及ぶテーブルの「全件ステータス更新」のようなバッチ処理において、通常のRead-Writeトランザクションで挑むのは愚策だ。ロック競合によるスループットの低下、あるいはトランザクションのサイズ制限（20MB）に抵触し、システムは早々に破綻するだろう。

ここで登場するのが Partitioned DML だ。これは単なる一括更新ツールではない。Spannerの分散アーキテクチャの根幹を、あえて「制約を捨てて効率に振る」ことで最大出力させるためのプロトコルである。

1. 内部アーキテクチャ：なぜPartitioned DMLは高速なのか

通常のトランザクションと異なり、Partitioned DMLは「分散実行」を前提としている。

Spannerのデータは、スプリット（Split）という単位でノード間に分散されている。Partitioned DMLが実行されると、システムは対象のテーブルをスプリット単位で並列的に分割（Partitioning）する。そして、個々のスプリットに対して独立したDML操作を投げつける。

ここが重要だ。Partitioned DMLは、「結果整合性」に近い挙動をとる。

アトミック性の放棄: 全ての行が同時に更新されるわけではない。各スプリットの実行は独立したトランザクションとして扱われる。
ロックの最小化: 競合するような巨大なロック範囲を確保せず、スプリット内部のローカルなロックのみで処理を完結させる。

つまり、Partitioned DMLとは「完全なACID」という贅沢を捨て、「分散DBの物理限界まで並列度を叩き上げるための投機的実行モデル」なのである。

2. 極限の運用：設計者が知るべき「見えない制約」

Partitioned DMLを使う際、ドキュメントの表面をなぞるだけでは痛い目を見る。アーキテクトとして意識すべき制約は以下の通りだ。

A. 冪等性の担保は「設計者の義務」

Partitioned DMLは、途中で一部のパーティションが失敗した場合、自動的にリトライされる。しかし、一度成功したパーティションが再度実行される可能性もゼロではない（分散システムにおいて「完全なExactly-once」は幻想だ）。
したがって、DMLは必ず「冪等（Idempotent）」でなければならない。

— 悪い例：加算処理（リトライで値が倍増する可能性がある）
UPDATE Users SET Balance = Balance + 100 WHERE Status = ‘ACTIVE’;

— 良い例：状態遷移（何度実行しても結果が変わらない）
UPDATE Users SET Balance = 1000 WHERE Status = ‘ACTIVE’;

B. 読み取り整合性の代償

Partitioned DMLは、実行中のデータスナップショットを必ずしも最新に保たない。実行の瞬間に各スプリットが持っている状態に対して処理を行うため、非常に長いスキャンを行うDMLの場合、更新開始時と終了時でデータの整合性が厳密に一致しない可能性がある。「厳密なリアルタイム更新」が求められるビジネスロジックには絶対に使ってはならない。

3. パフォーマンスを極限まで引き出すチューニング

Partitioned DMLの真価を発揮させるには、以下の観点が不可欠だ。

WHERE句の最適化:

パーティショニングの効率は、WHERE句に依存する。インデックスが効かない条件でPartitioned DMLを実行すれば、Spannerは全スプリットを走査する羽目になる。プライマリキーまたは適切なセカンダリインデックスのプレフィックスに合致する条件を設計せよ。

負荷の平滑化:

一度にテーブル全体を更新しようとすれば、CPU負荷がスパイクし、通常のオンライントランザクションを駆逐する。大規模な更新は、必要に応じてキー範囲で論理的に分割し、段階的に実行するオーケストレーションが望ましい。

4. 最後に：伝説のエンジニアからの忠告

Partitioned DMLは、強力な武器だが、同時に「諸刃の剣」だ。
これを実行する前に、まず自問してほしい。

1. 「本当に今、更新する必要があるのか？」（データストア側でなく、アプリケーション側のロジックで制御できないか？）
2. 「この更新によって、メインのトラフィックに影響を与えないか？」（CPU使用率の監視なしに叩くのは素人だ。）

Spannerにおいて、Partitioned DMLを適切に扱えるということは、その分散アーキテクチャの構造（スプリット配置、トランザクション境界、レイテンシの非対称性）を理解していることと同義である。

技術とは、制約をいかに美しく回避するかというパズルに過ぎない。君たちが設計するシステムが、この先数十年、止まることなくスケーリングし続けることを期待している。