# 分散SQLデータベース ## 定義 分散 SQL データベース(Distributed SQL Database)とは、水平スケールアウト・地理的分散・高可用性を備えながら、ACID トランザクション・セカンダリインデックス・フル SQL クエリというリレーショナルデータベースの機能を完全に提供するシステムである。 2010 年代初頭まで「スケーラビリティと一貫性はトレードオフ」という通説(Brewer の CAP 定理[5]、NoSQL への移行潮流)が支配的だったが、Spanner([[@2013__TOCS__Spanner - Google's Globally Distributed Database|@ 2013__TOCS__Spanner - Google's Globally Distributed Database]])と F1([[@2013__VLDB__F1 - A Distributed SQL Database That Scales]])の登場で両立可能であることが本番規模で実証された。 典型的な実現アプローチ: - **ストレージ・複製基盤を分離**(例: F1 → Spanner、CockroachDB → Paxos/Raft ストレージ) - **階層スキーマ・クラスタ化ストレージ**でデータ局所性を確保し、クロスパーティションの 2PC を最小化 - **楽観的/スナップショット並行制御**でロック競合を回避 - **ステートレス SQL 層**でコンピュートをスケール独立に追加 ## 横断的知見 - **Spanner → F1 の 2 層設計**: Spanner は外部一貫性・グローバル分散・Paxos 複製を担い、F1 は SQL・インデックス・スキーマ管理・クエリエンジンを担う。レイヤー分離により各レイヤーを独立にスケール可能。(Source: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]) - **コミットレイテンシの壁**: 同期複製による 50-150 ms のコミットレイテンシは物理的に不可避で「隠蔽」によって対処される。Spanner 論文では commit wait という追加レイテンシも存在する。F1 はアプリケーション設計(並列・非同期化)とスキーマ設計(単一ルートトランザクション優先)で隠蔽する。(Source: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]], [[@2013__TOCS__Spanner - Google's Globally Distributed Database]]) - **グローバルインデックスのスケーラビリティ**: 分散 SQL での globally-consistent なセカンダリインデックスは、大量挿入時に 2PC 参加者が爆発するため実用的な設計制約になる。Megastore は非同期インデックスで解決したが一貫性を犠牲にした。F1 はグローバルインデックスを最小限にして整合性を優先した。(Source: [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]) - **既存 PostgreSQL 互換分散化のアプローチ**: Aurora Limitless は PostgreSQL をシャーディングせずに水平スケールさせる実用例である。PostgreSQL の xid ベーススナップショットを時刻ベース MVCC に置換し、集中型トランザクションマネージャなしで snapshot isolation と外部一貫性を実現する。最大 64 シャード・32 ルータの本番構成で 2,891,718 NOPM を達成した。地理分散 SQL(Spanner 等)とは異なり cross-AZ にスコープを絞り、Aurora 既存ストレージ層を使うことで Paxos/Raft を追加しない。(Source: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] §1, §8) - **スコープ絞り込みによる最適化**: 地理分散 SQL(Spanner・CockroachDB)は multi-region を対象にするためコミットレイテンシが大きい。Aurora Limitless は cross-AZ(同一リージョン内)に絞り、AWS Time Sync の精度(CEB < 1ms、一部リージョンでは十数μs)を活かして commit wait を最小化する。適用範囲を絞ることで設計制約を緩和できる事例。(Source: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] §5.1, §9) ## 未解決の問い - グローバルインデックスのスケーラビリティを一貫性を犠牲にせずに解決する一般的なアプローチは存在するか? - F1/Spanner は OLTP 向けに設計されているが、OLAP 向けにハッシュ分散クエリをどこまで最適化できるか? CockroachDB・YugabyteDB・TiDB など後発システムはどう解決したか? - 非ブロッキングスキーマ変更の「最大 2 バージョン同時有効 + lease」方式は、どういうケースで失敗するか? - Aurora Limitless が shard key 選択を「一方向の決定」と述べるが、resharding をゼロダウンタイムで実行できる一般的な手法は存在するか? table slice 単位の移行は十分に細粒度か? - PostgreSQL が commit order と visibility order を一致させていない(Ports & Grittner 2012 [30])問題は、分散設定でどの程度の実害があるか? Aurora Limitless の timestamp による強制一致は PostgreSQL コミュニティへのフィードバックとなりうるか? ## F1 における実装 [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]は分散 SQL データベースの初期の大規模本番事例。設計上の主要な選択: | 設計判断 | F1 の選択 | 理由 | |---|---|---| | ストレージ基盤 | Spanner(外部一貫性保証) | ACID + グローバル分散を基盤から継承 | | スキーマ構造 | 階層スキーマ + クラスタ化 | 単一ディレクトリ内で関連行を共配置 → 2PC 回避 | | 並行制御 | スナップショット/楽観的/悲観的の 3 種混在 | ユースケースに応じて使い分け | | インデックス整合性 | ローカルは即時一貫性、グローバルは制限 | グローバルインデックスの 2PC コストを認識して最小化 | | スキーマ変更 | リース付き非同期・2 バージョン同時有効 | ダウンタイムゼロのオンライン変更 | | クエリ分散 | ハッシュ分散のみ(レンジ分散なし) | Spanner のランダム分散でレンジ統計が使えないため | ## 関連 - [[分散トランザクション]] — ACID を分散環境で実現するコアメカニズム - [[外部一貫性]] — F1 が Spanner 経由で継承する一貫性保証 - [[インメモリデータベース]] — 比較対象: F1 はディスクベースでリモートストレージ - [[OLTPシステムアーキテクチャ]] — OLTP/OLAP 混在ワークロードの処理設計 ## 出典 - [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] — F1 の詳細設計 - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] — F1 の基盤ストレージ - [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] — PostgreSQL 互換分散 OLTP の実用例