NewSQL(ニューエスキューエル)
1. 概要
NewSQLとは、関係データベース(RDBMS)の強い一貫性とACIDトランザクション、標準SQLインターフェースをそのまま維持しつつ、[[nosql]]が示した水平スケーラビリティ(scale-out)と高可用性を同時に達成するよう設計された次世代の分散関係データベース群を指す。2011年に451 GroupのアナリストMatthew Aslettが、「SQLの保証を守りながらOLTPをスケールさせる新興DB」を指して初めて命名した。
従来のデータ処理技術は、長らく相反する二つの軸の間で一方を捨てることを強いてきた。 一方には、数十年にわたり検証されてきた単一ノードのRDBMSがある。正規化されたスキーマ、トランザクションのACID保証、宣言型SQLという強力な武器を提供するが、処理量が一台のサーバの限界に達すると、より大きな機器に替える垂直スケール(scale-up)以外に道がなく、コストと上限の壁に阻まれた。 もう一方には、2000年代後半に登場したNoSQLがある。シャーディングによる水平スケールと高可用性を容易に得たが、その代償として強い一貫性を結果整合性(eventual consistency)に緩め、複数行・複数テーブルにまたがるトランザクションや結合、標準SQLの多くを放棄した。
NewSQLは、「スケーラビリティを得るには一貫性を捨てなければならない」というこの古い二分法に正面から挑む。 すなわち開発者には変わらずACIDとSQLを提供しつつ、その下ではデータを自動的に分割・複製・同期する分散システムを隠すことがNewSQLの本質である。 論述答案においてNewSQLは、単に「スケールするRDBMS」に矮小化してはならず、(1) シャーディング・複製をアプリケーションに透過的に隠す分散アーキテクチャ、(2) 分散環境でも直列性(serializability)を守る分散トランザクション・合意メカニズム、(3) NoSQLと区別されるSQL・ACIDの保全という三つの軸で述べるべきである。
A. 登場背景と必要性
第一に、ウェブスケールのトランザクション需要の急増が決定的な動因である。 グローバル電子商取引、フィンテック決済、大規模ゲームの課金のように、毎秒数万~数十万件の書き込みを処理しながらも「注文の重複・二重決済が決してあってはならない」業務が増えた。 NoSQLの結果整合性ではこうした金融性トランザクションの正確性を保証しにくく、単一RDBMSでは処理量を賄えないため、両者の長所を合わせた解法が切実に求められた。
第二に、NoSQL運用経験の反動である。 多くの企業がスケーラビリティのためにNoSQLを導入したが、アプリケーション層で結合・集計・トランザクションを直接実装する複雑さと、結果整合性が引き起こす微妙なデータ整合性バグに悩まされた。 「SQLとトランザクションが恋しい」という現場のフィードバックがNewSQL需要につながった。
第三に、ハードウェア・分散技術の成熟がNewSQLを現実化した。 大容量メモリ、高速ネットワーク、そしてPaxos・Raftのような検証済みの分散合意アルゴリズム([[distributed-consensus]])が普及するにつれ、かつては理論にとどまっていた「強い一貫性を維持する水平スケール」が商用水準で実装可能になった。 2012年にGoogleが発表したSpanner論文は、全地球規模で外部整合性(external consistency)を達成できることを証明し、この潮流の決定的な分岐点となった。
2. NewSQL全体アーキテクチャ
NewSQLシステムは、外見上は一つの巨大なRDBMSのように見えるが、内部的には状態を共有しない(shared-nothing)多数のノードがデータを細かく分けて分担する分散構造を持つ。 中核となる設計思想は「SQL層とストレージ層の分離」である。アプリケーションは通常のRDBMSのようにSQLを投げ、その下で分散SQLエンジンがクエリを複数のノードに分割して実行し、結果を集める。
graph TB
APP["アプリケーション(標準SQL·JDBC)"] --> LB["ロードバランサ·ゲートウェイ"]
LB --> SQL1["SQLノード(パーサ·オプティマイザ·分散実行)"]
LB --> SQL2["SQLノード(パーサ·オプティマイザ·分散実行)"]
SQL1 --> TXN["分散トランザクションコーディネータ(タイムスタンプ·2PC)"]
SQL2 --> TXN
TXN --> SH1["シャード/レンジ1(Leader + 複製本)"]
TXN --> SH2["シャード/レンジ2(Leader + 複製本)"]
TXN --> SH3["シャード/レンジ3(Leader + 複製本)"]
SH1 -. "Raft/Paxos複製" .- R1["複製本A·B"]
SH2 -. "Raft/Paxos複製" .- R2["複製本A·B"]
META["メタデータ·配置管理者(シャード位置·リバランス)"] --> SH1
META --> SH2
META --> SH3
上記の構造では、アプリケーションは標準SQLとドライバ(JDBC、PostgreSQLワイヤプロトコルなど)で接続するため、既存のRDBMSを使っていたコードをほぼそのまま再利用できる。 SQLノードは入ってきたクエリをパース・最適化し、どのシャードにどのデータがあるかをメタデータ管理者から把握したうえで、関連するシャードにのみクエリ断片を送り並列実行する。 ストレージ層はデータをキー範囲(range)またはハッシュ基準でシャードに分け、各シャードはさらにRaft/Paxosで複数の複製本に同期複製され、ノード一つが落ちても自動的にリーダーが選出されサービスが途切れない。 肝要なのは、これらすべての分割・複製・障害復旧がアプリケーションにまったく見えないよう透過的に(transparent)動作しなければならない点であり、これがNewSQLが[[db-sharding]]を手動で実装していた過去の方式と決定的に異なる点である。
A. 分散トランザクションと合意メカニズム
NewSQLの最も難しい課題は、複数のシャードに散らばったデータを修正するトランザクションでもACIDを守ることである。 単一ノードならローカルロックとログだけで十分だが、データが複数ノードに散らばると「すべてコミットされるか、すべてロールバックされる」原子性をネットワーク越しに保証しなければならない。 このためNewSQLは、従来の[two-phase-commit]で複数シャードの原子的コミットを調整しつつ、各シャード内部の複製は2PCより障害に強いRaft/Paxos合意で処理する2層構造をよく用いる。
ここでより微妙な問題が隔離性(isolation)、特に直列性である。 分散環境では、異なるノードの時計がずれて「どのトランザクションが先か」を判定しにくい。 GoogleのSpannerはTrueTimeという、GPSと原子時計で誤差範囲を数ms以内に制限した時間APIを設け、コミット時点で不確実区間だけ意図的に待機(commit-wait)することで、全域的に矛盾のない順序、すなわち外部整合性を達成する。 一方CockroachDBは特殊ハードウェアなしにハイブリッド論理時計(HLC, Hybrid Logical Clock)で物理時刻と論理カウンタを結合し、読み取り時のタイムスタンプ更新(read refresh)で直列性(SERIALIZABLE)を保証する。 このように「分散時計をどう扱うか」が各NewSQL製品のアイデンティティを分ける中核的な技術選択となる。
B. シャーディングと自動リバランスの動作
NewSQLの水平スケーラビリティは、データを小さな断片に分け、ノードの追加・削除・負荷変化に合わせてその断片を自動的に再配置する能力から生まれる。 CockroachDBはこの単位をレンジ(range)、TiDBはリージョン(region)と呼び、通常は数百MB単位に分けて特定のキー範囲を担当する。 断片が大きくなりすぎれば分割(split)し、特定ノードに負荷が偏れば別ノードへ移動(rebalance)する全過程をシステムが自ら行う。
graph LR
START["書き込み流入·データ増加"] --> CHK{"レンジサイズ/負荷超過?"}
CHK -->|"いいえ"| KEEP["現状維持·複製本同期"]
CHK -->|"はい"| SPLIT["レンジ分割(split)"]
SPLIT --> DECIDE{"ノード間の負荷不均衡?"}
DECIDE -->|"はい"| MOVE["複製本移動·リバランス"]
DECIDE -->|"いいえ"| PLACE["配置維持"]
MOVE --> RAFT["Raftグループ再構成·新リーダー選出"]
PLACE --> RAFT
KEEP --> RAFT
RAFT --> SERVE["無停止サービス継続"]
SERVE --> START
上記の流れで重要なのは、リバランスが無停止(online)で起きる点である。 複製本を移すときも、Raftグループに新しい複製本を先に追加してデータを追いつかせたうえで既存の複製本を取り除くため、過半数(quorum)が常に維持され、読み取り・書き込みが途切れない。 たとえばブラックフライデーのトラフィック急増時にノードを数台追加すれば、システムが熱い(hot)レンジを自動的に新ノードへ分散させ、数分以内に処理量が線形に近く増える——これがNewSQLが掲げる弾力的スケール(elasticity)の実体である。
3. 中核技術要素
NewSQLが「スケーラビリティと一貫性を同時に」という目標を達成するために動員する技術は複数の層にまたがり、それぞれが独立して発展してきた分散システム研究の集約である。 下記の表は補助的な整理であり、各技術が「なぜ必要か」は文章で理解すべきである。
| 層 | 中核技術 | 解決する問題 |
|---|---|---|
| ストレージ·分割 | Range/Hashシャーディング、自動リバランス | データ·負荷の水平分散 |
| 複製·可用性 | Raft/Paxos同期複製、自動フェイルオーバ | ノード障害時の無停止([[database-replication-high-availability]]) |
| トランザクション | 分散2PC、MVCC([[mvcc-snapshot-concurrency-control]]) | 複数シャードの原子性·並行性 |
| 時間·順序 | TrueTime、HLC、タイムスタンプオラクル | 分散直列性·外部整合性 |
| クエリ | 分散SQLオプティマイザ、プッシュダウン | 標準SQLをノード並列実行へ |
特にMVCC(多版同時実行制御)はNewSQL性能の隠れた土台である。 読み取りが書き込みを妨げないよう各行の複数バージョンをタイムスタンプで管理すれば、長時間の分析クエリが進行中でも短いOLTP書き込みが遅延なく流れうる。 またプッシュダウン(push-down)最適化は、フィルタ・集計演算をデータがあるストレージノードへ下ろしてネットワークで運ぶデータ量を減らす技法であり、分散環境でクエリ性能を左右する決定的要素である。
4. NewSQLの類型分類
Andy PavloとMatthew Aslettは2016年の共同論文で、NewSQLを実装方式により三つの枝に分類したが、この枠組みは今も有効な記述基準である。
第一に、完全新規アーキテクチャ(New Architectures)である。 Spanner、CockroachDB、TiDB、VoltDB、YugabyteDBのように分散を前提に底から新しく設計したエンジンで、shared-nothing構造とネイティブ分散トランザクションを備える。 最も純粋なNewSQLであり、スケーラビリティと一貫性の両面で最も強力だが、実装の複雑度と成熟度リスクが大きい。
第二に、透過的シャーディングミドルウェア(Transparent Sharding Middleware)である。 Vitess(MySQLベース、YouTubeが開発)やCitus(PostgreSQL拡張)のように、既存の単一RDBMS複数台の前段にシャーディング層を置き、アプリケーションには一つのDBのように見せる方式である。 検証済みのRDBMSエンジンを再活用して安定的だが、分散トランザクションの強度は新規アーキテクチャほどではない。
第三に、DBaaS(Database-as-a-Service)である。 Amazon Aurora、Google AlloyDBのようにクラウド事業者がストレージとコンピュートを分離して管理型で提供する形態で、運用負担を事業者に渡しつつ自動スケールを享受する。
5. RDBMS·NoSQL·NewSQLの比較
三つの系列の違いは、単純な機能の列挙ではなく、各々が何を守ろうとして何を犠牲にしたかという設計哲学の違いとして理解すべきである。
| 区分 | 従来RDBMS | NoSQL | NewSQL |
|---|---|---|---|
| スケール方式 | 垂直(scale-up) | 水平(scale-out) | 水平(scale-out) |
| 一貫性 | 強い一貫性(ACID) | 結果整合性(BASE) | 強い一貫性(ACID) |
| クエリ | 標準SQL·結合 | 限定的·API中心 | 標準SQL·結合 |
| トランザクション | 完全サポート | 限定的(単一キー) | 分散トランザクション対応 |
| 代表 | Oracle, MySQL | MongoDB, Cassandra | Spanner, CockroachDB, TiDB |
RDBMSが一貫性・SQLを守ろうとしてスケーラビリティを犠牲にしたのなら、NoSQLはスケーラビリティ・可用性を得ようと一貫性・SQLを犠牲にした。 NewSQLは「両方を守るが、その費用を分散合意とネットワーク遅延で支払う」——すなわちタダではなく、CAP定理の制約下で遅延時間と地理的複製コストを払って一貫性を買う戦略である。 したがって「NewSQLが無条件に優れている」という記述は誤りであり、地域分散環境での書き込み遅延増加というトレードオフを必ず併記すべきである。
6. 実装事例の比較
具体的な製品に下りると、設計選択の違いがはっきり現れる。 Google SpannerはTrueTimeハードウェア(GPS·原子時計)を前提に全地球規模の外部整合性を達成し、Googleの広告システム(F1)の兆ウォン規模のトランザクションを支える——ただし特殊インフラに縛られ、事実上Googleクラウド専用である。 CockroachDBはSpannerから着想を得たが、汎用ハードウェアでHLCにより直列性を実装してどこでも動かせ、PostgreSQLワイヤ互換で移植性を高めた。 TiDBはMySQL互換SQL層とRaftベースの分散KVであるTiKVを分離し、列ストレージエンジンTiFlashを加えて[[htap]]まで包含する——一つのデータでOLTPとリアルタイム分析を共に処理しようとする点が特徴である。 韓国でも大規模電子商取引・ゲーム・金融分野でTiDB・CockroachDBの導入事例が増えており、数百TB規模のデータを単一の論理DBとして運用しながらシャーディング運用負担を大きく減らした報告が続いている。
7. 深化:「Distributed SQL」への再定義と収斂
近年、業界は'NewSQL'というやや曖昧だった用語の代わりに「分散SQL(Distributed SQL)」という名称を好む。 これは「底から分散を前提に設計し、標準SQL・強い一貫性を提供するDB」というより狭く明確な範疇で、CockroachDB・YugabyteDB・TiDB・Spannerが自らをこの範疇へ再ポジショニングしている。 初期のNewSQLに含まれていた単純なシャーディングミドルウェアやインメモリOLTP製品と区別しようとする試みである。
第二の流れはストレージ・コンピュート分離とサーバレス化である。 CockroachDB Serverless、TiDB Serverlessのように使用量に応じて自動的に0まで縮小・拡張される課金モデルが登場し、中小規模のサービスも初期コスト負担なく分散DBの利点を享受できるようになった。 第三はHTAP・AIワークロードとの収斂である。 行ストレージと列ストレージを一つのシステムに統合して運用データに対するリアルタイム分析・ベクトル検索を共に提供しようとする方向で、トランザクション・分析・AIの境界がデータベース内で曖昧になりつつある。 ただし分散SQLは依然として単一ノードRDBMSに比べ書き込み遅延が大きく運用の専門性が多く求められるため、すべての業務に合う万能の解法ではないという点は変わらない。
8. 考慮事項および示唆点
第一に、一貫性要求水準に応じた選別的適用が核心である。 グローバル決済・在庫のように強い一貫性とスケーラビリティが同時に必要な中核OLTPにはNewSQLが適するが、単一リージョンで十分な業務をわざわざ分散SQLへ移すと、書き込み遅延と運用の複雑さが増すだけである。 「スケーラビリティが実際に単一RDBMSの限界を超えるか」をまず検証したうえで導入を決めるべきである。
第二に、遅延時間-一貫性-地理的分散のトレードオフを定量的に設計すべきである。 マルチリージョン同期複製はネットワーク往復のため書き込み遅延が数十ms以上増えうるので、データの局所性(locality)を活用した配置ポリシー(地域別パーティショニング)で遅延を制御する設計力が成否を分ける。
第三に、運用成熟度とエコシステムリスクを考慮すべきである。 新規アーキテクチャのNewSQLは相対的に歴史が浅く、障害対応・バックアップ・監視のツールと熟練人材が従来のRDBMSほど豊富でない。 PoCを通じて障害注入(chaos)シナリオとアップグレード・マイグレーション経路を必ず検証し、ベンダーロックイン(lock-in)とオープンソースライセンス変更の可能性も併せて点検すべきである。
第四に、既存資産との移行・共存戦略が必要である。 全面置換よりStrangler方式でスケール上のボトルネック業務から漸進的に移管し、データマイグレーション・CDCベースの同期で無停止移行を設計するのが現実的である。 標準SQL・PostgreSQL互換性が移植コストを大きく下げるため、製品選定時に互換プロトコルとマイグレーションツールの完成度を核心的な評価項目とすべきである。
第五に、技術士の観点からの展望として、NewSQL/分散SQLはクラウドネイティブ・マルチリージョンサービスの基本データ層として定着しつつあり、HTAP・ベクトル・AI機能を吸収しながら「一つのデータで取引・分析・知能」を処理する統合データプラットフォームへ進化すると展望される。
参考資料
- Andrew Pavlo, Matthew Aslett, "What's Really New with NewSQL?" ACM SIGMOD Record (2016): https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf
- Google, "Spanner: Google's Globally-Distributed Database" (OSDI 2012): https://research.google/pubs/pub39966/
- CockroachDB Architecture — Transaction Layer: https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer
- PingCAP TiDB Architecture文書: https://docs.pingcap.com/tidb/stable/tidb-architecture
- Wikipedia, "Distributed SQL": https://en.wikipedia.org/wiki/Distributed_SQL
一言まとめ: NewSQL(分散SQL)は、シャーディング·Raft複製·分散トランザクションとTrueTime/HLCベースの分散時計を通じてRDBMSのACID·標準SQLを守りつつNoSQLの水平スケーラビリティを達成した分散関係DBであり、遅延時間·一貫性·運用複雑性のトレードオフを理解し中核OLTPに選別適用することが肝要である。