TiDBのアーキテクチャーをざっくりと眺めてみる（コンピューティング概要）

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

TiDBのアーキテクチャーをざっくりと把握しようという、こちらの続きです。

TiDBのアーキテクチャーをざっくりと眺めてみる（全体概要、ストレージ概要まで） - CLOVER🍀

今回はコンピューティングを扱ってみようと思います。対象のTiDBのバージョンは8.1です。

TiDB Computing | PingCAP Docs

コンピューティング

対象のページはこちらです。

TiDB Computing | PingCAP Docs

全体像でいくと、TiDBサーバー（TiDB cluster）の部分ですね。

TiDB Architecture | PingCAP Docs

こういった概要でした。

• MySQLプロトコルのエンドポイントを外部に公開するステートレスなSQLレイヤー
• SQLリクエストを受信してSQL文の解析と最適化を行い、分散実行プランを生成する
• 水平スケーリングが可能で、LVS（Linux Virtual Server）、HAProxyなどの負荷分散コンポーネントを通じて外部にインターフェースを提供可能
• データは保存せずコンピューティングとSQL分析のみが役割

ここではもう少し深堀します。ドキュメント内でTiDBがTiDBそのもののことを言っているのか、コンピューティングコンポーネントである
TiDBサーバーのことを言っているのかちょっと曖昧なのですが、TiDBサーバーのことを言っている場合はそう表記していきたいと思います。

TiDBサーバーは、TiKVが提供する分散ストレージもとづき、トランザクション処理とデータ分析処理の優れた能力を組み合わせた
コンピューティングエンジンです。

Based on the distributed storage provided by TiKV, TiDB builds the computing engine that combines great capability of transactional processing with that of data analysis.

TiDB Computing | PingCAP Docs

このページでは以下の内容が紹介されています。

• TiDBサーバーのテーブルからTiKVのキーと値へのデータマッピングアルゴリズム
• TiDBサーバーのメタデータ管理
• TiDBサーバーのSQLレイヤーアーキテクチャー

ストレージに関してはTiKVのストレージ構造のみを紹介していて、列ベースのストレージであるTiFlashは扱いません。

テーブルのデータからキーと値へのマッピング

まずはテーブルのデータからキーと値へのマッピングについて。

TiDB Computing / Mapping table data to Key-Value

ここで扱うのは2つのタイプのデータです。

• テーブル内の各行のデータ（以降、テーブルデータ）
• テーブル内のすべてのインデックスデータ（以降、インデックスデータ）

テーブルデータのキーと値へのマッピング

TiDB Computing / Mapping table data to Key-Value / Mapping of table data to Key-Value

テーブルデータとキーと値のマッピングは、次のように設計されています。

• 同じテーブルのデータが簡単に検索できるように、各テーブルにID（TableID）を割り当てる
  • TableIDはクラスター全体で一意の整数
• テーブル内の各行にID（RowID）を割り当てる
  • RowIDはテーブル内で一意の整数
  • テーブルのプライマリーキーが整数型の場合、主キーの値をRowIDとして使用する

各行は、次の規則にしたがってキーと値のペアにエンコードされます。

Key:   tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]

tablePrefixとrecordPrefixSepはキー空間内で他のデータと区別するための文字列定数です。

こちらを見ると、実体はtablePrefixはt、recordPrefixSepはrですね。

TiDB Computing / Mapping table data to Key-Value / Summary of mapping relationships

エンコードの例はこちらに書かれています。

TiDB Computing / Mapping table data to Key-Value / Example of Key-Value mapping relationship

実は、このあたりに近い情報は前に少し見ています。

TiDB（TiKV）のデータのリージョンごとの配置状況を確認してみる - CLOVER🍀

TiDB（TiKV）のキーのエンコード・デコード結果を確認する - CLOVER🍀

インデックスデータのキーと値へのマッピング

TiDB Computing / Mapping table data to Key-Value / Mapping of indexed data to Key-Value

TiDBはプライマリーキーとセカンダリーインデックス（ユニークインデックスであってもなくても）の両方をサポートしています。

テーブルデータがそうだったように、インデックスデータにもID（IndexID）を割り当てます。

プライマリーキーおよびユニークインデックスの場合は、キーバリューをもとにRowIDをすぐに見つけられるように以下のように
エンコードされます。

Key:   tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID

対象が一意にならないインデックスの場合は、ひとつのキーが複数の行にマッチすることがあります。このためキーの範囲に応じてRowIDに
対応するクエリーを実行する必要があるため、以下のルールでエンコードされます。

Key:   tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null

indexPrefixSepは、tablePrefixとrecordPrefixSepと同じく文字列定数です。実体はiですね。

TiDB Computing / Mapping table data to Key-Value / Summary of mapping relationships

エンコードの例は、テーブルデータと同様にこちらに書かれています。

TiDB Computing / Mapping table data to Key-Value / Example of Key-Value mapping relationship

メタデータ管理

次はメタデータ管理について。

TiDB Computing / Metadata management

TiDB内の各データベースやテーブルに関する定義や属性はメタデータとして扱われ、この情報もTiKVに保存されます。

それぞれのデータベースやテーブルには一意のIDが割り当てられます。テーブルデータがキーと値にエンコードされると、このIDは
m_ prefix付きのキーとしてエンコードされます。

