# 地理分散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 の厳密直列化可能性が**実際のアプリケーション**に必要なケースはどの程度か? 単一キー線形化可能性で済むユースケースと済まないユースケースの系統的な分類はあるか? - 専用ハードウェア(GPS/原子時計)なしに厳密直列化可能性を提供するための実現可能なアプローチは何か? - CRDB の高コンテンション・ジップ分布ワークロード(YCSB Workload A)でのスケーリング問題は悲観的読み取りロックで解決されたか? - 地理分散 DB の「Follow the Workload」(自動リースホルダー移動)はなぜ実用に至らないのか? 適応的手法を本番 DB に導入するための設計原則は何か? ## 関連 - ソース: [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]] / [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] - エンティティ: [[CockroachDB]] / [[Spanner]] / [[Cockroach Labs]] / [[Google]] - 概念: [[分散トランザクション]] / [[外部一貫性]] / [[ハイブリッド論理クロック]] / [[OLTPシステムアーキテクチャ]] ## 出典 - [[@2020__SIGMOD__CockroachDB - The Resilient Geo-Distributed SQL Database]](SIGMOD 2020) - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]](TOCS 2013)