TiDBのアーキテクチャから学ぶ分散システム入門 〜MySQL互換のNewSQLは何を解決するのか〜 / tidb-architecture-study

Transcript

1. TiDBのアーキテクチャから学ぶ分散システム入門 〜MySQL互換のNewSQLは何を解決するのか〜 2026/4/11 PHPカンファレンス小田原2026 / @DPon
2. 自己紹介 • 堂薗 伸樹(どうぞの のぶき) / DPon(でぃーぽん) ◦ X（旧Twitter）: @DPontaro ◦ 🙅 園 🙆 薗 • 所属：スターフェスティバル株式会社 ◦ エンジニア兼マネージャー • 大阪からきました • ゲーム・漫画が好きです • スト6 Cジュリ MR1300 ~ 1400くらい
3. 今日お話すること • NewSQLとは何か、RDBMS, NoSQLとの違い • TiDBのアーキテクチャ概要（TiDB / TiKV / PD） • 分散システムがもたらす強みとユースケース
4. NewSQLとは何か RDBMS, NoSQLとの違い
5. RDBMSとは “Relational Database Management System” の略称 • MySQL, PostgreSQL, Oracle, SQL Serverなど • データをテーブル形式で管理 • データの関係性を定義 • SQLを使用してデータ操作 • データの整合性を強く保証（ACID特性）
6. ACID特性とは 予期せぬ処理の失敗があっても、データの整合性を保つための性質 • Atomicity（原子性）：処理がすべて成功 or すべて失敗 • Consistency（一貫性）：処理の前後で、定義されてる制約条件を満たす • Isolation（独立性）：処理が相互に影響しあわない • Durability（永続性）：処理が完了したら、その結果が失われない
7. RDBMSの課題 書き込みのスケールアウトが難しい • 基本はスケールアップ（マシンのスペックをあげる） • レプリケーションで読み取りのスケールアウトは可能 • 書き込みは水平シャーディングをアプリケーション側で実装する必要がある • 運用が複雑になる
8. NoSQLの特徴 NoSQL: Not Only SQL • Redis, DynamoDB, MongoDBなど • 可用性や分散性を優先（BASE特性） • 高いスケーラビリティ（水平スケーリング前提） • 柔軟なデータ構造（スキーマレス） • データ操作に独自のAPI
9. NewSQL RDBMSとNoSQLの両方の利点を持つデータベース • TiDB, Spanner, CockroachDB, YugabyteDBなど • 高いスケーラビリティ • ACID特性 • SQLインタフェース
10. RDBMS, NoSQL, NewSQLの比較 特徴 RDBMS NoSQL NewSQL データモデル リレーショナル スキーマレス (キーバリュー、ドキュメン トなど) リレーショナル クエリ言語 SQL 独自API SQL スケーラビリティ スケールアップ スケールアウト スケールアウト データの一貫性 ACID特性 BASE特性 ACID特性
11. TiDBのアーキテクチャ概要 （TiDB / TiKV / PD）
12. TiDBとは • PingCAP社が開発した分散SQLデータベース • MySQL互換のプロトコルを提供 • 「チタン（Titan）」のように堅牢なDBという意味で元素記号「Ti」から命名
13. TiDBのアーキテクチャ 引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture/
14. TiDB cluster • コンピューティング層 • MySQL互換のプロトコルを提供 • SQLクエリの解析、最適化を実行 • 最終的に分散実行プランを生成 • データ読み取りリクエストをTiKVノードに送信 • ステートレスで、スケールアウトが容易
15. TiKV • ストレージ層 • データの保存を担当 • 分散キーバリューストア • データは複数のノードに分散され、シャーディング • リージョンという単位でデータを保存 • 各TiKVノードには複数のリージョンが割り当てられる ID 名前 出身 1 佐藤 北海道 2 田中 神奈川 Key Value 1 佐藤, 北海道 2 田中, 青森
16. PD（Placement Driver） • クラスタ全体のメタデータ管理コンポーネント • データの配置管理 • TSO（Timestamp Oracle）の発行 • TiDB -> TiKVへのルーティング • 通常3ノード構成、高可用性
17. TiKVのリージョンとリーダー選挙
18. TiKVのリージョン • データはリージョンという単位で分割されて保存される ◦ usersのID:1〜1000はリージョン1 ◦ usersのID:1001〜2000はリージョン2 • いわゆる水平シャーディング
19. TiKVのリージョン：リーダーとフォロワー • 各リージョンは複数のノードに複製される • リーダーとフォロワーの役割がある • リーダー：書き込みと読み取りのリクエストを処 理 • フォロワー：リーダーからのデータを複製し、 リーダーの障害時に昇格
20. Raftアルゴリズム • 分散合意アルゴリズム • safety（安全性）と liveness（生存性）を保証 • リージョンのリーダー、 フォロワーは1つのRaftグループを形成
21. リーダー選挙：選挙タイムアウト • フォロワーはリーダーから定期的な ハートビートを受け取っている • 一定時間受け取れなくなった場合に、 選挙タイムアウト が発生 • クラスター内で新たにリーダーを決定す るための選挙プロセス が開始
22. リーダー選挙：立候補 • フォロワーが自身を候補者（Candidate)に 昇格 • 候補者のノードはまず自身に投票 • 候補者は他のノードに投票を要求 • 任期番号と最新のログ情報を投票要求に 含める
23. リーダー選挙：投票と昇格 • 他ノードは自身の任期番号とログ情 報を比較 • 適切な場合に投票 • 過半数から投票を獲得した候補者が 新リーダーに昇格 • 新リーダーは全フォロワーにハート ビートを送信し、クラスターの安定性を 回復
24. PD：TSOでの時刻同期
25. 分散システム：時刻ずれの課題 • 分散システムにおいては、各ノードで時刻がずれてるのが当たり前 • 全ノードを都度同期させるのは現実的ではない
26. タイムスタンプの課題：例
27. TSO（Timestamp Oracle） • PDサーバーが唯一のタイムスタンプ発行元 • SELECT, INSERTなど処理のはじめに必ずPDにタイムスタンプを要求 • タイムスタンプはグローバルに一意で、クラスター全体で一貫した時系列を維持 tso = 457658991939683538; 2025-04-28 08:55:05.141000 末尾の141000は、論理時間。同じ時間での並び順 0.001秒あたり、最大26万のTSOを発行可能
28. PDサーバーが停止したらTSOはどうなる？ • PDサーバーが発行したTSOの最大値が記録されている • 停止時Raftアルゴリズムで新しいPDサーバーが選出される • 新しいPDサーバーは停止前の最大TSOを引き継ぎ、タイムスタンプの一意性と順 序を保証
29. 分散システムがもたらす強みとユースケース
30. 分散システムの強み • 高可用性：ノード障害があってもサービス継続 • 耐障害性：データの複製とリーダー選挙で障害に対応 • 高スケーラビリティ：ノード追加で水平スケーリング可能 • 負荷分散：リクエストを複数ノードで処理
31. ユースケース • ライトヘビーなアプリケーション • 柔軟なスケーリングが必要な場合 • 無停止での運用が求められるシステム • （TiDBの場合）既存のMySQLからの移行 • TiDBの事例記事 ◦ https://pingcap.co.jp/case-study/ 逆に向いてない（かも） • シンプルな読み取り中心のシステム • 低レイテンシが求められるリアルタイムアプリケーション
32. まとめ
33. まとめ • NewSQLはRDBMSとNoSQLの利点を兼ね備えたデータベース • 分散システムの強み、高可用性、耐障害性をRaftアルゴリズムで実現 • 分散トランザクションの一貫性をTSOで保証(TiDBの場合) • 水平スケーリングが可能で、ライトヘビーなユースケースなどに適している
34. ご清聴ありがとうございました 登壇は 午前で終わると あと気楽 でぃーぽん