# 地理分散SQLデータベース ## 定義 地理分散 SQL データベース(Geo-Distributed SQL Database)とは、複数のデータセンター・リージョン・大陸にまたがるノード群を単一のリレーショナルデータベースとして見せるシステムである。従来のシャーディングや NoSQL で犠牲にしてきた SQL インターフェイスと ACID トランザクションを維持しつつ、水平スケーラビリティ・フォールトトレランス・地理的データ配置制御を実現する。しばしば "NewSQL" とも呼ばれる。 代表的なシステムに [[Spanner]]([[@2013__TOCS__Spanner - Google's Globally Distributed Database]])と [[CockroachDB]]([[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]])がある。 ## 主要設計課題 1. **一貫性 vs レイテンシのトレードオフ**: リージョン間通信が必須のため、単一ノード RDBMS より高いコミットレイテンシが避けられない 2. **クロック同期**: グローバルな直列化可能順序を保証するには分散クロックの取り扱いが核心になる 3. **データ主権(data domiciling)**: GDPR 等の規制でユーザーデータを特定の地理的範囲に閉じ込める必要 4. **フォールトトレランス設計**: AZ 障害・リージョン障害・ネットワーク分断に対して異なる可用性保証が必要 5. **分散 SQL 実行**: クロスノード JOIN・集計を効率よく実行するための分散クエリ計画が必要 ## データ配置戦略 地理分散 DB のデータ配置は「レイテンシ最小化」「可用性最大化」「規制遵守」の 3 軸でトレードオフを持つ。 CockroachDB([[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §2.3)が提示した 3 ポリシー: | ポリシー | 読み取りレイテンシ | 書き込みレイテンシ | リージョン障害耐性 | 規制遵守 | |---|---|---|---|---| | Geo-Partitioned Replicas | ローカル | ローカル | ✗ | ✓ | | Geo-Partitioned Leaseholders | ローカル | クロスリージョン | ✓ | 部分的 | | Duplicated Indexes | 最低(完全ローカル) | 高(全レプリカ更新) | ✓ | △ | ## 横断的知見 - **Spanner と CRDB の一貫性保証の差**: Spanner は TrueTime + commit wait で**厳密直列化可能性**を実現する一方、CRDB は HLC + Read Refresh で**単一キー線形化可能性のみ**を保証。外部低レイテンシ通信チャネルがあるシステムでは CRDB の保証が不十分になりうる。(Source: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §4.2, [[@2013__TOCS__Spanner - Google's Globally Distributed Database]]) - **commit wait の実用性**: Spanner の commit wait はε(クロック不確実性上限 ≈ 4ms)だけコミットを遅延させる。CRDB の Read Refresh は低コンテンション時に commit wait を不要にするが、高コンテンション時にはリトライが増える。どちらが優れるかはワークロード特性に依存する。(Source: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] §8) - **スケーラビリティ実証**: CRDB は TPC-C 100,000 ウェアハウス(50 億行・8 TB)で 98.8% 効率を達成——Aurora の 7.3%(10,000 ウェアハウス)と対照的。従来の単一マスタ型 RDBMS は大規模地理分散ワークロードへのスケールに本質的な限界がある。(Source: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] Table 1) - **悲観的ロック(Spanner/CRDB) vs OCC+MVCC(Aurora DSQL)のコミットレイテンシへの効果**: Spanner・CockroachDB はステートメントごとに分散ロック状態を維持する悲観的並行制御を採る一方、Aurora DSQL は MVCC による座標不要読み取りと OCC による書き込みバッファリングを組み合わせ、座標をコミット時の 1 回に限定する。DSQL の実測では 2 リージョン構成でも UPDATE ステートメント数を増やしてもレイテンシが一定に保たれるのに対し、悲観的ロックベースの比較対象("Competitor A")は UPDATE 数に比例して線形にレイテンシが増加する(追加ラウンドトリップのため)。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] §2.2, Figure 5) - **クロスリージョン通信を「1 回のラウンド」に圧縮する設計**: Aurora DSQL はマルチリージョン設定で「一貫性のための座標」と「耐久性のための複製」を単一のラウンドの通信で両方達成できると主張する(3 リージョン構成では 3 のうち近い方の 2 リージョンへのクォーラムコミットで足りる)。Spanner の TrueTime commit wait・CRDB の Read Refresh がいずれも「単一リーダー/単一 Paxos グループでの合意」を前提とするのに対し、DSQL は Adjudicator + 単一 Journal へのアトミック書き込みという別経路でクロスリージョン座標回数を最小化する。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] §2.3, §2.5) - **一貫性優先(PCEC)の選択は 3 システムに共通**: Spanner・CockroachDB・Aurora DSQL はいずれも Abadi の PACELC 分類で PCEC(ネットワーク分断時は一貫性を優先)を選ぶ。ただし DSQL は多数派側のリージョンには一貫性と可用性の両方を提供し続けると明示しており、これは Spanner の majority-side availability と同種の保証である。(Source: [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] §2.3) - **「個々のノードではなく合意グループをコホートにする」という可用性改善策は、教科書レベルの一般原則として独立に確認できる**: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.2.1, §13.5 は、2PC が「1つでもコホートが利用不可なら中断せざるを得ない」という一般的な可用性低下の問題を説明したうえで、Spanner がこれを「個々のノードではなく Paxos グループに対して 2PC を実行する」ことで改善する、と明示的に接続する。本 concept が既に記録する Spanner・CockroachDB のフォールトトレランス設計課題は、この「2PC のコホート単位を個別ノードから合意グループへ格上げする」という一般原則の具体例として整理できる。原論文([[@2013__TOCS__Spanner - Google's Globally Distributed Database]])は同じ設計を実装の詳細として述べるが、詳説 データベースは 2PC 一般論からの導出として提示しており、抽象化のレベルが異なる2つの独立ソースが同じ設計判断に収束している。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] §13.2.1, §13.5, [[@2013__TOCS__Spanner - Google's Globally Distributed Database]]) ## 未解決の問い - Spanner の厳密直列化可能性が**実際のアプリケーション**に必要なケースはどの程度か? 単一キー線形化可能性で済むユースケースと済まないユースケースの系統的な分類はあるか? - 専用ハードウェア(GPS/原子時計)なしに厳密直列化可能性を提供するための実現可能なアプローチは何か? - CRDB の高コンテンション・ジップ分布ワークロード(YCSB Workload A)でのスケーリング問題は悲観的読み取りロックで解決されたか? - 地理分散 DB の「Follow the Workload」(自動リースホルダー移動)はなぜ実用に至らないのか? 適応的手法を本番 DB に導入するための設計原則は何か? - Aurora DSQL は OCC + MVCC でステートメントごとのロック状態を避けるが、write skew 異常を許容する。Spanner/CRDB の悲観的ロックアプローチと比べ、write skew が実際のアプリケーションでどの程度の頻度・深刻度で問題になるかの定量比較データはまだない。 - Spanner が「Paxos グループを2PCコホートにする」ことで可用性を改善する一方、グループ内の過半数障害時にはそのグループ自体が2PCへ応答できなくなる。CockroachDB の Range ベースの Raft グループも同じ制約を持つはずだが、詳説 データベース13章・CockroachDB論文のいずれも「グループ自体の過半数障害時の2PC挙動」を明示的には比較していない。 ## 関連 - ソース: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] / [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] / [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]] - エンティティ: [[CockroachDB]] / [[Spanner]] / [[Cockroach Labs]] / [[Google]] / [[Aurora DSQL]] - 概念: [[分散トランザクション]] / [[外部一貫性]] / [[ハイブリッド論理クロック]] / [[OLTPシステムアーキテクチャ]] / [[分散コンセンサス回避]] ## 出典 - [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]](SIGMOD 2020) - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]](TOCS 2013) - [[@2026__arXiv__Aurora DSQL - Scalable, Multi-Region OLTP]](arXiv 2026) - [[@2021__OReillyJapan__詳説 データベース - Chapter 13 分散トランザクション]](§13.2, §13.5 Paxos グループを 2PC コホートにする可用性改善策)