TiDB 5.0はそのリリース以来、金融、インターネット、ニューエコノミー、ロジスティクスなどの業界で幅広く利用されています。以下のユーザーを始め、多くのユーザーに受け入れられています。
- 58 FinanceとAnjukeでは、TiDBが、データハウスのレポート作成に必要な複雑な読み取りクエリや結合クエリを処理しています。マルチテーブルの結合クエリの場合、TiDB 5.0はTiDB 4.0よりも90%高いパフォーマンスを発揮できます。
- NetEase Gamesが実施したテストでは、TiDB 5.0にはジッターが認められず、TiDB 4.0よりも安定性が高いことがわかりました。
- Autohomeでは、結合クエリや集計クエリを処理するため、TiDB 5.0を利用しています。TiDB 5.0の超並列処理（MPP）エンジンは、MySQLの20～50倍のパフォーマンスを発揮できます。
PingCAPの共同創業者兼CTOであるEdward Huangは、次のように述べています。「ユーザーからのフィードバックのおかげで、私たちは前進し続けることができます。当社のミッションは、デベロッパーやDBAのユーザーエクスペリエンスを継続的に改善することです。したがって、新たなTiDBをリリースする度に、ユーザーが抱えている問題点を解決することを目指しています。TiDB 5.0以来、リリースサイクルを短縮し、より柔軟かつアジャイルなリリーストレインモデルを採用してきました。最高のアーキテクチャは、実世界のユースシナリオに基づいて構築されたアーキテクチャだと私たちは考えています。実際のユーザーから何らかの機能をリクエストされたならば、それは2か月後の次のリリースでその機能を提供するための機会を与えられたということです。」
TiDB 5.1のリリースをここに発表します。今回のリリースにより、遅延がより安定し、MPPのパフォーマンスと安定性が最適化されるほか、メンテナンスがさらに容易になります。TiDB 5.1では、デベロッパーやDBAはあらゆる規模のミッションクリティカルアプリケーションをより簡単に構築することができます。
TiDB 5.1の特長
新しいリリースでは、ANSI SQL99標準の共通テーブル式がサポートされます。メンテナンスしやすいより簡潔なSQLを記述することができます。これにより、複雑なアプリケーションロジックを簡単に処理し、各アプリケーションをより効率的に開発できます。
MPPがさらに高速化され、その安定性も増したため、リアルタイムの意思決定をより迅速に行うことができます。TiDB 5.1では、MPPモードでのパーティションテーブルと、最適化された関数式と演算子がサポートされています。これらの機能のおかげで、TiDBのリアルタイム分析のパフォーマンスは10倍以上向上します。TiDBのメモリ管理とロードバランシングが強化され、分析クエリ処理のスピードと効率性が改善されています。
さまざまなワークロードで、クエリの遅延が大幅に短縮（20%～70%）されます。突然大量の書き込みがデータベースに流れ込んだ場合でも、クラスタをスケールインまたはスケールアウトする必要が生じた場合でも、オンラインデータがインポートまたはバックアップされた場合でも、TiDB 5.1のロングテールクエリの遅延はこれまでよりも安定しています。高負荷下でのクエリ処理、特に、低遅延を必要とする金融業界のミッションクリティカルアプリケーションでのクエリ処理が大幅に安定しました。
また、MySQL互換性も向上しているため、アプリケーションコードを変更することなく、TiDBに簡単に移行することができます。また、カラムタイプの変更がサポートされました。
TiBD 5.1を利用すれば、大規模なクラスタをより簡単に操作およびメンテナンスでき、DBAの負荷をさらに軽減できます。TiDB 5.1のクラスタスケーリングとデータ移行のスピードは、約40%向上しました。これにより、大規模クラスタの操作とメンテナンスの信頼性が改善し、大規模クラスタのバックアップとリカバリにかかる時間が短縮されます。変更データキャプチャ（CDC）のデータリンクの一時中断後の自動回復機能を最適化したため、データ複製の信頼性が向上しています。
より柔軟なアプリケーション開発
カラムタイプの変更に対応
複数のアップストリームMySQLクラスタからのデータは、しばしばバイナリログを介して単一のTiDBクラスタに集約されます。これまでのTiDBは、カラムタイプの変更に対応していませんでした。アップストリームMySQLクラスタでテーブルのカラムタイプが変更されると、MySQLとTiDB間のデータ複製は停止していました。TiDB 5.1では、カラムタイプを変更するデータ定義言語（DDL）ステートメントがサポートされるようになりました。これにより、上記の問題が解決され、TiDBとMySQL間の互換性が高まります。
ステイル読み取り（実験的な機能）
ステイル読み取りは、読み取りが頻繁に発生し、書き込みがほとんどなく、鮮度の低いデータを許容できるシナリオに適しています。例えば、Twitterユーザーがツイートすると、システムが何千もの、あるいは何百万もの読み取りリクエストを受け取るようなケースが挙げられます。ツイートを表示する際に少々の遅延が発生しても、それは許容範囲内です。このシナリオでは、データベースに対し、並列読み取りの大きな負荷がかかるため、読み取りホットスポットを生じさせる可能性があります。読み取りホットスポットが原因で、ノード間の負荷分散が不均等になり、スループット全体がボトルネックになる可能性があります。
ステイル読み取りを利用すれば、TiDBは指定された時間の履歴データをいずれかの複製から読み取ることができます。複製は、Leaderとして動作する必要がありません。そのため、ステイル読み取りを利用すれば、ノードにかかる負荷を大幅に軽減し、スループット全体をほぼ2倍にすることができます。
/* for example, you can enable Stale Read by setting the current transaction to query data from five seconds ago */
> SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() – INTERVAL 5 SECOND;
> SELECT * FROM T;ロックコンフリクトの迅速な特定（実験的な機能）
アプリケーションロジックは、同時実行トランザクションを慎重に処理するものである必要があります。テーブルロックが発生すると、オンラインアプリケーションに大きな影響を及ぼす可能性があります。DBAはロックの原因を迅速に特定し、アプリケーションを正常な状態に回復させなければなりません。
TiDB 5.1にはLock Viewが導入されています。Lock Viewを利用すれば、DBAはテーブルロックの原因となっているトランザクションやSQLステートメントをすばやく特定し、きわめて簡単にロックコンフリクト問題を解決することができます。
以下に示すのは、Lock Viewによって、テーブルロックの原因となっているトランザクションやSQLステートメントをすばやく特定するためのプロセスです。
より高速かつ正確な統計分析
アプリケーションのデータは絶えず変化するため、テーブルの統計データは陳腐化する場合があります。陳腐化の結果、オプティマイザーの実行プランの精度が下がり、クエリ速度が低下します。DBAはANALYZE操作を実行し、テーブルの統計データを再構築します。
TiDB 5.1では、ANALYZEサンプリングアルゴリズムのパフォーマンスが最適化されています。統計データを平均で50%速く作成することができます。また、今回のリリースでは新しい統計データタイプが導入されているため、オプティマイザーはより正確にインデックスを選択できます。
共通テーブル式：SQLステートメントの記述を効率化
金融トランザクションシナリオでは、アプリケーションの複雑性が高いため、2,000行にも及ぶ単一SQLステートメントを記述する場合があります。こうしたステートメントには、おそらく大量の集計とサブクエリの複数層の入れ子が含まれています。このようなSQLステートメントをメンテナンスすることは、デベロッパーにとっては悪夢のようなものです。今回のTiDB 5.1のリリースで、ANSI SQL99標準の共通テーブル式（CTE）と再帰がサポートされました。これにより、デベロッパーやDBAは、複雑なアプリケーションロジックのSQLステートメントをより効率的に記述できるほか、コードを容易にメンテナンスできます。
リアルタイム分析機能の強化
改善されたMPPパフォーマンスと安定性
意思決定を迅速化できるよう、TiDB 5.1ではTiFlash MPPエンジンの計算機能を以下のとおり大幅に高めました。
- MPPはパーティションテーブルに対応しています。MPPをアプリケーションロジックと組み合わせることにより、膨大なデータクエリや分析で消費されるリソースを削減し、クエリスピードを向上させることができます。
- TiDBでは、一般的に利用されるSQL関数を利用し、演算子を最適化することができます。これにより、クエリでMPPエンジンが有効活用され、計算処理が高速化します。
- TiDBには、強制的にMPPモードにするための、便利なスイッチが備わっています。これにより、MPPモードを有効化するかどうかをユーザーが決定できます。
- TiDBでは、クラスタロードバランシングと分散メカニズムが最適化され、ホットスポットが除去されます。これにより、システムの総合的キャパシティが改善されます。
- エンジンメモリ使用量の問題が修正されています。これにより、よりスムーズかつ安定的なエクスペリエンスが実現されます。
高ワークロード時でも高い安定性を確保
TiDB 5.1では、高負荷時におけるクエリと分析の安定性が改善されています。金融ビジネスのシナリオでは、高負荷のバッチデータ処理が毎日実行され、最新のマーケティングレポートが作成されます。そしてこのレポートに基づき、意思決定がなされます。バッチ処理の継続性要件は非常に厳しく、ミスは絶対に許されません。TiDB 5.1では、こうしたユースケースを基に、TiDBのリクエスト再試行メカニズムとTiKVのリクエスト処理メカニズムが最適化されています。これにより、高負荷時にTiFlashデータ複製がタイムリーに実行されない場合に発生する、Region Unavailableエラーが大幅に軽減されます。
TiSparkとのシームレスな統合
TiSpark 5.1では、クラスタ化されたインデックスを持つテーブルの読み取りと書き込みを行うことができ、しかも追加のパフォーマンスオーバーヘッドが発生しません。この最適化は、ユーザーにとって完全にトランスペアレントになっています。TiSparkの最新バージョンにアップグレードできるとともに、TiSparkとTiDBをシームレスに連携させることができます。
読み取りと書き込みの遅延ジッターを軽減
低遅延を必要とするアプリケーションを利用する場合において、以下の条件が該当するとき、データベースのP99およびP999でジッターが発生する可能性があります。
- 大量の書き込みトラフィックがオンラインで生成されている。
- TiDBのスケールアウトまたはスケールインが行われている。
- 統計タスクがバックグラウンドで実行されている。
- データがオンラインデータベースにインポートされている、またはデータがオンラインデータベースからバックアップされている。
これらの状況は、ロングテールクエリに影響を及ぼす場合があります。
TiDB 5.1では、ディスクの読み取りと書き込みリンクの管理が強化されており、バックグラウンドタスクによるディスクリソースの使用が制限されます。こうした強化策によって、上記シナリオによるオンラインアプリケーションへの干渉が大幅に減少するほか、読み取りと書き込みリンクの効率性と安定性が改善されます。
EBS gp3ディスクをマウントしたAWS EC2 r5b.4xlargeインスタンスでTPC-Cベンチマークテストを行ったところ、以下の結果になりました。
- TiKVの動作クラスタを6ノードから3ノードにスケールインすると、P99は20%、P999は15％減少しました。
- 200 GBデータをTiDBにオンラインでインポートすると、P99は71%、P999は70%減少しました。
大規模クラスタのメンテナンスとデータ伝送の信頼性が向上
大量のテーブルのバックアップを最適化
今回のリリースでは、大量のテーブルのバックアップが最適化されています。50,000テーブルを持つデータベースの場合、完全バックアップにかかる時間は60～70%短縮されます。
また、TiDB 5.1には、バックアップモジュールの新しいメタデータファイル編成（「v2」）も導入されました。これにより、1回の書き込みのデータ量が削減され、メモリ消費量が低下するとともに、8 GB以下の環境での異常終了が回避されます。ユーザーはBRを起動する時に、–backupmeta-version=2を指定することによって、「v2」を有効化することができます。
大規模クラスタのメンテナンスの信頼性が向上
TiDBクラスタの規模が大きくなるほど、クラスタのスケーリング、ハードウェアのアップグレード、ノードの移行などのメンテナンス業務に要する時間も長くなります。TiDB 5.1では、スケーリング中におけるデータ移行のパフォーマンスが大幅に向上します。パフォーマンステストの結果は以下のとおりです。
- 100ノードのクラスタの場合、データセンター間で全データを移行させる時間が20%短縮されました。
- ノードをオフラインにしたり、ノードからデータを移行させたりする時間が約40%短縮されました。
メモリ使用量の最適化
TiDB 5.1では、メモリ使用量が以下のように最適化されているため、メモリ不足（OOM）のリスクが低くなっています。
- ウィンドウ関数row_numberは、データサイズに関係なく、固定量のメモリしか使用しない。
- メモリ使用量を抑制できるように、パーティションテーブルでの読み取り操作が最適化されている。
- ストレージレイヤーには、構成可能なメモリ制限が設けられた。メモリ制限に達すると、システムがキャッシュをリリースしてメモリ使用量を抑制します。
- TiFlashでの書き込みで使用するメモリ量が、80%削減された。
信頼性の高いCDC複製リンク
TiCDC 5.1は、手動による操作を必要としない、信頼性の高いデータ複製リンクを備えています。環境に混乱が生じたり、ハードウェアに障害が発生したりした場合は、TiCDCが複製を継続させます。複製作業が中断された場合でも、状況に応じて複製作業が自動的に再試行されます。
謝辞
Xiaomi社、Zhihu社、iQiyi社、Li Auto社、Sina社、Huya TV社、Xiaodian社、KY Express社、EMAR Online社を始めとするコミュニティの開発者の皆様に対し、心より感謝申し上げます。皆様からは、TiDB 5.1の設計、開発、テストで非常に有益かつ継続的なご支援をいただきました。このようなご支援のおかげで、リリースする度にTiDB 5.1を改善することができます。
PingCAPについて
PingCAPは、エンタープライズ向けのソフトウェアサービスプロバイダーとして2015年に設立され、オープンソースでクラウドネイティブなワンストップのデータベースソリューションを提供することにコミットしています。PingCAPの社名は、ネットワークの疎通を確認するために使用されるコマンド「Ping」とCAP定理の「CAP」の2つの単語を組み合わせています。3つのうち2つを選ばなければならないとされるCAP定理のC (Consistency – 一貫性)、A (Availability – 可用性)、P (Partition Tolerance – ネットワーク分断への耐性) ですが、この3つの全てに接続したい (Ping) という思いが込められています。PingCAPの詳細については https://pingcap.co.jp をご覧ください。
本件に関するお問合わせ先
PingCAP株式会社 広報部
Email：pingcapjp@pingcap.com