コンピューターサイエンス：アルゴリズム / OS / ネットワーク / DB

NewSQL と分散 SQL

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

NewSQL と分散 SQL

このレッスンで分かること

  • NoSQL では解けなかった「SQL + ACID + 分散」の難題
  • NewSQL を支える Raft / Paxos と TrueTime
  • TiDB / Spanner / CockroachDB の特徴比較

NewSQL と分散 SQL とは

TiDB / Spanner が実現する分散環境での ACID。本レッスンでは、NewSQL と分散 SQL の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

NoSQL の限界

2000 年代の NoSQL ブームで、Cassandra や MongoDB は「スケールするデータベース」として人気を博しました。しかし運用すると次の声が増えました。

  • SQL で書きたい（学習コストとエコシステム）
  • JOIN が欲しい（アプリ側結合は遅い）
  • ACID トランザクションが欲しい（金融や決済で必須）
  • スキーマがあった方がバグが減る
  • それでも分散スケールは諦めたくない

「整合性を取り戻しつつ、分散もしたい」という欲張りな要件に応えるのが NewSQL です。

NewSQL の定義

NewSQL は次の特徴を全て備える DB を指します。

  • SQL インターフェイス — 既存アプリの SQL がそのまま動く
  • ACID トランザクション — 強整合性
  • 水平スケール — シャーディングを内蔵し、ノード追加で線形スケール
  • 自動リバランス — シャード分割・統合・移動を自動化

代表的な実装は Google Spanner、CockroachDB、TiDB、YugabyteDB です。

diagram (will load when visible)

分散環境で ACID を実現する難しさ

シングルノードで ACID を保証する技術は確立されています。難しいのは「複数ノードにまたがる トランザクション」で ACID を守ることです。

ノード A の UPDATE とノード B の UPDATE が同じトランザクションに含まれるとき、次の問題が出ます。

  • A は成功、B は失敗、を防ぐ（原子性）
  • A の値変更が B から見えるタイミングを揃える（分離性）
  • ノード障害でも変更が消えないようにする（永続性）

これを実現する技術が次の 3 つです。

1. コンセンサス（合意）アルゴリズム

複数ノードで「同じ決定をする」ためのプロトコルです。代表は Paxos と Raft です。

Raft の流れは次の通りです。

  1. 1 ノードを Leader に選出
  2. クライアントの変更はまず Leader に届く
  3. Leader が Follower に変更ログを送る
  4. 過半数の Follower が受信 したら、Leader が COMMIT 確定
  5. クライアントに成功を返す

過半数（クォーラム）で合意するので、少数派ノードが落ちても継続可能 です。5 ノードなら 2 ノードまでの障害に耐えます。

TiDB は Raft、Spanner は Paxos、CockroachDB は Raft を使います。

2. グローバル順序付け

分散環境で「どの書き込みが先か」を決めるのは難しい問題です。ノードの時計はわずかにずれるため、単純なタイムスタンプでは順序が決められません。

Spanner の TrueTime

Google Spanner は TrueTime という独自の時刻 API を持ちます。各データセンターに GPS と原子時計 を設置し、「現在時刻は [t1, t2] の範囲」という 不確実性付き で時刻を取ります。

書き込み時にこの範囲を待ってから COMMIT するため、後続トランザクションは絶対に先のトランザクションより新しい時刻を持ちます。これで 外部一貫性 (Linearizability) を実現します。

TiDB / CockroachDB の TSO

GPS を使えない NewSQL の多くは、順序付けの方法が二手に分かれます。TiDB は TSO (Timestamp Oracle) という中央タイムスタンプサーバを置き、PD (Placement Driver) がこれを担います。一方 CockroachDB と YugabyteDB は中央サーバを置かず、HLC (Hybrid Logical Clock) を使って各ノードのローカル時計を同期することでグローバル順序を決めます。

3. 分散トランザクションプロトコル

2 相コミット (2PC) が古典的な分散トランザクションプロトコルです。

  1. Prepare フェーズ — Coordinator が各 Participant に「コミット可能か」を問い、全員 OK ならログを書く
  2. Commit フェーズ — 全員に COMMIT 指示

2PC は Coordinator が落ちると Participant がブロックする問題（ブロッキング）があり、現代では Percolator（TiDB が採用）や Paxos Commit など改良型が使われます。

