CLOVER🍀

That was when it all began.

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サーバー
      • データの保存を担当する
      • 分散トランザクションをサポートするキーバリューストレージエンジン
      • リージョンと呼ばれる単位を基本にデータを保存する
        • 各リージョンにはStartKeyからEndKeyまでキーの範囲でデータが保存される。範囲は左閉半開区間(left-closed and right-open interval)になっていて、終端キーは含まない
      • 各TiKVノードには複数のリージョンを保持する
      • TiKV APIにより、キーと値のペアのレベルで分散トランザクションをネイティブにサポートし、デフォルトでスナップショット分離レベルを提供する
      • TiDBサーバーはSQL文を処理した後に、SQLの実行プランをTiKV APIの呼び出しに変換する
      • データは複数のレプリカ(デフォルトで3つ)を持ち自動的に維持するため、ネイティブで高可用性を備え自動フェイルオーバーが可能
    • TiFlashサーバー
      • 特殊なタイプのストレージサーバーで、TiKVノードとは異なり列ごとにデータを保存する
      • 主に分析処理を高速化するように設計されている

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

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

ストレージ

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

TiDB Storage | PingCAP Docs

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

  • キーバリューペア
    • TiKVはキーバリューのモデルでデータを保存する
      • SQLとの関連についてはこのページでは説明しない
  • ローカルストレージ(RocksDB)
    • TiKVではデータストレージとしてRocksDBを使用している
    • RocksDBを単一のキーバリューMapとして使っている
  • Raftプロトコル
  • リージョン
    • TiKVでは[StartKey, EndKey)の連続するキーセグメントに分割された範囲をリージョンと呼んでいる
    • 各リージョンのデフォルトのサイズは96MB(変更可能)
    • 単一のリージョンに対する考え方
      • 各リージョンのデータは1ノードにのみ保存される
      • TiDBはクラスター内の全ノードのリージョンをできるだけ均等にしようとする(PDサーバーの役割)
      • ストレージは水平方向にスケーリングされ、新しく追加されたノードに他のノードのリージョンが自動的にスケジュール、展開される
      • 負荷分散が実現され、ノード間でデータの大きな偏りはなくなる
    • 複数のリージョンに対する考え方
      • リージョンのデータは、異なるノードに保存されRaftグループを形成し、Raftアルゴリズムにより一貫性を保つ
      • レプリカのひとつはリーダーとして機能し、他はフォロワーとして機能する
      • デフォルトではすべての読み込み、書き込みはリーダーを通して処理が行われ、書き込みはフォロワーにレプリケーションされる
  • MVCCをサポート
  • 分散ACIDトランザクションをサポート

コンピューティング、スケジューリング

コンピューティングとスケジューリングに関するドキュメントはこちらです。

TiDB Computing | PingCAP Docs

TiDB Scheduling | PingCAP Docs

が、このあたりはまたゆっくり眺めていくとします。だいぶSQLの実行に関するものやクラスターの管理の話になっていくので…。

TiKVやTiFlashに関して掘り下げたドキュメントなどもあるので、こちらもいずれ…。

TiKV Overview | PingCAP Docs

TiFlash Overview | PingCAP Docs

おわりに

TiDBのアーキテクチャーを全体像、ストレージをベースに眺めてみました。

QuickStartをやっていた時にはTiKV、TiFlashの位置づけくらいしかわからなかったのですが、少し理解度が上がったような気がします。

これより詳しい内容は、またおいおいドキュメントを見ていこうと思います。