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 より前のバージョンでは、トランザクション ライフサイクル全体を通じてすべてのトランザクション変更がメモリ内に保持されるため、リソースに負担がかかり、パフォーマンスが低下します。数百万行に及ぶ操作の場合、メモリ使用量が過剰になり、リソースが不足するとメモリ不足 (OOM) エラーが発生する場合があります。

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

解決

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

テスト環境

• クラスタトポロジ: TiDB (16 vCPU、32 GiB) 1 + TiKV (16 vCPU、32 GiB) 3
• データセット: 1,000 万行 (約 10 GiB のデータ) の 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 が多数のデータベースとテーブルをホストします。これらのテーブルが小さいか空の場合、特にテーブル数が大規模 (100 万以上など) に増えると、TiKV は多数の小さなリージョンを蓄積します。これらの小さなリージョンにより、メンテナンスの負担が大幅に増加し、リソースのオーバーヘッドが増加し、効率が低下します。

解決

この問題に対処するため、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 パフォーマンステストレポート