🐎

今更聞けない NewSQL とは何か？ RDS と NoSQL の「いいとこ取り」アーキテクチャ

に公開
SQL
NoSQL
Aurora
NewSQL
TiDB
tech

はじめに

先日、メルカリがオンプレミスのデータベースをTiDB Cloudへ移行した事例が公開され、話題となりました。

https://pingcap.co.jp/case-study/mercari-tidb-cloud/

大規模なトランザクションをさばくために選ばれた 「NewSQL」 というカテゴリ。
本記事では、AWS Aurora や TiDB に代表される NewSQL が、従来の RDS や NoSQL と何が違うのか、そしてどのようにして「一貫性（ACID）」と「拡張性（Scale）」を両立しているのか AWS Aurora を例に挙げて解説します。

1. NewSQL = 分散 RDS

一言で言えば、NewSQL は RDS のデータ整合性と、NoSQL の分散拡張性のいいとこ取りをしたデータベースです。

  • RDS (Relational Database): 厳密なデータ整合性 (ACID) を持つが、分散（スケールアウト）が苦手。
  • NoSQL: 無限にスケールアウトできるが、厳密な整合性や複雑な検索 (JOIN など) を犠牲にしている。

これらを理解するために、図書館の司書RDS と 袋詰めNoSQLというアナロジーで比較してみましょう。

2. 比較：几帳面な司書 vs 袋詰め

RDS：几帳面な司書（B-Tree）

RDS は、データを B-Tree などのインデックスを用いて厳密に管理します。

  • 仕組み: 本（データ）の内容を細かく分解し、別々の棚に整理します。「タイトル」は A 棚、「著者」は B 棚、「出版年」は C 棚へ。
  • 検索時: あちこちの棚を回って情報を集め、机の上で合体（JOIN）させて提供します。
  • 分散の限界: サーバー（棚）を物理的に離れた場所に分散させると、司書が棚の間を移動する距離（通信）が長くなりすぎて、応答速度（レイテンシ）が劇的に悪化します。これが RDS が分散に向かない理由です。

NoSQL：袋詰め（Key-Value / Document）

NoSQL は、分散させることに特化した構造です。

  • 仕組み: 本に関連する情報（著者、レビュー、出版年）を全て 1 つの袋に入れ、「ID: 123」というタグを付けます。
  • 検索時: 「ID: 123 の袋」と言えば、どの棚にあっても一発で袋ごと取得できます。
  • メリット: 袋単位で独立しているため、棚（サーバー）が世界中に分散していても影響がありません。
  • デメリット: 「2020 年以降に出版された本」のように、袋の中身を横断して検索したり結合したりするのは苦手です。

NewSQL：第三の選択肢

NewSQL は、ユーザーからは司書（SQL）に見えるが、裏側の倉庫管理は袋詰め（分散ストレージ）のようにスケーラブルという構造を実現したものです。

3. NewSQL のアーキテクチャ（Aurora の例）

NewSQL（特にクラウドネイティブな Aurora 等のアーキテクチャ）は、「コンピュート（計算）」と「ストレージ（保存）」を分離することでこの問題を解決しています。

以下は、AWS Aurora を例にした内部構造のイメージです。

構成要素

  1. プライマリノード (Primary): 書き込みと読み込みを担当。
  2. リーダーノード (Reader): 読み込み専用。プライマリとストレージを共有。
  3. 分散ストレージ (Distributed Storage): 3 つの AZ（Availability Zone）にまたがり、データを 6 つのコピーとして保持。

3 つの通信フローと ACID の実現

なぜ分散しているのに、RDS のような厳密な整合性（ACID）を保てるのでしょうか？そこには 3 つの通信制御があります。

1. PR → RD（ログ転送：キャッシュ無効化）

プライマリ(PR)でデータが更新された際、変更されたデータそのものではなく、「ストレージのアドレス(xxxx)のデータが変わった」という ログ(Redo Log record) だけをリーダー(RD)に送信します。
リーダーはこのログを受け取ると、自分の持っているキャッシュを更新（または無効化）し、常に最新の状態が見えるように備えます。
※この通信はクライアントへの応答をブロックしないよう非同期で行われます。

2. PR → DS（書き込み：Quorum）

プライマリがストレージ(DS)に書き込む際、6 つあるコピーのうち 4 つから書き込み完了の承認（ACK）が返ってきた時点で「書き込み成功」とみなします。
これにより、特定の AZ やノードがダウンしていても、システム全体として書き込みを継続できます。

3. RD ←→ DS（読み込み：Smart Read）

リーダーがデータを読む際、キャッシュになければストレージからデータを取得します。
ACID 特性を保証するためのモデルとしては、6 つあるコピーのうち 3 つから情報を取得・照合することで、確実に最新データを特定します。
（※実際の動作では、遅延を最小にするために最も近いノードから読み込む最適化が行われます）

まとめ

NewSQL は、RDS の「使いやすさ・整合性」と、NoSQL の「拡張性・可用性」を、アーキテクチャの刷新（コンピュートとストレージの分離、Quorum モデルの採用など）によって実現しています。

  • 大規模サービス: 無限の拡張性が必要だが、決済など厳密な整合性も必須。
  • Aurora / TiDB: SQL インターフェースを維持したまま、裏側で分散を解決。

Discussion