TiDB v8.5.0 のTiDB Cloudパフォーマンスのハイライト

TiDB v8.5.0は重要な長期サポート (LTS) リリースであり、パフォーマンス、スケーラビリティ、運用効率が大幅に向上しています。

このドキュメントでは、次の領域における v8.5.0 のパフォーマンス改善について概説します。

• 全体的なパフォーマンス
• 過剰なMVCCバージョンによるホットスポット読み取り
• IOレイテンシージッター
• バッチ処理
• TiKVのスケーリングパフォーマンス

全体的なパフォーマンス

v8.5.0 では、デフォルトのリージョンサイズが 96 MiB から 256 MiB に増加し、その他のいくつかの改善も行われたため、パフォーマンスが大幅に向上しました。

• oltp_insertパフォーマンスが 27% 向上します。
• Analyzeパフォーマンスは約 45% の大幅な向上を示します。

過剰なMVCCバージョンによるホットスポット読み取り

チャレンジ

一部のユーザー シナリオでは、次のような課題が発生する可能性があります。

• 頻繁なバージョン更新: 一部のワークロードでは、データが非常に頻繁に更新され、読み取られます。
• 履歴バージョンの長期保存：特定の時点へのフラッシュバックのサポートといったビジネス要件を満たすため、ユーザーはGC（ガベージコレクション）時間を過度に長く（例えば24時間など）設定することがあります。その結果、多版型同時実行制御（MVCC）バージョンが過剰に蓄積され、クエリ効率が大幅に低下します。

MVCC バージョンが蓄積されると、要求されたデータと処理されたデータの間に大きなギャップが生じ、読み取りパフォーマンスが低下します。

解決

この問題を解決するために、TiKV はインメモリエンジン（IME）導入します。最新バージョンをメモリにキャッシュすることで、TiKV は履歴バージョンが読み取りパフォーマンスに与える影響を軽減し、クエリ効率を大幅に向上させます。

テスト環境

• クラスタトポロジ: TiDB (16 vCPU、32 GiB) 1 + TiKV (16 vCPU、32 GiB) 6

• クラスタ構成:

  tikv_configs:
  [in-memory-engine]
  enable = true
  

• データセット: 頻繁に更新されるデータを含む、約 340 のリージョンを持つ 24 GiB のstorageサイズ

• ワークロード: スキャンを必要とする行には、頻繁な更新によって導入された多数の MVCC バージョンが含まれています。

テスト結果

クエリのレイテンシーは50% 減少し、スループットは 100% 増加します。

IOレイテンシージッター

チャレンジ

クラウド環境では、クラウドディスクにおける一時的または持続的なIOレイテンシーの変動が一般的な課題となります。こうした変動はレイテンシーの増大を招き、タイムアウト、エラー、通常の業務運用の中断を引き起こし、最終的にはサービス品質の低下につながります。

解決

TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォーマンスへの影響を軽減するための複数の機能強化が導入されています。

• Leader書き込み最適化: リーダーがコミットされたがまだ永続化されていないRaftログを早期に適用できるようにし、リーダー ピアの書き込みレイテンシーに対する IO ジッターの影響を軽減します。

• 低速ノード検出の強化：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラが起動し、パフォーマンスを回復します。2 遅いノード検出メカニズム 低速ストアの排除スケジューラ使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。

• 統合ヘルスコントローラー：TiKVに統合ヘルスコントローラーを追加し、KVクライアントにフィードバックメカニズムを追加します。KVクライアントは、TiKVノードのヘルスとパフォーマンスに基づいて、エラー処理とレプリカ選択を最適化します。

• レプリカ セレクターの改善: KV クライアントにレプリカ セレクター V2 が導入され、状態遷移が改良され、不要な再試行やバックオフ操作が排除されます。

• 追加の修正と改善: TiKV のストア ループでの不要な IO 操作を回避しながら、リージョン キャッシュや KV クライアント ヘルス チェッカーなどの重要なコンポーネントの機能強化が含まれています。

テスト環境

• クラスタトポロジ: TiDB (32 vCPU、64 GiB) 3 + TiKV (32 vCPU、64 GiB) 6
• ワークロード: 読み取り/書き込み比率 2:1、クラウド ディスク IO の遅延または 1 つの TiKV ノードでのハングをシミュレート

テスト結果

前述のテスト設定に基づいて、複数の IO 遅延シナリオでのフェイルオーバーが改善され、影響時の P99/999レイテンシーが最大 98% 削減されました。

次のテスト結果の表では、 「現在」の列には IOレイテンシージッターを削減するための改善を加えた結果が表示され、 「オリジナル」の列にはこれらの改善を加えていない結果が表示されます。

さらなる改善

ディスクジッターの重大度は、ユーザーのワークロードプロファイルにも大きく関係する可能性があります。レイテンシの影響を受けやすいシナリオでは、TiDBの機能と組み合わせてアプリケーションを設計することで、アプリケーションへのIOジッターの影響をさらに最小限に抑えることができます。例えば、読み取り負荷が高くレイテンシの影響を受けやすい環境では、レイテンシー要件に応じてtikv_client_read_timeoutシステム変数を調整し、ステイルリードまたはフォロワーリードを使用することで、TiDBから送信されたKVリクエストに対する他のレプリカピアへのフェイルオーバー再試行を高速化できます。これにより、単一のTiKVノードへのIOジッターの影響が軽減され、クエリレイテンシーの改善に役立ちます。この機能の有効性はワークロードプロファイルに依存するため、実装前に評価する必要があります。