また、TiDBは専用のキーと値のペア使ってすべてのテーブル構造情報の最新のバージョン番号を保存します。このキーと値のペアは
グローバルに管理されていて、DDL操作が行われるとバージョン番号が1増加します。

TiDBはこのキーと値のペアをPDサーバーに永続的に保存します。キーは/tidb/ddl/global_schema_version、値はint64型の整数値です。

この一方でTiDBはスキーマ変更をオンラインで適用するため、PDサーバーに保存されているテーブル構造情報のバージョン番号が変更されて
いないかどうかを常にチェックするバックグラウンドスレッドを実行します。このスレッドにより、バージョンの変更が一定期間内に
取得されることが保証されます。

SQLレイヤー

最後はSQLレイヤーです。

TiDB Computing / SQL layer overview

SQLレイヤーは、TiDBサーバーのことです。SQL文をキーと値の操作に変換し、分散キーバリューストレージレイヤーであるTiKVに転送します。
そしてTiKVから返された結果を組み立てて、最終的にクライアントにクエリーの結果として返します。

TiDBサーバーはステートレスです。データを持たず、どのノードも同じです。

SQLコンピューティング

TiDB Computing / SQL layer overview / SQL computing

SQLコンピューティングのもっとも簡単なソリューションは、前述のようにテーブルデータをキーと値にマッピングすることです。
これでSQLクエリーがKey Valueクエリーにマッピングされ、Key Valueインターフェースを通して対応するデータの取得や計算処理を
行えます。

例として、select count(*) from user where name = "TiDB"というSQL文をあげます。このSQL文を実行するには、TiDBはテーブル内の
すべてのデータを読み取り、nameカラムが「TiDB」であるかどうか確認し、一致する場合はこの行を返します。

そのプロセスは以下のとおりです。

1. キーの範囲を構築する
   • テーブル内のすべてのRowIDは[0, MaxInt64)の範囲にある
   • 行データのキーのエンコーディングルールにしたがって0からMaxInt64の範囲で[StartKey, EndKey)を構築する
   • StartKeyの値は含む（left-closed）、EndKeyの値は含まない（right-open）
2. キーの範囲をスキャンする
   • 前のステップで構築したキーの範囲にしたがって、TiKVのデータを読み取る
3. データのフィルタリング
   • 読み取られた各行に対して、name = "TiDB"を計算する
   • 結果がtrueの場合はこの行を返し、そうでない場合はスキップする
4. count(*)を計算する
   • 要件を満たす各行ごとに、count(*)の結果に加算する

このプロセスを図示したものがこちらです。

つまり、TiDBサーバーがTiKVから各行のデータを取り出し、TiDBサーバーがフィルタリングと集計をしています。

これはわかりやすいのですが、以下のような問題があります。

• データがスキャンされる際に、各行は少なくともひとつの（RPC操作のオーバーヘッドを伴う）Key Value操作を行う
  • スキャンするデータの量が多い場合は、このオーバーヘッドがとても高くなる可能性がある
• 条件を満たさないデータは読み取る必要がなく、すべての行に適用する必要はない
• このクエリーの返された結果には要件に一致する行の数のみが必要であり、それらの行の値は必要ない

要するに、ムダが多いというわけですね。

分散SQL操作

TiDB Computing / SQL layer overview / Distributed SQL operations

前述のSQLコンピューティングの節で挙げられた問題を解決し、RPC呼び出しが大量行われるのを避けるためには、計算をストレージノードに
できるだけ近づける必要があります。

まずSQLの述語であるname = "TiDB"をストレージノードにプッシュダウンし、有効な行のみが返されるようにします。これでネットワーク
転送が必要以上に行われる状況を回避します。

次に、集計関数count(*)もストレージノードにプッシュダウンして事前集計します。各ストレージノードは、count(*)の結果のみを返します。

SQLレイヤー（TiDBサーバー）は、各ノードから返されたcount(*)の結果を合計します。

この様子を表したのが以下の図です。

SQLレイヤーのアーキテクチャー

TiDB Computing / SQL layer overview / Architecture of SQL layer

ここまでが、SQLレイヤーの機能のいくつかの紹介で、SQL文の処理方法について基本的な内容になっていました。

ですが、実際のSQLレイヤーには多くのモジュールとレイヤーがあり、もっと複雑です。以下の図が重要なモジュールと呼び出し関係を
示しています。

ユーザーのSQLリクエストは、TiDBサーバーに直接、またはロードバランサー経由で送信されます。

TiDBサーバーはMySQLプロトコルパケットを解析し、リクエストの内容を取得します。そしてSQLリクエストを構文的、意味的に解析し、
クエリープランを開発して最適化します。クエリープランを実行した後は、データを取得して処理します。

すべてのデータはTiKVクラスターに保存されているため、このプロセスではTiDBサーバーはTiKVと対話してデータを取得します。
最後にTiDBサーバーは、クエリーの結果をユーザーに返します。

おわりに

TiDBのアーキテクチャー、コンピューティングの概要をざっと見てみました。

コンピューティングノードである、TiDBサーバーの役割やデータをキーと値にマッピングする考え方、そしてSQL実行の流れの基礎的な
内容がわかったような気はします。

とはいえ、まだまだ上澄みな感じはすごくするので、このままドキュメントを読み進めていくと理解が深まるといいなと思います。