はじめに

12 日のアドベントカレンダーで NewSQL に触れ、13 日・14 日のアドベントカレンダーで TiDB と CockroachDB をそれぞれローカルで構築して実際に触ってみました。
本記事ではこの 2 つの異なる NewSQL データベースを比較し、それぞれの特徴や違いを整理しながらそれぞれのデータベースの特性への理解を深めていきたいと思います。

基本情報の比較

項目	TiDB	CockroachDB
開発元	PingCAP	Cockroach Labs
初版リリース	2017 年	2017 年
ライセンス	Apache 2.0	BSL / CCL
SQL 互換性	MySQL 互換	PostgreSQL 互換
実装言語	Go + Rust（TiKV）	Go

アーキテクチャの違い

TiDB

TiDB は計算層とストレージ層が分離した 3 層構造を採用しています。

コンポーネント	役割
TiDB Server	MySQL プロトコルを公開するステートレスな SQL 層。SQL の解析・最適化・実行を担当
TiKV	分散トランザクショナル Key-Value ストレージ。実際のデータを保存
PD (Placement Driver)	クラスタのメタデータ管理、データスケジューリング、トランザクション ID の割り当て

この設計により、計算リソースとストレージリソースを独立してスケーリングできます。

独立スケーリングのメリット
例えば分析クエリが増えた場合は TiDB Server（計算層）だけを追加し、データ量が増えた場合は TiKV（ストレージ層）だけを追加できます。

CockroachDB

CockroachDB は単一バイナリで動作し、内部的に 5 つのレイヤーで構成されています。

レイヤー	役割
SQL Layer	SQL を Key-Value 操作に変換
Transaction Layer	ACID トランザクションの実装、並行操作の調整
Distribution Layer	データの分散配置、Range の管理
Replication Layer	Raft による複製、リースホルダーの管理
Storage Layer	Pebble エンジンによるディスク書き込み

各ノードが対等（symmetric）に動作し、どのノードにリクエストを送っても処理できます。

分散トランザクションの仕組み

両者とも Two-Phase Commit (2PC) をベースにしていますが、実装方法が異なります。

2PC とは分散システムで複数ノードにまたがるトランザクションを「全部成功」か「全部失敗」にするためのプロトコルです。これにより ACID 特性の原子性を分散環境で保証できます。

TiDB

TiDB は Google Percolator ベースの 2PC を採用しています。

開始
1. PD からタイムスタンプを取得し、スナップショットを固定
Prewrite
1. 全キーに対して競合確認と暫定ロック
Commit
1. プライマリキーで最終確定

v3.0.8 以降は悲観的トランザクションがデフォルトになりました。これは MySQL と同じ動作モデルで、書き込み時に即座にロックを取得することでコミット時の競合を削減します。

CockroachDB

CockroachDB は Write Intent と Parallel Commits という仕組みを採用しています。

Write Intent は書き込み時に作成される暫定値で、MVCC の値とトランザクションレコードへのポインタを含みます。従来の 2PC における「prepare」フェーズに相当します。

Parallel Commits は 2019 年に導入された最適化で、prepare フェーズと commit フェーズを並列化します。これにより、コミット時のレイテンシが 2 ラウンドから 1 ラウンドに短縮されます。

データ配置とレプリケーション

両者とも Raft コンセンサスアルゴリズムを使用してデータを複製します。
Raft コンセンサスアルゴリズムとは分散システムで複数ノードが同じデータを持つことを保証するアルゴリズムです。1 台のリーダーが書き込みを受け付け、フォロワーに複製します。過半数が合意すれば OK とするため、全員の応答を待たずに処理を進められ、一部ノードが落ちてもデータが失われません。

TiDB

TiDB はデータを Region という単位で管理します。

Region はキー空間の連続したセグメント（デフォルト 256 MiB）
各 Region は複数ノードに複製され、Raft グループを形成
PD がクラスタ全体に Region を均等に分散させるスケジューリングを担当

CockroachDB

CockroachDB はデータを Range という単位で管理します。

Range はキー空間の連続したチャンク（デフォルト 64 MiB）
各 Range はデフォルトで 3 ノードに複製
Leaseholder が読み書きリクエストを処理し、Raft でフォロワーに複製

項目	TiDB	CockroachDB
データ単位	Region（256 MiB）	Range（64 MiB）
スケジューラ	PD（専用コンポーネント）	各ノードに分散
コンセンサス	Raft	Raft

ユースケースの違い

TiDB が向いているケース

MySQL からの移行
- MySQL プロトコル互換のため、既存の MySQL アプリケーションを移行しやすい
HTAP ワークロード
- TiFlash により、OLTP と OLAP を単一プラットフォームで処理可能
読み取り重視のワークロード
- 読み取り集約的なワークロードや分析クエリに強い
計算・ストレージの独立スケーリング
- 計算リソースとストレージリソースの需要が不均等な場合

CockroachDB が向いているケース

PostgreSQL からの移行
- PostgreSQL 互換のため、既存のツールやライブラリを利用可能
書き込み重視のワークロード
- 書き込み集約的なワークロードに向いている
シンプルな運用
- 単一バイナリで動作し、「ノードを追加する」だけのシンプルなスケーリングモデル
グローバル分散
- 地理的に分散したデプロイメントでの利用

まとめ

TiDB と CockroachDB はどちらも 2017 年にリリースされた NewSQL データベースで、Raft を使った分散アーキテクチャを持つ
TiDB は MySQL 互換で計算・ストレージ分離型、CockroachDB は PostgreSQL 互換で単一バイナリ型という違いがある
TiDB は HTAP や読み取り重視のワークロードに、CockroachDB は書き込み重視やシンプルな運用を求める場合に向いている
どちらが優れているかは一概には言えず、ワークロードや運用要件に応じて選択することが重要

参考