「PingCAP認定スキルアップワークワークショップ TiDBエキスパートへの道」を通して感じたTiDBの感想

こんにちは髙橋です。
2024年3/21～22の2日間で、今話題のTiDBのワークショップに参加しましたので、TiDBについて学んだことと感想を投稿します。

TiDBとは何か？

TiDBはNewSQLの一つで、MySQLと互換性のある分散データベースです。TiDBのTiはTitanium(チタニウム)の略で、微笑みの国とは関係ないようです。ただ、今回のワークショップに参加することで、システム担当としては微笑みたくなるような内容が多くありました。

ワークショップ

2024年3月21日～22日の2日間にわたり東京丸の内にあるビルの一室でPingCAP様主催で開催されました。
ワークショップの前後で桜の開花予想が出ておりましたが、気温が思ったほど上がらず桜の開花は遅れていたことは残念でした。

多数の会社の方が参加され、各セッションで質問も多数出ており、活発なワークショップでした。
私もあらかじめTiDBを触っていたこともあり、幾つかの質問に回答をいただけたのは大変良かったです。
また、親睦会を開催いただきほかの会社の方とお話しさせていただけたのもよい経験でした。

TiDBの特徴

では、今回のワークショップで学んだ内容を細かく上げていきたいと思います。

TiDBは複数のサーバーで構成されている

TiDBを構成するサーバーとしては「TiDBサーバー」「PDサーバー」「TiKVサーバー」「TiFlashサーバー」があげられます。

TiDBサーバーはTiDBの入り口のようなもので、クエリの受付や結果を返すといったものを担当します。
MySQLと互換性のあるTiDBでは、SQLをTiDBが解析し、各種処理の実行計画を立ててTiKV(TiFlash)サーバーと通信を行います。

TiKVサーバーは、TiDBのデータを保存しているサーバーです。
内部ではRockyDBと呼ばれるKey-Value形式のDBが稼働していますが、単純にKey-Valueで保存するだけではありません。
複数台数で構成されるTiKVサーバーでは、一つのテーブルをリージョンという単位で分割し、各サーバーに分散して保存します。また、Mult-Raftプロトコルを使用したシステムでは、一部のサーバーがダウンしてもデータの一貫性・保守性が保たれた状態となります。

PDサーバーはTiDBサーバー・TiKVサーバーのデータの正当性を保つという大きな役割があります。
TiDBは分散型データベースであるために、各サーバーにはタイムラグがあり、そのタイムラグを埋めるための仕組みが用意されています。
具体的にはタイムスタンプ(TSO)を発行するというものですが、PDがTiDBのデータの正当性を保っていると言えます。

TiFlachサーバーはTiDBの特徴であるHTAPを実現するためのサーバーといえます。
TiKVサーバーはデータをKey-Value形式で持ちますが、内部的にはテーブルの情報を1行づつ保存しているというイメージです。
これに対し、TiFlashはデータを列で持つイメージになります。
そのため、列に対する計算(和・平均等)に対するコストを減らすことが期待できます。
また、TiKVサーバーと同時に利用することができるので、一部は行指向の計算、一部は列指向の計算といった形でクエリを実行することが可能です。

分散型データベースである

先に述べたように、TiDBは複数のサーバーで構成されています。
データを扱うTiKVサーバーも複数のサーバーで構成されており、スケールアウト・スケールインが容易にできるような仕組みを採用しています。
従来のデータベースではダウンタイムが必要とされるところ、システムを停止させることなく実行することも可能です。

また、Raft/Multi-Raftと呼ばれるアルゴリズムを使うことで、一部のノードで障害が起きても他のノードが肩代わりすることでダウンタイムを発生せずにサービスを続けることが可能です。
また、ホットスポットとなるノードがあったとしても、自動的に負荷を分散させることで負荷を散らすということも期待できます。

MySQL互換である

TiDBでは、独自にMySQLのSQLを構文解析し、TiDBのコマンドに変換させて実行することが可能です。このため、これまでMySQLで扱っていたシステムをそのままTiDBに移行することが容易です。

ただし、MySQL互換とはいえ中身は全く違うので、MySQLで期待していた通りの動きになるかは試してみる必要があるようです。

分析機能が強化されている

TiDBではもともとOLTP(オンライントランザクション処理)型のDBとして開発されてきていました。その後、TiFlashサーバーの登場で、OLAP(オンライン分析処理)型のDBとしても容易に操作が可能になりました。

結果、OLTPワークロードとOLAPワークロードの両方を処理するデータベースとして、ハイブリッドトランザクション/分析処理（HTAP）ワークロードに対応したDBとなっています。TiFlashの項目でも書きましたが、データの持ち方をTiKVサーバーとは別にするということで、実現されたようです。

これまでは分析のために別サービスを利用するということが多かったですが、今後一つのDBでリアルタイムに分析を行うことが可能になっていきそうです。

TiDBを使うにあたっての懸念

ワークショップを通して、あるいはTiDBを触ってみたことによる懸念を少し出したいと思います。

PHPとの相性

TiDBはMySQLと互換性があるということでMySQLライクな使い方ができます。実際、Laravelの接続先としてTiDBを設定することで、違和感なく扱うことが可能です。

ただし、MySQLのクエリが使えはしますが、内部的には全く違うものですのでサポート外や想定外の動きがでてきます。

主キーの設定方法
TiDBなどの分散データベースでは、主キーをもとに分散させる仕組みになっていることが多いです。
そのために、主キーをAUTO_INCREMENTで設定するよりもAUTO_RANDOMで設定することが推奨されています。これは、テーブルに保存されているデータをなるべく分散させて保持するために、主キーをランダムに発行するというものになります。

ただ、AUTO_RANDOMの取る範囲は64ビットのランダムな整数になります。そのためにPHPのINT型の最大値を超えてしまう可能性があります。AUTO_RANDOMの取りうる値を変更するなどして対応する必要があるようです。
主キーをSignedにするか、64ビットではなく32ビットにするなどの対応が必要そうです。

テーブルのCreate文
MySQL互換とはいえ、テーブルのCreate文の一部はコメントアウトして出力されます。
AUTO_RANDOMを設定したテーブルでも、SHOW CREATE TABLEではAUTO_RANDOMがコメントとして記載されてしまうので、テーブルの移行やMigrationファイルを生成するときは注意が必要かもしれません。

ほかにもTiDB特有の設定などはコメントアウトされてしまうようなので、注意が必要かと思います。