主要 NewSQL の比較

製品開発元コンセンサス順序特徴
SpannerGooglePaxosTrueTime (GPS + 原子時計)商用クラウド限定、世界規模
CockroachDBCockroach LabsRaftHLCOSS、Spanner にインスパイア
TiDBPingCAPRaftTSO (PD)OSS、MySQL 互換
YugabyteDBYugabyteRaftHLCPostgreSQL 互換

TiDB は MySQL クライアントから接続できるので、既存アプリの移行コストが極めて低いです。chotdekiru でも TiDB Cloud を使っています。

NewSQL のオーバーヘッド

万能ではありません。次のコストがあります。

  • 書き込みレイテンシ — クォーラムへの同期が必要で、シングルノード DB より遅い（数 ms 〜 数十 ms）
  • 複雑な運用 — Raft グループの管理、レプリカ配置の最適化、リバランス
  • コスト — ノード数 × データレプリカ数 (通常 3 倍) のリソース消費

書き込みが少なく単一マシンに収まる規模なら、PostgreSQL や MySQL の方がシンプルで速いです。

NewSQL は「スケールが必要になった瞬間に SQL を保てる」のが利点。最初から必要なわけではない。

いつ NewSQL を選ぶか

  • データ量がペタバイト規模に向かう
  • 書き込みが秒間数万を超える見込み
  • 既存アプリの SQL を捨てたくない
  • ACID トランザクションが業務要件
  • 地理分散が必要

逆に「データ 100GB、QPS 1000」なら PostgreSQL で十分です。NewSQL は 将来の選択肢として知っておく のが正解です。

OLTP / HTAP / OLAP

最新の NewSQL は HTAP (Hybrid Transactional / Analytical Processing) をうたいます。これは「OLTP（業務系）と OLAP（分析系）を 1 つの DB で扱う」コンセプトです。

TiDB の TiFlash はカラム指向ストレージを別途持ち、分析クエリを高速化します。CockroachDB はカラムストアではなくベクトル化実行エンジンで分析性能を高めるアプローチを取ります。OLTP のリアルタイムなデータをそのまま分析できるのが強みです。

やってみよう

  • TiDB Cloud の無料プラン (Serverless) でアカウントを作り、MySQL クライアントで接続する
  • 100 万行を INSERT し、ノードの裏で Raft が動いているのを意識する
  • EXPLAIN ANALYZE で TiDB の分散実行計画を読む
  • 同じテーブルをカラム指向の TiFlash にレプリカし、集計クエリの速度差を見る

コース修了

これで データベース基礎：RDB理論・B-tree・トランザクション のコースは完了です。

ER モデルから始まり、正規化、B+tree、ACID、MVCC、EXPLAIN、シャーディング、NewSQL まで一周しました。ここで学んだ理論は、PostgreSQL でも MySQL でも TiDB でも、あらゆる DB に共通する 不変の知識 です。

次は実技編の SQL 入門コース で実際に手を動かすか、より深い分散システムの世界（Raft の論文を読む、Spanner の論文を読む）に進むのがおすすめです。

よくある質問

Q. このトピックは実務でどう役立ちますか？

A. DB のクエリ最適化、API 設計、データ構造の選択など、設計判断の根拠になります。表面的にライブラリを使うだけでなく「なぜそれが速いのか」を理解できると、性能問題を未然に防げます。コーディング面接でも頻出のテーマです。

Q. 計算量はどう求めれば良いですか？

A. ループのネストごとに掛け算する、再帰なら漸化式から解く、というのが基本です。Big-O 表記は定数倍と低次の項を無視するため、n の指数（n²、n log n など）に注目してください。最悪・平均・最良の 3 つを意識すると説得力が増します。

Q. 覚えるべき定番アルゴリズムは何ですか？

A. 二分探索、クイックソート/マージソート、BFS/DFS、ダイクストラ、DP の基本問題（フィボナッチ・ナップサック）が必修です。これらを「白紙から書ける」状態にすると、応用問題が一気に解けるようになります。

次のレッスン

これでこのコースの最後のレッスンです。お疲れさまでした。コース全体を振り返り、つまずいた箇所を 1 つ選んで復習してみましょう。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. NewSQL と分散 SQL の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. NewSQL と分散 SQL とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン