2025年現在のNewSQL (最強DB講義 #36 発表資料)

© 2025 NTT DATA Corporation
2025年現在のNewSQL
2025/4/23
株式会社NTTデータ
小林隆浩

© 2025 NTT DATA Corporation 3
アジェンダ
1. NewSQLの（個人的な）定義
2. データベースの分類
3. NewSQLの現在の状況
4. コンポーネント詳解
① シャーディング
② ストレージエンジン
③ Raft
④ トランザクション
5. まとめ

1.
NewSQLの（個人的な）定義

（言葉遊び）もともとNewSQLだったもの達
⚫ 「NewSQL」という言葉に違和感を覚える人は多い。
⚫ 「いつまでNewなのか」「何に対してNewなのか」「NewSQLより新しいものは？」
⚫ 時は遡って2011年、その時のNewSQLは今とは違うものだった。
• 分析系でトレンドだったShared-Nothing、さらにインメモリ
• VoltDBやNuoDB
⚫ クラウドでプラットフォームに最適化されたRDBのクラスタが動けば、Newだった
• Amazon RDSやAuroraを指すケースも

「2020年現在のNewSQL」
⚫ Google Cloud Spannerの登場後に現れた、新しいRDBの特徴を以下のように定義した。
✓ 強い整合性を持ち、
✓ ACIDトランザクションをサポートする、
✓ (地球規模の)分散型のSQLデータベース
⚫ 基本的にはNoSQLのカウンターワード。
⚫ 2025年現在でも特徴は大きく変わっていないが、ユーザが注目するポイントは少しずつ変
わってきている。
✓ 書き込みヘビーに対するスケーラビリティは当然重要
✓ (ほぼ)ゼロダウンタイム、DBでもローリングアップデートがクラウドユーザに訴求した
✓ 地理分散は日本ではあまり必要なかった
* https://qiita.com/tzkoba/items/5316c6eac66510233115

2.
データベースの分類

データベースの分類
⚫ クラウド上でのマネージドDB(DBaaS)の利用は一般的になった。
⚫ その中でRDBの構成（提供形態）も変化しており、おおよそ以下の6つの種類がある。
# 分類代表的なDB・サービス
1 単一インスタンス -
2 レプリケーション • Amazon RDS
• Google Cloud SQL
3 双方向レプリケーションによるマルチプライマリ • EDB PostgreSQL Distributed(PGD)
• pgactive(RDS for PostgreSQL)
4 ログ適用可能なストレージを用いたDB
• Amazon Aurora
• Google Cloud AlloyDB
• Neon
5 マネージドシャーディング
• Citus
• Vitess
• Amazon Aurora PostgreSQL Limitless Database
6 分散KVS＋SQL
• TiDB
• YugabyteDB
• CockroachDB

単一インスタンス
⚫ 可用性が低く、スケールアップのみでスケーラビリティの限界値は低い。
⚫ とにかくシンプルな構成。
⚫ 共有ストレージの利用時も単一インスタンス(アクティブ‐スタンバイ)だが、可用性は
向上する。
PostgreSQL PostgreSQL
• クラウドで仮想化レベルのリカバリーが有効であれば、
意外とこれで何とかなることも。
• 仮想化レイヤで1つの大きな仮想マシンが作れれば、
スケールアップも出来る。
（かつてそうした製品もあった）

レプリケーション（プライマリ-スタンバイ）
⚫ スタンバイサーバを構成して可用性を向上。
• 同期レプリケーション：RPO=0
• 非同期レプリケーション：RPOは数秒（距離による）
• フェイルオーバが発生するため、RTOは1‐3分程度
⚫ 読み取りのスケーラビリティが向上可能だが、書き込みは向上しない。
プライマリスタンバイ
書き込み読み取り読み取り
• プライマリで読み/書き、スタンバイでは読
み取りのみを行う。
• スタンバイは1台ではなく、複数台で構成し
ても良い。

双方向レプリケーションによるマルチプライマリ
⚫ アクティブ-アクティブ構成でダウンタイムを短縮。
⚫ 同じデータに対する異なるサーバからの書き込みで衝突が発生し、別途解決が必要。
PostgreSQL
SQL SQL
SQL
(非同期)論理レプリケーション
• サーバ間で非同期の論理レプリケーションが
行われる。
• どのサーバからでも、常時書き込み/読み取
りが可能だが、競合や読み取りのラグが
発生する。
• 競合を回避しつつ書き込みを分散させると、
水平スケールしない。
V=1
V=2
衝突

（参考）書き込みが衝突した際の解決方法
⚫ 行単位または列単位(オプション)で競合を検出。
⚫ CRDTs (Conflict-free replicated data types)を使うことも可能。
⚫ 検出された競合のタイプ別に解決方法を設定できる。
⚫ 以下はEDB Postgres Distributedで検出される競合とその解決方法の例。
検出される競合の種類デフォルトの競合解決説明
insert_exists update_if_newer insertでキー競合を検知。新しいレコードで更新
update_differing update_if_newer update時のキー変更を検知。新しいレコードで更新
update_origin_change update_if_newer update時に別ノードで更新を検知。新しいレコードで更新
update_missing insert_or_skip 存在しない行の更新を検知。新しい行のinsertまたはスキップ
update_recently_deleted skip 削除行の更新を検知。スキップする
update_pkey_exists update_if_newer update時にキー重複を検知。新しいレコードで更新
delete_missing skip 存在しない行の削除を検知。スキップする
…

ログ適用可能なストレージを用いたDB
⚫ 従来のRDBの構成を見直して、ComputeとStorageを分離。
• クラウドプラットフォームに最適な形で再構成されたデータベース。
• ストレージへWALを送信し、WAL適用は非同期でストレージ内で行われる。
⇒「ログ適用可能なストレージ」が採用されている。
• リードレプリカが増やしやすい、クローンがしやすいなど運用のメリットが大きい。
⚫ 読み取りスケーラビリティはあるが、ラグは発生する。
⚫ 書き込みのスケーラビリティは限定的。
⚫ 通常は最大ストレージの制限(Auroraは最大128TB)がある。

（参考）AlloyDBの構成
⚫ PostgreSQL互換のDBaaSでAuroraに近い構成。
⚫ DBに最適化されたIntelligentなストレージが特徴で、 WALを受け取って永続化している。
⚫ 更にカラムナエンジンや高速キャッシュの機能も搭載。
Intelligent Database Storage Engine
プライマリ F/Oレプリカリードプール
分散ファイルシステム（Colossus）
書込時は
WALのみを送信
ストレージ側で
WALを処理して、
耐久性の高い
ストレージへ書込み

マネージドシャーディング
⚫ テーブルをシャードに分割して、複数サーバに配置する構成。
• サーバを増やすことで、読み取り/書き込みのスケーラビリティが向上。
• 大規模アプリケーションで採用されているケースがあるが、一般的な構成とは言えない。
⚫ 過去からいくつかの課題が存在する。
• クエリの振り分けや集約を行うコーディネータがボトルネックとなりがち。
• マルチシャードの処理が遅く、2PCが必要とされる。
• 上記を回避するためにデータモデリングとサーバ構成が密結合になりがち。
⚫ 近年GAとなったAurora Limitless Databaseが起爆剤となるか？

（参考）Aurora Limitless Database
⚫ Router/Shardの2種のノードを用いて、2層+Auroraストレージからなる水平スケール可能な
分散SQLデータベース（PostgreSQL互換）を実現している。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/limitless-architecture.html
• Endpointは1つでクライアントからは1つの大きなDBとして見える。
• Routerはメタデータを保持し、SQLを解析後に必要なコマンドを
Shardに送信する。データの集約も行い、クライアントに応答する。
• Routerは複数Shardに跨る分散トランザクションを管理する。
• ShardはAurora PostgreSQLのDBインスタンスそのもの。異なる
Shardには異なるデータセットが格納される。

（参考）AWSのPostgreSQL互換DBにおける位置づけ
⚫ RDS、Aurora、そしてマネージドシャーディングとしてLimitless DBがラインアップされた。
⚫ 更にマルチリージョンでマルチプライマリが可能なDSQLが登場。
プライマリスタンバイプライマリリードレプリカ
RDS
（単一インスタンス）
*リードレプリカも可
Limitless Database
（マネージドシャーディング）
トランザクションルータ
(コーディネータ)
...
シャード
Aurora
（ログ適用可能なストレージ）
ストレージレイヤの
同期レプリケーション
クラウドに最適化されたストレージを利用し、
基礎性能や可用性を向上

分散KVS＋SQL
⚫ TiDBやYugabyteDB、CockroachDBなどNewSQLが採用しているアーキテクチャ。
⚫ シャーディングで水平スケールを実現、Raft(合意プロトコル)でレプリケーションを行う。
クエリエンジン
KVS KVS KVS
クエリエンジン • SQLを扱うComputeレイヤはステートレス
• Storageレイヤは分散KVSで、トランザクショ
ンやレプリケーションを担当する。
• コンポーネントが多く、レイテンシーが劣化
しやすい。スループットは向上する。
Compute
Storage
SQL SQL
Key-Value Key-Value

3.
NewSQLの現在の状況

Google Cloud Spanner
⚫ 2012年「Spanner: Google’s Globally Distributed Database」の論文が発表されている。
⚫ 2025年現在は「実質的に無制限のスケーリングを備えた、常時稼働のデータベース」
⚫ マルチI/Fなデータベースへ進化を続けている（Graph、Cassandra対応などもプレビュー中）。
Span Server
Split
Compute
Storage
(Colossus)
Google SQL PostgreSQL
Span Server Span Server
Split Split Split Split Split Split Split Split
• データをSplitに分割。
• Span Serverは一定範囲のSplitを管理。
• マルチSplitのトランザクションにはPaxosを
用いる。
• 分散ストレージとしてColossusが利用されて
いる（KVSではない）。
• マルチリージョン対応が可能。
Region① Region② Region③

Google Cloud Spannerの注目すべきリリース
 デュアルリージョン
• 通常は3地域が必要なマルチリージョンを、
2リージョンで構成。日本(東阪)で最適。
• RF=6、Paxosの合意には4ノードが必要。
• RPO=0だがRTO≠0、障害時は手動でローカル
リージョンへ再構成。
 Data Boost
• OLTPとは別に分析用のComputeリソース。
Colossusは共有する。
* https://cloud.google.com/blog/ja/products/databases/spanner-dual-region-
configurations-for-data-residency
* https://cloud.google.com/blog/ja/products/databases/understanding-cloud-spanner-
data-boost?hl=en

Aurora DSQL
⚫ AWSが公開した（現在プレビュー）のマネージドDB。
⚫ 「常に利用可能なアプリケーション向けの最速のサーバーレス分散SQLデータベース」
⚫ PostgreSQL互換としているが、通常Auroraと比較して互換性は低い。
Journal
Query
Processor
SQL
Query
Processor
Region① Region② Region③
Adjudicator
Storage
Adjudicator
Storage
Journal
SQL
Read
Write
• マルチリージョンでマルチプライマリ。
• 楽観的同時実行制御(OCC)が行われ、コミッ
ト時にAdjudicatorが他リージョンで更新が
ないかを確認して調停。
• 問題なければ、Journalにログを書き出して
クライアントへ応答。
• JournalからStorageへの適用は非同期。

TiDB
⚫ PingCAPが開発している、MySQL互換のNewSQL。
⚫ 書き込みヘビーなワークロードの移行先として、国内でも注目される。
• 下記のコンポーネントから構成される。
• PD
• メタデータ管理やグローバルタイムスタンプの発行
• TiDB
• ステートレスなクエリエンジン
• TiKV
• 行ストア用途の分散KVS
• ACIDなトランザクションに対応
• TiFlash
• 列ストア用途のストレージエンジン
• 同期更新ではないが、読み取り時に一貫性を確保
* https://docs.pingcap.com/ja/tidbcloud/tidb-architecture/

TiDBの注目すべきリリース
 TiProxy
• TiDBへの接続を分散し、プーリングする。
 リソース制御
• TiDBクラスターにリソースグループを設定し、グ
ループごとに利用可能なリソース量を設定。
• マルチテナントの環境で、特定グループにリソー
スが占有されるような状況を防止。
* https://docs.pingcap.com/ja/tidb/stable/tiproxy-overview/
OLTP バッチ向け分析
リソース
グループ
リソース
ユーザ
①
ユーザ
②
バッチ
PGM
帳票
②
帳票
①
CPU IO

YugabyteDB
⚫ Yugabyte社が開発しているNewSQL。PostgreSQL/Cassandra互換のインターフェースを持つ。
⚫ PostgreSQLとの互換性はかなり高く、スケールアウト構成への移行先として魅力的。
* https://github.com/yugabyte/yugabyte-db/blob/master/README.md
• ユーザデータを扱うyb-
tseverと、メタデータを扱う
yb-masterが各サーバに配置
される。

YugabyteDBの注目すべきリリース
 コネクションマネージャ
• ノード内のコネクションをプーリング。
• クライアントの接続には専用ドライバを利用。
 xCluster
• クラスター間の非同期レプリケーション
• 災害対応での利用を想定。
* https://docs.yugabyte.com/preview/explore/going-beyond-sql/connection-mgr-ysql/ * https://docs.yugabyte.com/preview/architecture/docdb-replication/async-
replication/#active-active-single-master

CockroachDB
⚫ PostgreSQL互換のNewSQL、名前のインパクトが大きい。
⚫ グローバルレベルの地理分散機能に強みを持つ。
* https://github.com/cockroachdb/cockroach/blob/master/docs/design.md
• クエリエンジンと分散KVSがそれぞれのノード
に配置される。
• YugabyteDBに近い構成を持つ。
• PostgreSQLバージョンへの追従は比較的遅く、
機能別の対応に方針を変えたように見える。

CockroachDBの注目すべきリリース
 物理クラスターレプリケーション(PCR)
• アクティブ‐スタンバイでPostgreSQLの
Streaming Replicationに近い。
 論理データレプリケーション(LDR)
• アクティブ‐アクティブも可能で、PostgreSQLの
Logical Replicationに近い。
* https://www.cockroachlabs.com/blog/isaster-recovery-cockroachdb-surviving-failures/

（参考）NewSQLでクラスター間レプリケーションが必要？
⚫ NewSQLは地理分散に向くのは事実だが、障害時の構成を検討すると色々と課題がある。
⚫ リージョン障害に耐えるために3リージョンが必要で、それぞれに配置するサーバ数も性能に
大きく影響する。
⚫ 詳しく知りたい方は「マルチクラウドデータベースの教科書」がおすすめ。
Region① Region② Region① Region② Region③
【2リージョンのストレッチクラスター】【3リージョンのストレッチクラスター】
Region① Region②
※①の障害でDB継続不可 ※①の障害でもDB継続
【2リージョンのクラスター間レプリケーション】
※①の障害でも切り替えてDB継続

4.
コンポーネントの詳解

NewSQLのコンポーネント
⚫ NewSQLのアーキテクチャを①-④のコンポーネントに分解して解説する。
クエリエンジン
分散Txn Mgr
Compute
Storage
Shard1 Shard2 Shard3
クエリエンジンクエリエンジン
分散Txn Mgr 分散Txn Mgr
①ストレージエンジン
書き込み重視でデータを格納。
②シャーディング
スケーリングのためにデータを分散。
③Raft
高可用性のためにデータを冗長化。
④トランザクション
データをどのように見せるか/更新するか。

① ストレージエンジン
⚫ ストレージエンジン：物理的にデータを格納する役割を持つ。
⚫ 評価するポイントとして、Read/Write/Spaceの効率性がある。
• B-Tree ：従来RDBで利用、コピーが1つでReadが得意。
書き込みはIn-place、Write Amplificationが起きやすく効率は悪い。
更新用にブロックの空きを保持する必要があり、Space効率も悪くなりがち。
⚫ NewSQLでは、書き込みを重視してLog-Structured Merge Tree(LSM-Tree)が使われる。
• LSM-Tree：追記型のデータ構造。Writeがシーケンシャルになり効率的。
Readは複数バージョンから調停するので効率は悪い。
圧縮プロセスもあり、Space効率は高くなる。
• 追記型の書き込みはSSDと相性が良い。In-placeではSSDの劣化が早くなりがち。

（参考）ストレージエンジンと媒体の相性について
「Cloud Native時代のデータベース」
: https://speakerdeck.com/tzkoba/cloud-nativeshi-dai-falsedetabesu?slide=12

①-1 LSM-Treeの実装：RocksDB
⚫ Facebookが開発した組み込みのKey-Valueストア。
* https://github.com/facebook/rocksdb/wiki/RocksDB-Overview
• LSM-Treeでは、まずメモリ上の構造
(Memtable)にデータが書き込まれる。
• RocksDBではオプションでMemtableの書き込
み時にWALを書いて、リカバリに利用できる。
• Memtableが一杯になると、ディスク上の
SST(Sorted String Table)ファイルへフラッシュ
される。この際はシーケンシャルな書き込み。
• SSTファイルはCompactionプロセスで、マー
ジと圧縮が行われる。この際、不要データも
削除される。

（参考）具体的なRocksDBの利用例
⚫ TiDBではストレージエンジンとして、RocksDBと独自エンジンの両方が利用されている。
• RocksDB ：ユーザデータの書き込み先（Raft Logの適用先）
RocksDBのインスタンスを複数にする、Partitioned Raft KVの機能を開発中。
• Raft-engine：Raft Logの書込み先となる独自エンジン(過去にはRocksDBを利用)。
ログ書込みに最適化されており、RocksDBから不要な機能を削除。
Raft Log ユーザデータ
Raft-
engine
RocksDB
TiKVノード
Raft-
engine
RocksDB
TiKVノード
Raft-
engine
RocksDB
TiKVノード
レプリケーション

（参考）RocksDBでIOを削減する工夫
⚫ RocksDBでは1レコードのサイズが大きくなると、CompactionプロセスでIOが増大する。
⚫ TiKVでは、大きなレコードはSSTファイル外で管理するTitanという機能が実装されている。
• Titanでは、Memtableのフラッシュまでは通常の
RocksDBで取り扱う。
• Compactionのプロセスで閾値を超えたレコードか
ら、値を分離してBlobに格納。
• RocksDBとの互換性を重視した機能だが、Readと
Spaceの効率が劣化するため、利用には注意が必要。
* https://docs.pingcap.com/tidb/v8.1/titan-overview/

①-2 LSM-Treeの実装：DocDB
⚫ YugabyteDB内で使われている、RocksDBベースのストレージエンジン。
⚫ DocDBではクエリエンジンからPush Downされた処理に対応し、ストレージエンジン側で
効率的なスキャンやフィルタリングを行う。
• 例）Seq Scan時のリモートフィルタなど
• DocDBでは、シャード(tablet)ごとにRocksDBのイン
スタンスを管理する構成。
• この構成により、シャードをノード間で移動させた
り、テーブル削除する際の処理が効率化される。
• Raftで書き込みの永続化が保証されるため、
RocksDBのWAL機能はOffにして効率化している。

② シャーディング
⚫ テーブルをシャードに分割して、複数サーバに配置する。
⚫ 以下の観点で各DBのシャードに関する考え方が概観できる。
• どんな方法（アルゴリズム）でシャーディングを行うか。
• マルチシャードの処理を効率化できるか。
• システム規模や負荷に応じて、自動シャーディングが可能か。
DB名シャード名アルゴリズムマルチシャードサイズ/シャード自動シャーディング
Spanner Split レンジインターリーブ 4GB サイズ/負荷、結合/分割
TiDB Region レンジ 96MB サイズ/負荷、結合/分割
YugabyteDB Tablet レンジ/ハッシュコロケーション 128MB/1GB/100GB サイズ、分割
CockroachDB Range レンジ 128-512MB サイズ/負荷、結合/分割

②-1 2種類のシャーディング
 レンジ・シャーディング
• 範囲クエリに強い。
• HotSpotが発生しやすい。
• 格納時にハッシュ化することは容易。
 ハッシュ・シャーディング
• 均等分散するため、HotSpotが発生しづらい。
• 範囲クエリがマルチシャードとなりがち。
• レンジ化はできない。
* https://www.yugabyte.com/tech/database-sharding/

②-2 自動シャーディング
⚫ NewSQLでは、スケーリングに関わる重要な技術となっている。
⚫ 「サイズ」ベース
• シャードのサイズが大きくなると、自動で分割
• シャードのサイズが小さい場合、自動で結合
⚫ 「負荷」ベース
• シャードでQPSやCPU利用量・トラフィック等が高くなると、自動で分割
• シャードで一定期間の利用量が少ないと、自動で結合
⚫ 自動シャーディングの注意点
• パフォーマンス・性能特性が予期しないタイミングで変わる可能性がある
• 事前に負荷増が予想できる場合は、手動シャード分割やウォームアップが必要になる

②-3 インターリーブ
⚫ Spannerでサポートされている、関連テーブルを同一シャードで扱う設定。
⚫ 良くJOINされるテーブル間で、同じキーのレコードが同じSplitに配置されるので、マルチ
シャードのクエリで通信量を削減できる。
⚫ 現在ではSpanner以外で実装しているNewSQLはない。
親テーブル
pkey colA colB
001 AAA XXX
002 BBB YYY
fkey key1 colQ
001 100 nnnn
子テーブル
002 200 mmmm
002 300 oooo
【インターリーブの論理構造】
Split(1)
親テーブル
pkey colA colB
001 AAA XXX
fkey key1 colQ
001 100 nnnn
子テーブル
Split(2)
002 BBB YYY
002 200 mmmm
002 300 oooo
【インターリーブによるSplitへの配置】

③ Raft
⚫ NewSQLでは可用性を高めるために、分割されたシャードをRaft(合意プロトコル)を
用いてレプリケーションしている。
⚫ Raftには各ノードの役割としてLeader/Follower/Candidateがあり、以下2つの機能を持つ。
⚫ Leader選出
• 1つの期間(Term)で、1人のLeaderが選出される。
• 他の参加者はFollowerになる。
• 2人以上がLeaderに選ばれることはなく、データの破損が起きない。
⚫ ログ複製
• 合意済みのデータは、Leaderが変更されても巻き戻ることはない。
• ⇒コミットされたデータは、必要なノード数を満たした上で必ず永続化される。
* https://raft.github.io

③-1 Leader選出
⚫ RaftはLeaderの役割が大きく、レプリケーションや読み取りもLeaderが主導する。
⚫ Leaderはハートビートを送信し続けて、自身の状態をFollowerに伝える。
⚫ ハートビートが途絶えると、次のTermのLeader選出が以下の流れで行われる。
Leader
Follower
Follower
Candidate
（選出フェーズ）
Term(2)
Term(1)
Leader
①
②
③
④
Follower
Leader
（通常フェーズ）
（Leader選出の流れ）
① 前TermのLeaderで障害、ハートビートが停止。
② タイムアウトによりFollowerがCandidateとなり、
次のTermで選出フェーズを開始。
③ Candidateは自身に投票後、他ノードへ投票
リクエストを送る。
④ 過半数の投票を得ると、CandidateがLeaderに
なる。

③-2 何のためのログ複製？
⚫ 「同じ開始状態から、同じ順序でコマンドを与えれば、同じ状態に達する」
⇒ State Machine Replication
⚫ コマンド＝Raftのログであり、同じ順序でログを適用し続けることで、各ノードのデータを
同じ状態に保つ。
ソース
v=10
v=20
v=100
v=5
ターゲット2
v=10
v=20
ターゲット1
v=10
v=20
v=100
v=5
• ログを複製し、ソースと同じ順序でター
ゲットに適用。
• 課題が2つ発生する。
• コマンド順序は入れ替わらないか？
• 必要な数だけ確実に複製されたか？
• これを合意により保証するのがRaft。

③-3 ログ複製
⚫ Raftでは安定したLeader-Follower構成を前提にログ複製が行われる。
⚫ Leaderが出来るのはログの追記のみで、並び替えや削除は出来ない。
⚫ 以下の流れで複製されたログは、次のTermのLeaderにも必ず含まれることが保証される。
Leader a
v=10
Follower1
v=10
Follower1
v=10
②
①
②
③
④
⑤
（ログ複製の流れ）
① 更新リクエストを受信して、Leaderのログ
に追記。まだコミットはしない。
② ログ複製後にFollowerへ送信、応答を待つ。
③ Followerの過半数から応答を受けて、
Leaderはログをコミットする。
④ 更新リクエストの完了を通知。
⑤ コミット済みログを適用。

③-4 マルチRaft
⚫ NewSQLでは単一ではなく、複数のRaft Groupを用いてスケーラビリティを確保する。
⚫ Raft GroupごとにLeaderを分散配置することで、マルチプライマリの構成を実現している。
⚫ Etcdのような単一Raft GroupのDBも存在する。
Shard1
Shard2
Shard3
Raft Group#1
Raft Group#2
Raft Group#3
• 基本的に1Shard=1Raft Group。
• 但し、Raft Groupごとにハートビートな
どの管理用通信も増えるため、リソース
消費の増加に繋がる。
• Shardを増やしつつ、Raft関連の通信を最
適化する工夫が各DBで検討されている。

③-5 Raftでの読み取り最適化 - Lease Read -
⚫ Raftで強い整合性の読み取り(最新データの読み取り)はLeaderの役割、かつコストが高い。
⚫ 効率化のために、NewSQLではLease Readという仕組みが取り入れられている。
Leader
Follower
Follower
①Read
②Leaderの確認
(合意)
③Reply
Leader
Follower
Follower
①Read
Leaseの期限内であれば、
Leaderの確認を省略
②Reply
【通常のRaft Log Read】【Lease Read】
Lease
(期限付き)
• Leaseは書き込み可能な1ノードのみが持つ。
• Leaseの期限は通常時は更新され、Followerに
も通知される。
• FollowerはLeaderに昇格しても、前Leaseの
期限内は新Leaseの取得が出来ない。
• 期限後に新LeaderがLeaseを取得、書き込み
が可能となる。
• 障害時に書き込み不可となる時間があるが、
通常の読み取りが高速になる。

③-5 Raftでの読み取り最適化 - Follower Read -
⚫ Raftでは基本的にLeaderが読み取りを行うが、古い(Stale)データでも良ければ、Followerが読み
取りを行うこともできる。
⚫ 読み取り負荷分散のために、Follower ReadやStale Readと呼ばれる仕組みが実現されている。
Leader
Follower
Follower
過去データを
問い合わせ
Follower Read
Read/Lease Read
最新ログが送信/適用されて
いない可能性がある
• 過去のタイムスタンプでFollowerに読み取りを行う。
• Follower Readの利点として、アプリケーションの近傍
(AZやリージョン)からデータを読み取れる点がある。
• また、Read-Onlyのトランザクションとなり、更新系
トランザクションに影響を与えない。
• 但し、TiDBのFollower Readは仕組みが異なり、強い整合性
の読み取りを提供する(Stale Readも提供されている)。

Proposer
③-6 RaftとPaxosの違い
⚫ 分散SQLデータベースでは、RaftではなくPaxosを用いて実装されているものも存在する。
⚫ 両プロトコルの大きな違いはコンポーネントを分割できるかどうか。
⚫ OSSのNeonではMultiPaxosを採用、ログ複製とデータ格納のノードを分離した構成を取る。
【Raftの状態遷移】【Neonのノード構成とMutilPaxosのマッピング】
* https://raft.github.io/raft.pdf
Distinguished
Proposer
Accpetor
Proposer Accpetor
Accpetor
Learner
Proposer
Distinguished
Proposer
Accpetor
Learner
* https://neon.tech/docs/introduction/architecture-overview
をベースに追記

④ トランザクション
⚫ NewSQLは、Serializable等の高いトランザクション分離レベルを前提に開発されてきた。
⚫ 最近では互換性向上のために、Read Committedの採用が増えてきている。
DB名 Read Committed Repetable Read Serializable
Spanner (preview)
Aurora DSQL
TiDB
YugabyteDB (early access) Snapshot
CockroachDB
⚫ 但し、同じ名称の分離レベルでもDBごとに実装が少しずつ異なっている場合がある。
• CockroachDBのRCはPostgreSQLの改善版になっていて、動作が異なる。
• TiDBのRCはPCCで利用可能。ギャップロックがない等、MySQLと異なる。

④-1 Spannerのマルチシャード・トランザクション
⚫ Spannerのマルチシャード（分散）トランザクションは以下の特徴を持つ。
• トランザクションログのレプリケーションのためにPaxosを使用
• マルチシャードのトランザクションに2PCを使用
• トランザクションの順序付けにTrueTime API(原子時計を用いた高精度な時刻同期)を使用
「詳説データベース」
【ロック型読み取り書き込みトランザクションの流れ】
1. 必要なロックを取得し、commit_tsを取得
2. PaxosでProposalを送り、過半数の応答を待つ
3. commit waitを行う
※この際の待ち時間がTrueTimeに依存
4. Paxosでコミット完了を通知する
5. ロックを解除する

④-2 TiDBの楽観的／悲観的同時実行制御
⚫ TiDBは、悲観的同時実行制御(PCC)と楽観的同時実行制御(OCC)を切り替え可能。
⚫ TiDBでは、トランザクションの順序付けにPDが発行するTSO(TimeStamp Oracle)を利用する。
【TiDBのPCCの流れ】
begin
get start_ts
read with start_ts
get for_update_ts
acquire locks
commit
prewrite with start_ts
get commit_ts
commit with commit_ts
success
TiDB PD
2PC
TiKV
【TiDBのOCCの流れ】
begin
get start_ts
read with start_ts
commit
prewrite with start_ts
get commit_ts
commit with commit_ts
success/abort
TiDB PD
2PC
TiKV
acquire locks
write in cache
write in cache
release locks release locks

④-3 YugabyteDBのマルチシャードトランザクション
⚫ YugabyteDBでは、Provisional Recordを利用してトランザクションの処理を進めている。
⚫ トランザクションのステータスもRaftで複製されるレコードとして管理される。
Txn Status
Tablet
Txn Mgr User Data
Tablet_1
User Data
Tablet_2
write request
commit
success/abort
create status record
write provisional record for Tablet_1
write provisional record for Tablet_2
change status to commit
async apply provisional record
async apply provisional record

5.
まとめ

「2025年現在のNewSQL」
⚫ NewSQLに分類されるデータベースは一層進化し、成熟度を増している。
⚫ 書き込みヘビーだったり、ダウンタイムゼロを求めるワークロードも増加している。
⚫ 今日説明したように、NewSQLで使われている技術は新しいものばかりではなく、
以前からデータベースで利用されていた技術の組み合わせで成り立っている。
（例：レプリケーション、シャーディング、2PC）
⚫ 今後、日本最大クラスでなくても、小規模にスタートするサービスでNewSQLを利用する
事例は増えていくと考えられる。
⚫ その際に、今までの技術と連続性を意識しながら比較を行い、採用を検討する必要がある。

記載されている会社名、商品名、又はサービス名は、
各社の登録商標又は商標です。

2025年現在のNewSQL (最強DB講義 #36 発表資料)

Recommended

More Related Content

What's hot (20)

Similar to 2025年現在のNewSQL (最強DB講義 #36 発表資料) (20)

More from NTT DATA Technology & Innovation (20)

2025年現在のNewSQL (最強DB講義 #36 発表資料)