# 分散トランザクション ## 定義 分散トランザクションとは、複数のデータパーティション・サーバー・データセンターにまたがる操作を ACID 特性(原子性・一貫性・独立性・永続性)で実行する仕組みである。単一ノードのトランザクションと異なり、参加ノード間の協調(コミットプロトコル、ロック管理)が必要になる。 主要な実現手法として二相コミット(2PC: Two-Phase Commit)が広く使われるが、コーディネーター障害時の可用性低下やレイテンシ増大が課題となる。Paxos などの複製ステートマシン上に 2PC を組み合わせることで可用性を改善できる。(Source: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]]) ## 2PC の障害シナリオ(詳説 データベース) 原子コミット問題(atomic commitment problem)を解く 2PC は、コーディネータとコホートという役割分担を持つ。コホートはある値(通常はトランザクション ID)を受け入れるか拒否するかを投票するだけで、提案を修正・代替できない。2PC が解けない前提はビザンチン障害(ノードが状態について嘘をつく)である。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.1) 障害シナリオは発生タイミングで性質が異なる。(1) **提案フェーズでのコホート障害**: 1 ノードでも投票できなければコーディネータはコミットへ進めず、可用性が低下する。(2) **賛成投票後のコホート障害**: コホートはいったん賛成すると決定を翻せないという取り決めがあるため、復旧後はコーディネータの決定ログに追いつくまで要求を処理できない。(3) **投票収集後・ブロードキャスト前のコーディネータ障害**: コホートは決定も他の参加ノードの状況も分からない不確定状態に陥り、コーディネータへの恒久障害が起これば決定を知る手段を失う。この (3) のケースが 2PC を「ブロッキングアトミックコミットアルゴリズム」たらしめる核心である。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.2.1, §13.2.2) ## Calvin による決定論的トランザクション順序 Calvin([[Calvin]])は、ロック獲得前にレプリカ間でトランザクションの実行順序と境界について合意を得ることで、ノード障害がトランザクション中断の原因にならないようにする設計を採る。**シーケンサ**が全トランザクションのエントリポイントとなり、10ms 程度の短いエポックへバッチ化してグローバルな入力シーケンスを確立する(バッチ自体がレプリケーション単位になるため個別通信が不要)。**スケジューラ**は決定論的スケジューリングプロトコルでシリアル実行順序を保ちながら部分並列実行を行う。トランザクション実行の入力(読み取りセット・書き込みセット)が事前に確定しているため、レプリカはシーケンサとそれ以上通信せずに同じ入力から同じ出力を独立に導出できる。エポック合意には Paxos または専用リーダーによる非同期レプリケーションを使う。Spanner がシャードごとの合意グループへ 2PC を適用するのとは対照的に、Calvin はそもそも実行フェーズでの調整を発生させない設計である。FaunaDB が Calvin の実装例として知られる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.4) ## 横断的知見 - **DDIA と詳説 データベースが独立に 2PC の同じ構造的弱点へ収束する**: DDIA(第8章)は「投票の後戻り不能点」と「決定の後戻り不能点」という 2 つの不可逆点、およびコーディネータ障害時の「in doubt」状態(ロック保持のままブロック)を述べる。詳説 データベース(第13章)は同じ構造を「コホートは賛成投票後に決定を翻せない」「コーディネータが投票収集後・ブロードキャスト前に障害を起こすとコホートは不確定状態に陥る」という独立した言葉で記述しており、両者は同一の不可逆点構造(コホートの投票確定・コーディネータの決定確定)を異なる教科書から導出している。これは 2PC のブロッキング問題が特定の教科書の解釈ではなく、プロトコルの構造そのものに起因することを裏付ける。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "A system of promises", "Coordinator failure", [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.2.1, §13.2.2) - **単一ノードの分離レベルを分散環境へ持ち上げるには、グローバル時刻源とアトミックコミットの2つが追加で必要になる**: [[スナップショット分離とMVCC]]は単一ノード(PostgreSQL 等)ではトランザクション ID の単調増加のみで実装できるが、Percolator が Bigtable 上に分散スナップショット分離を実装するには、(1) クラスタ全体で単調増加する**タイムスタンプオラクル**への 2 回の問い合わせ(開始時・コミット時)と、(2) 複数セルにまたがる書き込みをアトミックに可視化するための**クライアント駆動の 2PC**(prewrite でロックとプライマリ指定、commit でロック解放とメタデータ更新)という 2 つの追加機構が必要になる。単一ノードの MVCC が「どのバージョンが見えるか」という可視性ルールだけで完結するのに対し、分散版はそれに「どの時刻を基準にするか」と「複数パーティションでの可視化をどう同期するか」という調整コストが上乗せされる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.7, [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.3.6) - **楽観的 vs 悲観的トランザクションの使い分け**: F1 はデフォルトで楽観的トランザクションを採用する。楽観的は「ロックを保持しない」「サーバー側でリトライ透過化」「サーバー障害後に別サーバーへ切り替え可能」などの利点がある一方、高競合シナリオ(共有カウンタ等)では失敗率が高くなる。Spanner 論文は悲観的(二相ロック + wound-wait)を基盤として提供し、F1 がその上に楽観的レイヤーを追加した。(Source: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]], [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]) - **2PC 参加者数とレイテンシの実測**: Spanner 実測では参加者 50 まで mean 33.8ms / p99 62.4ms、100 参加者から顕著に増加(mean 55.9ms)。F1 では 1,000 行挿入でグローバルインデックスが 100 以上の 2PC 参加者を生み出す可能性があり、これが実用上のスキーマ設計制約になる。(Source: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] Table IV, [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] §3.3) - **スナップショット読み取りの戦略的活用**: F1 の SQL クエリと MapReduce は**スナップショットトランザクション**をデフォルトで使用する。Spanner の global safe timestamp(現時刻より 5-10 秒古い)に読み取ることでロックフリー・任意のレプリカで実行できる。これにより OLTP と OLAP ワークロードを分離し、読み取り専用レプリカを OLAP に活用する。(Source: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] §5, §9) - **グローバルインデックス一貫性のコスト**: 分散トランザクション上で globally-consistent なセカンダリインデックスを維持するには、インデックス更新のたびに 2PC 参加者が増える。Megastore は非同期インデックス(一貫性を緩和)で解決、F1 はグローバルインデックスを最小限にして一貫性を優先した。(Source: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] §3.3) - **2PC コーディネーター障害と lead shard パターン**: Spanner は Paxos グループ上に 2PC を載せてコーディネーター(コーディネーターは Paxos グループ)の高可用性を確保する。Aurora Limitless は別解として「ステートレスなルータにコーディネーターを置かず、ステートフルな lead shard にトランザクション状態を永続化する」設計を採用する。ルータは standby を持たなくてよく、コスト削減になる。ルータ障害時も lead shard の状態を問い合わせて in-flight トランザクションを解決できる。(Source: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] §5.4) - **時刻ベース MVCC によるクロックスキュー対処**: Spanner は TrueTime の commit wait で外部一貫性を保証する。Aurora Limitless は HLC(Hybrid Logical Clock)でシャードの論理クロックを読み取り時刻に追いつかせ、従来方式のような余分な待機なしで整合的な読み取りを実現する。commit wait は書き込みコミット時のみに限定され、ストレージ書き込みと並行実行して影響を最小化する。(Source: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] §5.5, §5.6 vs [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] §4.2.2) - **commit wait を回避する楽観的アプローチ**: CockroachDB は HLC + **Read Refresh**(楽観的再検証)で commit wait を完全に回避する。トランザクションのタイムスタンプを進める必要が生じたとき、過去の読み取り集合を再スキャンしタイムスタンプ区間内に更新がないことを確認する。成功すれば新タイムスタンプで続行、失敗はリトライ。低コンテンション YCSB では Spanner を大幅に上回るスループット・低レイテンシを実現したが、高コンテンション(Workload A)ではスケールしない。(Source: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §3.4, §6.3) - **Parallel Commits: 2PC の追加ラウンドを staging で回避**: CRDB の Parallel Commits は「staging」トランザクションステータスを使い、コミットステータスの複製と全 write intent のレプリケーション確認を並列化する。これにより通常 2PC で必要な追加コンセンサスラウンドを不要にし、セカンダリインデックス付きで 72% スループット向上・47% レイテンシ削減を実現。TLA+ で安全性を形式検証済み。(Source: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §3.1) - **2PC 回避のもう一つの系統: プロトコル最適化ではなくアーキテクチャで回避する**: Spanner・CockroachDB・Aurora Limitless は TrueTime/HLC・Read Refresh・Parallel Commits のようにコミットプロトコル自体を最適化することで分散合意コストを削減する。これに対し(classic)[[Amazon Aurora (Database)]]は、複数ノード間で合意すべき対象を「ログの適用」ではなく「ログの書き込み」だけに縮小し、gossip プロトコルで各ストレージノードが独立にログをリプレイして同じデータを再構築する設計により、そもそも 2PC を必要とする協調ポイント自体を減らす。単一 MySQL インスタンス + 分散ストレージという非対称アーキテクチャが、分散トランザクションのプロトコル改善とは異なる「協調回避(coordination avoidance)」の系統であることを示す。(Source: [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]] p.17) - **OCC の「よくある欠点」を MVCC + snapshot isolation で無効化する第 4 の系統**: Aurora DSQL は Kung & Robinson の古典的 OCC を採用しつつ、(1) MVCC で一貫スナップショット読み取りを保証し read-write 競合による中断を排除、(2) serializability ではなく snapshot isolation を選び read-write 競合の検出自体を不要にする、という 2 つの工夫で「OCC は高競合下で中断率が高い」という一般的批判を回避する。これは Spanner/CRDB の悲観的ロック、classic Aurora のログ縮小、Aurora Limitless の HLC + cross-AZ 限定のいずれとも異なる、「並行制御方式そのものを変える」系統の座標削減アプローチである。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] §2.2, §5) - **複数 Adjudicator 間の 2PC 変種は「投票のアトミック性」と「コミットのアトミック性」を分離する**: Aurora DSQL の cross-adjudicator commit protocol(Warp に着想)は、通常の 2PC が「投票」と「コミット」を同一のアトミック単位として扱うのに対し、投票フェーズを非アトミックな「コミット候補への合意」として扱い、実際のアトミック性は代表 Adjudicator の単一 Journal への単一書き込みだけで担保する。これによりクロス Journal 協調やフォールトトレラントなコーディネータが不要になり、代表 Adjudicator 障害時も「Journal に書いたか否か」の二分法だけで安全に処理できる。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] §5.1.1) - **Aurora DSQL の実測レイテンシは Spanner の 2PC 実測より大幅に低い**: Spanner の 2PC は参加者 50 で mean 33.8ms・p99 62.4ms だが、Aurora DSQL の 2 リージョン構成での COMMIT p99 は約 30ms(単一リージョンでは 7.4ms)。両者は異なるハードウェア・時代・ワークロードでの計測だが、コミット時のみの座標(DSQL)がステートメントごとの座標(Spanner の悲観的ロック)より低レイテンシになりうるという傾向を裏付ける一データ点である。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] Figure 6, [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] Table IV) - **DDIA が説明する「素の 2PC」の弱点は、Spanner/CockroachDB/Aurora Limitless の設計判断の動機そのものである**: DDIA 第8章は、単一ノードコーディネーターの 2PC が「in doubt」状態でロックを無期限保持しうること、コーディネーターのログ喪失が手動復旧を要すること、XA が異種システム間の最小公倍数ゆえデッドロック検出も SSI との統合もできないことを指摘する。これは抽象論ではなく、既存知見が示す各システムの具体的回避策と 1 対 1 対応する: Spanner はコーディネーター自体を Paxos グループ(複製・自動フェイルオーバー)にする、CockroachDB は Parallel Commits で 2PC の追加ラウンド自体を消す、Aurora Limitless はステートレスルータではなくステートフルな lead shard へコーディネーター状態を持たせて「ルータ障害 = in doubt」を回避する。DDIA の教科書的な「なぜ素の 2PC が壊れるか」の説明と、既存 4 論文が示す「壊れないためにどう作るか」の実装は、同一問題への異なる解像度の記述として接続できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Coordinator failure", "Holding locks while in doubt", "Problems with XA transactions", [[@2013__TOCS__Spanner - Google's Globally Distributed Database]], [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §3.1, [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] §5.4) - **「データベース内蔵 vs 異種間」という DDIA の二分法は、既存 4 事例がすべて前者に属することを明らかにする**: DDIA は分散トランザクションを「同一データベースソフトウェア内(database-internal)」と「異種技術をまたぐ(heterogeneous、XA が対象)」に二分し、後者は原理的に劣ると位置づける。Spanner・F1・CockroachDB・Aurora Limitless・Aurora DSQL はいずれも前者(自社ソフトウェアが全参加ノードを制御する)に属し、XA のような異種間分散トランザクションの事例はまだ本 wiki に ingest されていない。この二分法は、なぜこれら 4 事例が軒並み高性能な分散トランザクションを達成できているか(=異種間の制約を最初から負っていないから)を説明する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Distributed Transactions Across Different Systems") ## 未解決の問い - ~~Calvin・Percolator・CockroachDB など Spanner の同時代・後発の分散トランザクション実装と比べて、commit wait によるレイテンシ増大はどの程度の実用上の問題になっているか?~~ → CRDB SIGMOD 2020 §6.3 で YCSB ベンチマークにより実測。commit wait に起因するレイテンシが Spanner で顕著 - グローバルインデックスのスケーラビリティを一貫性を犠牲にせずに解決する汎用的なアプローチは存在するか? F1 は「最小化」で対処し CRDB は F1 方式オンラインスキーマ変更で対処したが、より原理的な解法はあるか? - 楽観的トランザクションが有利な条件(低競合・長い読み取りフェーズ)と悲観的が有利な条件(高競合カウンタ)の境界を、事前にワークロード分析で予測できるか? CRDB の高コンテンション YCSB Workload A でのスケール不良はこの問いを実証する - CRDB が悲観的読み取りロックを追加した後(v20.1 以降)、高コンテンション環境での性能はどう変わったか? - Aurora DSQL の write skew 緩和策(スキーマ設計で write-write 競合を強制、FOR UPDATE)は、CRDB・Spanner が悲観的ロックで最初から回避している問題をアプリケーション側に押し戻している。実運用でこの負担がどの程度深刻か、体系的な事例研究はまだない。 - DDIA が説明する XA(異種間 2PC)の実例(Narayana・JOTM・BTM・MSDTC 等のコーディネーター実装)は本 wiki にまだ ingest されていない。データベース内蔵分散トランザクション 4 事例との性能・障害耐性の定量比較は可能か。 - 3相コミット(3PC)がなぜ実用化されなかったか(非有界なネットワーク遅延・プロセス一時停止の下でアトミック性を保証できない)という DDIA の指摘は、コンセンサスプロトコルでコーディネーターを置き換える解法(第10章で詳述予定)とどう接続するか。Spanner の Paxos コーディネーターはこの解法の具体例と言えるか。 - Calvin の決定論的トランザクション順序は、読み取りセット・書き込みセットが事前に確定していることを前提にする(詳説 データベース13章はこの制約を「追加読み取りに依存するトランザクションをネイティブにサポートしない」と明記する)。条件分岐を含み read set が動的に決まるアプリケーションでは、Calvin はどう対応しているのか。事前解析パスを別途要するなら、そのオーバーヘッドは Spanner の 2PC と比べてどう評価されるか。 - Percolator の分散スナップショット分離(タイムスタンプオラクル + 2PC)と Spanner の RW トランザクション(TrueTime + 悲観的二相ロック)は、いずれも「単一ノードの分離レベルを分散環境へ持ち上げる」問題への解だが、後者は commit wait という追加コストを負う一方、前者はタイムスタンプオラクルへの往復 2 回で済む。両者のレイテンシ・スループット特性を定量比較した文献はまだ本 wiki にない。 ## 2相コミット(2PC)による原子コミット 分散トランザクションが解く根本課題は**原子コミット問題(atomic commitment problem)**である。複数ノードにまたがるトランザクションでコミット要求を単純に各ノードへ送るだけでは、一部ノードで制約違反・ネットワーク断・クラッシュが起きコミットとアボートが混在し、ノード間で不整合になる。**2相コミット(2PC、Two-Phase Commit)**はこれを防ぐ古典的アルゴリズムで、XA トランザクション(Java Transaction API 等)として異種システム間でも利用可能な形で提供される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Distributed Transactions", "Two-Phase Commit") **基本フロー**(コーディネーター/トランザクションマネージャーが参加者を統括する): 1. アプリケーションがコーディネーターからグローバル一意なトランザクション ID を取得 2. 各参加者上で単一ノードトランザクションを開始し、そのトランザクション ID を紐付ける 3. コミット準備が整うと、コーディネーターが全参加者へ **prepare** リクエストを送る 4. 参加者は prepare に「yes」と答えたら、以後そのトランザクションを**必ずコミットできる**ことを約束する(データをディスクへ書き切り、制約違反がないことを確認済み)。この時点で参加者は中断する権利を放棄する(ただし自らはまだコミットしていない) 5. 全参加者から yes を得たら、コーディネーターは commit/abort の決定を自らのログにディスク書き込みする(**commit point**)。これ以降は後戻りできない 6. コーディネーターが commit/abort リクエストを全参加者へ送る。失敗すれば成功するまで無限にリトライする 2PC には「投票の後戻り不能点」(参加者が yes と答えた時点)と「決定の後戻り不能点」(コーディネーターがディスクへ決定を書いた時点)という**2 つの「後戻りできない点」**があり、これが単一ノードのコミット(データ書き込み→コミットレコード書き込みの 1 点のみ)にはない構造である。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "A system of promises") **コーディネーター障害と「in doubt」状態**: prepare に yes と答えた後、コーディネーターがクラッシュすると、参加者は commit/abort のどちらか分からない「in doubt(不確実)」状態で待つほかない。この間、参加者は 2PL(→ [[直列化可能性]])を使っていれば読み書きロックを保持し続けるため、対象データへの他のアクセスがすべてブロックされる。コーディネーターのログが失われれば管理者による手動解決以外に手段がなく、XA の「heuristic decisions」(参加者が独断で commit/abort する緊急脱出口)は実質的にアトミック性を破る。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Coordinator failure", "Holding locks while in doubt", "Problems with XA transactions") **3相コミット(3PC)**という non-blocking な代替が提案されたが、ネットワーク遅延とプロセス一時停止が非有界な実システムではアトミック性を保証できず実用化されていない。より実践的な解法はコーディネーターを単一ノードではなくフォールトトレラントなコンセンサスプロトコルに置き換えることである(→ 第10章 Consistency and Consensus)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Three-phase commit") **異種間 2PC(XA)とデータベース内蔵分散トランザクションの違い**: XA は異種システム間の最小公倍数プロトコルとして設計されているため、システム横断のデッドロック検出や SSI との統合ができない。CockroachDB・TiDB・Spanner・FoundationDB・YugabyteDB のようなデータベース内蔵の分散トランザクションは、参加ノードが同一ソフトウェアのため (1) コーディネーターの複製と自動フェイルオーバー、(2) コーディネーターとシャードの直接通信、(3) シャードレプリケーションによる単一ノード障害での中断リスク低減、(4) デッドロック検出・一貫読み取りに対応した並行制御プロトコルとの結合、によって XA の弱点を克服できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Distributed Transactions Across Different Systems", "Database-Internal Distributed Transactions") **2PC を回避する代替策(べき等なメッセージ処理)**: メッセージブローカーとデータベースにまたがる分散トランザクションなしでも、メッセージ ID を処理済みテーブルへ記録しユニーク制約で重複挿入を防ぐことで、厳密に一度だけ(exactly-once)の処理を実現できる(→ [[べき等性]])。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]] "Exactly-Once Message Processing Revisited") ## Spanner における実現方法 [[@2013__TOCS__Spanner - Google's Globally Distributed Database]]は次の 3 種類の操作を提供する: | 操作種別 | 並行制御 | 実行レプリカ | |---|---|---| | 読み書きトランザクション(RW) | 悲観的(二相ロック + wound-wait) | リーダーのみ | | スナップショットトランザクション(RO) | ロックフリー | リーダーまたは十分更新済みのレプリカ | | スナップショット読み取り | ロックフリー | 十分更新済みのレプリカ | **読み書きトランザクションのフロー**: 1. クライアントが各 Paxos グループのリーダーに読み取りを発行(wound-wait によるデッドロック回避) 2. コミット時にコーディネーターグループを選択し、2PC を開始 3. 非コーディネーター参加者は準備タイムスタンプ(`s_prepare`)を Paxos で記録し、コーディネーターに通知 4. コーディネーターはすべての準備タイムスタンプ以上、かつ `TT.now().latest` 以上のコミットタイムスタンプ `s` を選択 5. `TT.after(s)` が真になるまで commit wait(待機時間 ≥ 2ε) 6. コミット通知後、全参加者が同一タイムスタンプで適用してロックを解放 2PC のスケーラビリティ実測: 参加者 50 まで mean 33.8ms / p99 62.4ms。100 参加者から顕著に増加(mean 55.9ms)。(Source: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] Table IV) **セーフタイム(tsafe)**: - 各レプリカが持つ「このタイムスタンプ以下の読み取りは確実に最新」という上限値 - `tsafe = min(tPaxos_safe, tTM_safe)` — Paxos セーフタイムと、準備中トランザクションが存在しない場合の ∞ との min **スナップショットトランザクションの利点**: - ロックなしで実行できるため、インフライトの書き込みをブロックしない - コミット時刻が確定した後は、どのレプリカでも実行可能 - Spanner では特定タイムスタンプでのデータベース全体の一貫スナップショット読み取りが可能(バックアップ・MapReduce に活用) ## F1 における分散トランザクションの実装 [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]は Spanner の分散トランザクション基盤の上に SQL レイヤーを構築し、3 種類のトランザクションモデルを提供する: | 種別 | ロック | レイテンシ | 用途 | |---|---|---|---| | スナップショット | なし | 最低(ローカルレプリカ) | SQL クエリ・MapReduce(デフォルト) | | 悲観的 | Spanner 二相ロック(サーバー固定) | 中 | 高競合シナリオ | | 楽観的 | なし(読み取り)→短い書き込み | 可変(競合失敗あり) | デフォルト ORM | 楽観的トランザクションは各行に hidden lock column(最終更新タイムスタンプ)を持ち、コミット時に再読み取りして競合を検出する。 ## 関連 - ソース: [[@2013__TOCS__Spanner - Google's Globally Distributed Database]], [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]], [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]], [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]], [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]], [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] - 概念: [[外部一貫性]] / [[TrueTime]] / [[ハイブリッド論理クロック]] / [[地理分散SQLデータベース]] / [[分散SQLデータベース]] / [[分散コンセンサス回避]] / [[直列化可能性]] / [[べき等性]] / [[スナップショット分離とMVCC]] - エンティティ: [[Google]] / [[James C. Corbett]] / [[Jeffrey Dean]] / [[Jeff Shute]] / [[CockroachDB]] / [[Cockroach Labs]] / [[Amazon Aurora (Database)]] / [[Aurora DSQL]] / [[Calvin]] / [[Percolator]] / [[Bigtable]] ## 出典 - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]](TOCS 2013 / OSDI 2012) - [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]](VLDB 2013) - [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]](SIGMOD 2020) - [[@2023__DataEngineeringStudy__30分でわかるデータ指向アプリケーションデザイン]](classic Amazon Aurora の gossip プロトコルによる 2PC 回避を紹介) - [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]](OCC + MVCC + Adjudicator/Journal によるコミット時座標の詳細) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 8 Transactions]](2PC の基本アルゴリズム・in doubt 状態・XA の限界・データベース内蔵分散トランザクションとの対比) - [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]](2PC/3PC の障害シナリオ・Calvin のシーケンサ設計・Percolator の分散スナップショット分離)