さらに、ユーザーパブリッククラウドへのTiDBの導入 、より高性能なクラウド ディスクを選択することで、ジッターの可能性を減らすことができます。

バッチ処理

チャレンジ

大量データ更新、システム移行、ETLワークフローといった大規模トランザクションは、数百万行の処理を伴い、重要な業務をサポートする上で不可欠です。TiDBは分散SQLデータベースとして優れた性能を発揮しますが、このような大規模なトランザクションの処理には、2つの大きな課題があります。

• メモリ制限：TiDB v8.1.0より前のバージョンでは、トランザクションのライフサイクル全体を通じてすべてのトランザクション変更がメモリ内に保持されるため、リソースに負担がかかり、パフォーマンスが低下します。数百万行に及ぶ操作では、メモリ使用量が過剰になり、場合によってはリソース不足によりOut of Memory（OOM）エラーが発生する可能性があります。

• パフォーマンスの低下：大規模なメモリ内バッファの管理は赤黒木に依存しており、計算オーバーヘッドが発生します。バッファが大きくなると、これらのデータ構造に固有のO(N log N)の計算量により、処理速度が低下します。

解決

これらの課題は、スケーラビリティの向上、複雑さの軽減、信頼性の向上を実現する明確な機会を浮き彫りにしています。現代のデータワークロードの増加に伴い、TiDBは大規模トランザクションの処理を最適化し、リソース利用率と全体的なパフォーマンスを向上させるように設計されたパイプラインDML機能を導入しました。

テスト環境

• クラスタトポロジ: TiDB (16 vCPU、32 GiB) 1 + TiKV (16 vCPU、32 GiB) 3
• データセット: 1,000万行（約10GiBのデータ）のYCSB非クラスタ化テーブル。ホットスポットパターンの影響を分離・評価するため、特定のテストでは主キーを部分的に削除しています。
• ワークロード: INSERT UPDATE含む DML DELETE 。

テスト結果

実行速度は 2 倍になり、最大 TiDBメモリ使用量は 50% 減少し、TiKV 書き込みフローはよりスムーズになります。

• レイテンシ（秒）

  ワークロード（10 GiB）	標準DML	パイプラインDML	改善
  YCSB-挿入-10M	368	159	131.45%
  YCSBアップデート10M	255	131	94.66%
  YCSB-削除-10M	136	42	223.81%

• TiDBメモリ使用量のピーク (GiB)

  ワークロード（10 GiB）	標準DML	パイプラインDML	削減
  YCSB-挿入-10M	25.8	12	53.49%
  YCSBアップデート10M	23.1	12.9	44.16%
  YCSB-削除-10M	10.1	8.08	20.00%

TiKVのスケーリングパフォーマンス

チャレンジ

水平スケーリングはTiKVの中核機能であり、必要に応じてシステムをスケールインまたはスケールアウトできます。ビジネス需要の拡大とテナント数の増加に伴い、TiDBクラスターではデータベース、テーブル、データ量が急速に増加します。サービス品質を維持するためには、TiKVノードを迅速にスケールアウトすることが不可欠になります。

シナリオによっては、TiDB が多数のデータベースとテーブルをホストすることがあります。これらのテーブルが小さい場合や空の場合、TiKV は多数の小さなリージョンを蓄積します。特にテーブル数が大規模（100万以上など）になると、その傾向が顕著になります。これらの小さなリージョンは、メンテナンスの負担を大きくし、リソースのオーバーヘッドを増加させ、効率を低下させます。

解決

この問題に対処するため、TiDB v8.5.0では、小規模リージョンのマージパフォーマンスが向上し、内部オーバーヘッドが削減され、リソース使用率が向上しました。さらに、TiDB v8.5.0には、TiKVのスケーリングパフォーマンスをさらに向上させるためのその他の機能強化もいくつか含まれています。

テスト環境

小さな地域の統合

• クラスタトポロジ: TiDB (16 vCPU、32 GiB) 1 + TiKV (16 vCPU、32 GiB) 3
• データセット: 約 100 万個の小さなテーブル (各テーブルのサイズは 2 MiB 未満)
• ワークロード: 小さなリージョンの自動マージ

TiKVノードのスケールアウト

• クラスタトポロジ: TiDB (16 vCPU、32 GiB) 1 + TiKV (16 vCPU、32 GiB) 4
• データセット: 20,000 の倉庫を含む TPC-C データセット
• ワークロード: TiKV ノードを 4 から 7 にスケールアウト

テスト結果

小さなリージョンの結合速度が約 10 倍向上します。

TiKV スケーリング パフォーマンスは 40% 以上向上し、TiKV ノードのスケールアウト時間は 30% 短縮されます。

ベンチマーク

上記のテスト データに加えて、v8.5.0 のパフォーマンスに関する次のベンチマーク結果を参照できます。

• TPC-Cパフォーマンステストレポート
• Sysbenchパフォーマンステストレポート