TiDBのアーキテクチャーをざっくりと眺めてみる

これは、なにをしたくて書いたもの？

この前、MySQL互換の分散データベースであるTiDBを少し触ってみました。

Ubuntu Linux 22.04 LTSに、MySQL互換の分散データベースTiDBをインストールして（ローカルでクラスターを立ち上げて）みる - CLOVER🍀

TiDBでHTAPを試してみる - CLOVER🍀

TiUpというツールを使うことで簡単に立ち上げることができるのですが、いろいろとコンポーネントがインストールされていたようなので
その役割をドキュメントをざっくりと眺めて確認したいと思います。

対象は、TiDB 7.5です。

アーキテクチャー

まずは、アーキテクチャーに関するドキュメントを見るのがよいのかなと思います。

TiDB Architecture | PingCAP Docs

こちらが全体像のようです。

各コンポーネントを概要はこんな感じみたいです。

TiDBサーバー
- MySQL プロトコルのエンドポイントを外部に公開するステートレスなSQLレイヤー
- SQLリクエストを受信してSQL文の解析と最適化を行い、分散実行プランを生成する
- 水平スケーリングが可能で、LVS（Linux Virtual Server）、HAProxyなどの負荷分散コンポーネントを通じて外部にインターフェースを提供可能
- データは保存せずコンピューティングとSQL分析のみが役割
PDサーバー（Placement Driver server）
- クラスター全体のメタデータ管理コンポーネント
- 各TiKVノードのリアルタイムなデータ分散メタデータとTiDBクラスター全体のトポロジーを保存する
- TiDBダッシュボードを提供する
- 分散トランザクションにトランザクションIDを割り当てる
- TiKVノードから報告されるデータ分散状態に従って特定のTiKVノードにデータスケジューリングを行う、TiDBクラスター全体の「頭脳」
- 少なくとも3ノードで構成され、高可用性を備える
- 奇数でのノード構成を推奨
ストレージサーバー
- TiKVサーバー
  - データの保存を担当する
  - 分散トランザクションをサポートするキーバリューストレージエンジン
  - リージョンと呼ばれる単位を基本にデータを保存する
    - 各リージョンにはStartKeyからEndKeyまでキーの範囲でデータが保存される。範囲は左閉半開区間（left-closed and right-open interval）になっていて、終端キーは含まない
  - 各TiKVノードには複数のリージョンを保持する
  - TiKV APIにより、キーと値のペアのレベルで分散トランザクションをネイティブにサポートし、デフォルトでスナップショット分離レベルを提供する
  - TiDBサーバーはSQL文を処理した後に、SQLの実行プランをTiKV APIの呼び出しに変換する
  - データは複数のレプリカ（デフォルトで3つ）を持ち自動的に維持するため、ネイティブで高可用性を備え自動フェイルオーバーが可能
- TiFlashサーバー
  - 特殊なタイプのストレージサーバーで、TiKVノードとは異なり列ごとにデータを保存する
  - 主に分析処理を高速化するように設計されている

QuickStartからなんとなくTiKVサーバーおよびTiFlashサーバーの役割はわかっていたのですが、特にPDサーバーが不明だったのでこれで
立ち位置がよくわかりました。

他のページにもう少しこれらのコンポーネントなどについて書かれているので、見てみましょう。

ストレージ

ストレージのページでは、主に以下のことが書かれています。

キーバリューペア
ローカルストレージ（RocksDB）
Raftプロトコル
リージョン
MVCC
分散ACIDトランザクション

TiDB Storage | PingCAP Docs

ざっくり、こんな感じのようです。

キーバリューペア
- TiKVはキーバリューのモデルでデータを保存する
  - SQLとの関連についてはこのページでは説明しない
ローカルストレージ（RocksDB）
- TiKVではデータストレージとしてRocksDBを使用している
- RocksDBを単一のキーバリューMapとして使っている
Raftプロトコル
- TiKVではデータのレプリケーションスキームにRaftアルゴリズムを採用している
- 以下の3つが重要な概念
  - リーダー選出
  - メンバーシップの変更（レプリカの追加、レプリカの削除、リーダーへの転送など）
  - ログのレプリケーション
- TiKVではRaftを使用してデータレプリケーションを実行し、各データの変更はRaftログとして記録する
- Raftログレプリケーションを通じて、データはRaftグループの複数のノードに安全にレプリケーションされる
  - 大半のノードへのデータのレプリケーションには、書き込みが成功すればよい
- 障害が発生しても、TiKVはRaftプロトコルにより自動的にレプリカを完成させることができ、アプリケーションには影響を与えない
リージョン
- TiKVでは[StartKey, EndKey)の連続するキーセグメントに分割された範囲をリージョンと呼んでいる
- 各リージョンのデフォルトのサイズは96MB（変更可能）
- 単一のリージョンに対する考え方
  - 各リージョンのデータは1ノードにのみ保存される
  - TiDBはクラスター内の全ノードのリージョンをできるだけ均等にしようとする（PDサーバーの役割）
  - ストレージは水平方向にスケーリングされ、新しく追加されたノードに他のノードのリージョンが自動的にスケジュール、展開される
  - 負荷分散が実現され、ノード間でデータの大きな偏りはなくなる
- 複数のリージョンに対する考え方
  - リージョンのデータは、異なるノードに保存されRaftグループを形成し、Raftアルゴリズムにより一貫性を保つ
  - レプリカのひとつはリーダーとして機能し、他はフォロワーとして機能する
  - デフォルトではすべての読み込み、書き込みはリーダーを通して処理が行われ、書き込みはフォロワーにレプリケーションされる
MVCCをサポート
分散ACIDトランザクションをサポート