分散SQL（NewSQL）アーキテクチャ

分散SQLとは何を統合したものか

分散SQL（NewSQL）は、CockroachDB・TiDB・YugabyteDB・Google Spannerに代表される設計思想で、「RDBのようにSQLとACIDトランザクションを使える」体験を保ちながら、内部は複数台の分散KVストアとして水平スケールします。既存の要素技術を並べただけに見えますが、実際には分散合意アルゴリズム（Paxos/Raft）とシャーディング方式をレンジという単位で結合することで初めて成立する統合システムです。この結合の仕方こそが分散SQLの核心であり、単なる「合意＋分割」の足し算ではありません。

アーキテクチャは明確に2層へ分離されます。

• SQL層（ゲートウェイ層）: クエリパース、クエリプランニング、分散結合・集約の調整。任意のノードがステートレスに受け付けられる。
• 分散KVストレージ層: 実データを保持し、レンジ単位で複製・合意・トランザクションを担う。

SQL層はどのノードでリクエストを受けても良く、実データの所在を意識させません。これにより「1台のRDBに見えるインターフェース」と「実体は分散KV」というギャップを埋めます。

レンジ：シャーディングと合意グループの結合単位

分散SQLの独自性は、レンジ（range）という単位に「シャーディングの分割境界」と「合意グループの範囲」を一致させた点にあります。シャーディング方式で見たレンジ分割そのものですが、ここでは各レンジが独立したRaftグループを背負う点が違います。

レンジ = キー空間の連続区間 + それを複製するRaftグループ

Range 1: [a, g)   -> Raft group A （leaseholder: node1, followers: node2, node3）
Range 2: [g, m)   -> Raft group B （leaseholder: node4, followers: node5, node6）
Range 3: [m, +∞)  -> Raft group C （leaseholder: node2, followers: node4, node6）

1つのRaftグループが担当するのは典型的に数十〜数百MB程度の1レンジのみです。クラスタ全体では数千〜数百万のレンジが同時に、それぞれ独立した合意（Raft）を回している状態になります。合意アルゴリズムの記事で扱った「過半数の交わり」による安全性は各レンジ内で閉じており、レンジAの書き込みとレンジBの書き込みは互いのRaftログに一切干渉しません。

各レンジ内のリーダー（leaseholder、CockroachDBの用語ではリース保持者）は、そのレンジへの読み書きの窓口になります。同じ物理ノードが複数レンジのleaseholderを兼ねることも、逆に1レンジのフォロワーになることも普通にあり、ノード単位とレンジ単位のリーダーシップは独立しています。これによりクラスタ全体の書き込み負荷が特定ノードへ偏るのを防ぎます。

レンジ分割・再配置：メタデータ更新としての水平分散

レンジがしきい値（サイズや負荷）を超えると自動分割（split）されます。原理はシャーディング方式の自動splitと同じで、中央値付近のキーで区間を二分しますが、分散SQLでは分割と同時に新しいRaftグループの起動が伴います。

split の流れ（レンジ + Raftグループの同時分割）

1. Range[a, m) が閾値超過を検知
2. 分割点 s を近似中央値から決定
3. メタデータを更新: Range[a, m) -> Range[a, s) + Range[s, m)
4. 既存Raftグループを分裂させ、[a, s)・[s, m) 双方とも
   新しい独立したRaftグループとして、同じメンバー(node1,2,3)の
   構成のまま再スタート（各レプリカは既に対象データをローカルに
   保持済みのため、データコピー不要で境界だけ切れば済む）
5. ルーティングメタデータ（レンジ→ノード対応表）を更新

ポイントは、split の瞬間にはデータの物理移動が発生しないことです。両側とも直前まで同じメンバーがフォロワーを持つため、コピーは要らず、境界情報とグループ管理情報の更新だけで完結します。データの物理移動が必要になるのはその後の**再配置（rebalance）**フェーズで、負荷やディスク使用量が偏ったノード間でレンジ単位のRaftメンバーシップ変更（Raftのjoint consensus/configuration change）を使い、1レンジずつ安全に移送します。

レンジのメタデータ（境界・所属ノード・leaseholder）自体も、実は特別なレンジ（CockroachDBのMetaレンジ、TiDBのPlacement Driver管理情報）として同じ仕組みで分散管理されます。クライアントはこのメタデータをキャッシュし、古くなれば NotLeaseholder のようなリダイレクト応答から学習し直します。

SQL層と分散KV層の分離が可能にすること

もう1つの柱が、SQL層をKV層から切り離したことです。SQL層は次を担います。

1つのSQL文が複数レンジにまたがる場合（複数行の更新、複数テーブルの結合など）、SQL層は各レンジのRaftグループに個別に書き込み、それらを2相コミットに類する分散トランザクションプロトコルで束ねます。ここはPercolator方式の分散SIや決定論的トランザクション（Calvin）と重なる領域で、CockroachDBはPercolatorに近いタイムスタンプベースの方式、YugabyteDBも同様の系譜、TiDBは実際にPercolatorを直接採用しています。つまり分散SQLの全体像は「レンジ単位の合意（Raft）でストレージを水平分割し、その上にPercolator的な分散トランザクションを載せ、SQL層で1台のRDB風インターフェースに見せる」という3層構造として理解すると筋が通ります。

まとめ