はじめに
2025 年 7 月に発売された「わかばちゃんとつくって、壊して、直して学ぶ NewSQL 入門」で初めて NewSQL の存在を知り、少しだけ私的に勉強用途で触る機会がありました。
初めに NewSQL と聞いた時、SQL, NoSQL は英単語を元に雑に SQL 有無が違うと判断できますが新しい SQL とはなんぞやと首を傾げたものです。
本記事では NewSQL とは何か、SQL とは何が違うのかについてこの記事で話して行きたいと思います。
データベースの歴史を振り返る
NewSQL を理解するには、まずデータベースの歴史を簡単に振り返る必要があります。
SQL（リレーショナルデータベース）の時代
1970 年代に登場したリレーショナルデータベースは、ACID 特性を備え、データの整合性を強力に保証します。MySQL、PostgreSQL、Oracle などが代表例です。
RDB には、トランザクションによるデータ整合性の保証、SQL による柔軟なクエリ、厳密なスキーマ定義といった特徴があります。
しかし、Web サービスの爆発的な成長に伴い、単一サーバーでは処理しきれないデータ量やアクセス数に直面するようになりました。RDB はスケールアップは得意ですが、スケールアウトが苦手という課題がありました。RDB はトランザクションの一貫性を保証するため、複数ノードにデータを分散すると分散ロックが必要になったりと何かと不都合なことが多いからです。
NoSQL の登場
2000 年代後半、Google の BigTable や Amazon の Dynamo の論文をきっかけに、NoSQL データベースが登場しました。MongoDB、Cassandra、Redis, Valkey などが代表例です。
NoSQL には、水平スケーリングが容易、スキーマレスで柔軟なデータ構造、高い可用性と分散処理といった特徴があります。
しかし、NoSQL は ACID 特性を一部犠牲にし、BASE という緩い整合性モデルを採用しています。これは「結果整合性」とも呼ばれ、データの整合性が即座には保証されません。
CAP 定理のジレンマ
分散システムでは CAP 定理 が重要な制約となります。
CAP 定理とは以下です。
-
Consistency（一貫性）
- すべてのノードで同じデータが見える
-
Availability（可用性）
- 常にリクエストに応答できる
-
Partition tolerance（分断耐性）
- ネットワーク分断が起きても動作する
CAP 定理によると、分散システムではこの 3 つのうち 2 つしか同時に満たせないとされています。
| データベース種別 | 選択する特性 |
|---|---|
| 従来の RDB | CA（一貫性 + 可用性） |
| NoSQL | AP（可用性 + 分断耐性）または CP |
NewSQL とは
NewSQL は、RDB の ACID 特性と SQL インターフェースを維持しながら、NoSQL のようなスケーラビリティを実現するデータベースです。2011 年頃から登場し始めたようでした。
つまり、SQL の良いところと NoSQL の良いところのいいとこ取りを目指したものです。
NewSQL の主な特徴
NewSQL の主な特徴は以下になります。
- ACID トランザクション
- 従来の RDB と同様に、強い整合性を保証します。
- 水平スケーリング
- ノードを追加することで性能を線形に向上させることができます。
- SQL 互換
- 既存の SQL 知識やツールがそのまま使えます。
- 分散アーキテクチャ
- データを複数ノードに自動分散します。
- 高可用性
- ノード障害時も自動でフェイルオーバーします。
代表的な NewSQL データベースとしては、TiDB, CockroachDB, Spanner, YugabyteDB, VoltDB などがあります。
NewSQL のアーキテクチャ
NewSQL がどのようにしてスケーラビリティと ACID を両立しているのか、簡単に説明します。
分散トランザクション
NewSQL では、複数ノードにまたがるトランザクションを実現するために、2 フェーズコミット や Raft / Paxos などの分散合意アルゴリズムを使用しています。
2 フェーズコミットは、複数ノードにまたがるトランザクションを「全部成功」か「全部失敗」にするための仕組みです。まず Prepare フェーズでコーディネーターが各ノードに「コミットできるか」を確認し、次に Commit フェーズで全員が OK なら「コミット」、1 つでも NG なら「ロールバック」を指示します。
Raft や Paxos は、分散システムで「どのデータが正しいか」を複数ノードで合意するためのアルゴリズムです。過半数のノードが同意すればその値を正とし、リーダーがデータの書き込みを調整します。ノード障害があっても過半数が生きていれば動作を継続できます。
データは自動的にシャード(分割)され、各シャードは複数のノードにレプリケートされます。これにより、単一障害点がなくなり、高可用性が実現されます。
NewSQL を選ぶべきケース
NewSQL が向いているケースとしては以下が挙げられます。
- 既存の RDB ではスケーラビリティが限界に達している
- ACID トランザクションが必須だが、スケールアウトしたい
- MySQL/PostgreSQL からの移行を検討しているが、アプリケーション変更を最小限にしたい
- グローバルに分散したデータベースが必要
一方、NewSQL が向いていないケースとしては以下が考えられそうです。
- 小規模なシステムで、単一サーバーの RDB で十分
- ACID が不要で、結果整合性で問題ない
- NoSQL で十分
- 運用コストを最小限に抑えたい
- NewSQL は運用が複雑になりがち
まとめ
- SQL は CID 特性と SQL による柔軟なクエリが強み。スケールアウトが苦手
- NoSQL はスケーラビリティと柔軟性が強み。ACID を犠牲にしている
- NewSQL は RDB の ACID と NoSQL のスケーラビリティを両立した「いいとこ取り」
NewSQL は銀の弾丸ではありませんが、従来の RDB の限界を感じている場合や、スケーラビリティと整合性の両方が必要な場合に、有力な選択肢となります。