TiDB 7.1をリリース：ビジネスクリティカルなアプリケーションのための安定性とパフォーマンスの向上

※このブログは2023年6月5日に公開された英語ブログ「Presenting TiDB 7.1: Enhanced Stability and Performance for Business-Critical Applications」の拙訳です。

ビジネスを成長させるためには、正確なデータへの迅速かつ信頼性の高いアクセスが必要です。これより、お客様の高い期待に応え、開発者やインフラエンジニアの生産性を加速させることができます。

2023年に予定されている2つの長期安定版 (LTS) の最初のリリースであるTiDB 7.1は、幅広いビジネスクリティカルなアプリケーションを強化できる、将来性のあるデータベースを提供することにより、これを容易にします。TiDB 7.1では、以下のことが可能です：

• DBオペレータが異なるワークロードを安定して制御できるようにし、テールレイテンシを大幅に改善することで、ビジネスクリティカルなワークロードを安定させます。
• より高いスループットと、より高速なオンラインDDLを実現するアーキテクチャの強化により、少ないリソースでワークロードを高速化します。

この記事では、TiDB 7.1の主要な機能と拡張機能、および前回の安定版リリースであるTiDB 6.5以降、過去の非安定版リリースで追加された実験的機能の一般公開 (GA) について説明します。

TiDB 7.0のリリースブログで紹介したキーとなる機能がいくつかありましたが、今回はそれについて詳しく説明しません。その機能とは、TiFlashの新しいアーキテクチャ、TiFlashのspill-to-diskクエリの安定性、REORGANIZE LIST/RANGEのパーティションです。TiDB 6.5 (前回のLTS) とTiDB 7.1 (今回のLTS) の間の差分に関するその他のすべての詳細については、リリースノートをご参照ください。

ビジネスクリティカルなワークロードを安定させる

このセクションで説明する機能および拡張は、クラスタの安定性をテーマとしています。具体的には、ワークロードによらずクラスタを安定させ、エッジケースにおけるワークロードのレイテンシを安定させることです。

リソースグループによるリソース制御のUXの改善

前回のブログ (TiDB 7.0) で、リソースグループによるリソース制御機能を紹介し、より完全なマルチテナンシーを実現するための準備を整えました。簡単に説明すると、この機能により、TiDBのオペレータは異なるワークロードに対してリソースのクォータと優先度を設定することができ、ミッションクリティカルなワークロードがクラスタを共有する他のワークロードの影響を受けずに実行できるようになります。

クリティカル性の高いワークロードを保護するために、TiDB管理者に与えられた権限は絶大です。しかし、前回発表した時点では実験的なものに過ぎません。TiDB 7.1では、2つの機能強化を行いこの機能をGAとしました：

• 書き込み量の多いワークロードで発生するわずかなレイテンシー劣化の除去
• より正確なリソースクォータを設定するための、ネイティブのワークロードキャリブレーションツールの追加

新たな強化点

1つ目の強化点について、リソースグループは、リソースクォータとプライオリティによってワークロードを制御します。優先順位は、ストレージレベルによって制御されます。ワークロードの書き込み量が多い場合、優先順位に基づくトランザクションのリスケジューリングにより、テールレイテンシが高くなることがあります。この機能のGA化により、テールレイテンシは期待される値に戻ります。

2つ目の強化点はユーザー体験に関係するものです。リクエストユニット (RU) のような抽象的な単位を使用してリソースクォータを設定することは、RUがワークロードにどのように関係するかという参照値を持っていない場合、難しいかもしれません。今回、オペレーターは、いくつかの方法でこの知識を得ることができるようになります。

最も速い方法は、SQLインターフェースからキャリブレーションコマンドを実行し、TPC-Cやsysbench (ワークロードにより近くなるように設定可能) などの既知のベンチマークスイートのRU使用量を推定することです。選択されたワークロードに対するこのRU容量の推定値は、クラスタサイズと利用可能なリソースに基づきます。

この値を測定する最適な方法は、新たに利用可能になった、リソースグループごとのRU使用量を追跡するメトリクスを使用することです。ステージング環境や開発環境でワークロードにリソースグループを割り当て、その環境でのRU使用量が代表的な期間にわたってどのように見えるかを知ることができます。そこから、その学習に基づいて本番環境にクォータを適用することは簡単なことです。

複数のホットスポットシナリオにおける性能安定性の向上

TiDBの基盤となる行ストレージであるTiKVには、レイテンシの安定性を向上させるための3つの重要な強化点があります。我々はこれをp99レイテンシーで測定しています。キーレベル、シャード (キーリージョン) レベル、ノードレベルという3つのレベルのホットスポットを処理するため、3つの最適化が導入されました：

• キーレベルホットスポット：ロック競合の最適化
• シャードレベルのホットスポット：TiKVサブタスクのバッチ処理
• ノードレベルのホットスポット：負荷に応じたレプリカの読み取りの導入

ロック競合の最適化 (GA) 

TiDBは、キーレベルのホットスポットを処理するための最適化を導入しました。多数のシングルポイント悲観的ロック競合が発生するワークロードでは、待機中のリクエストを呼び出すためのより安定したアルゴリズムが無駄な再試行を最小限に抑え、最終的にクラスタ全体でリソースとテールレイテンシーを削減します。この最適化を有効にした場合、テストでは、わずかなスループット低減の可能性がありますが、最も競合の多いワークロードでも、テールレイテンシが40～60%改善されることが示されています。

図 1

TiKVサブタスクのバッチ処理 (GA)

選択性の高くないクエリでは、多くのキーを読み取る必要がある場合もあります。TiDBの分散型アーキテクチャでは、このようなクエリは、クラスタに分散した多くのシャードに向かう多くのリクエストを管理することを意味し、クラスタ全体で数万から数十万のRPCを発行することもあります。

TiKVクライアントとして動作するTiDBサーバーは、同じシャードを対象とするタスクをバッチ処理する機会を認識し、それらのバッチを適切なストレージノードに送信するようになりました。これにより、ネットワークRPCが大幅に削減され、大規模なバッチクエリのパフォーマンスが安定します。この機能強化により、このようなシナリオでの待ち時間を最大50%短縮することができます。

負荷に応じたレプリカの読み取り (GA)

この最適化は、ノードのホットスポットに対処するものです。大規模なバッチクエリがキー検索を不均一に実施する場合、ノードのホットスポットが発生する可能性があります。Index検索JOINのような一般的なもので、これが発生する可能性もあります。このような場合、読み取りリクエストはキューに入れられ、キューが大きくなると、一部のリクエストはより長く待つことになります。このようなシナリオでは、クラスタの残りのリソースを合理的に使用して作業を分散させることで、待ち時間を短縮したいと考えてるでしょう。

TiKVはこの度、これを実現するための負荷ベースのレプリカ読み込みを導入しました。TiKVには、キューに設定可能な持続時間のしきい値が設定されており、これを超えるとTiDBにレプリカの読み込みを優先するように指示します。この機能により、このようなホットスポット・シナリオのレイテンシーを70%から200%改善することができます。

この最適化の詳細については、ドキュメントをご参照ください。

TiDB 7.1 は、少ないリソースでワークロードを高速化する

このセクションで説明する機能と強化は、書き込み、読み込み、操作をスピードアップし、より良いユーザー体験を提供します。新しいタイプのIndexが追加され、これまで非効率だった種類のワークロードが可能になりました。さらに、書き込みスループット、分析クエリの速度、バックグラウンドタスクの効率化にも大きな改善と最適化が行われました。

Multi-value index (GA) によるスピードと柔軟性の追加

この機能は、新しいindexによってスピードを追加しました。「JSON index」とも呼ばれるこの新しいタイプのセカンダリインデックスは、TiDB 6.6で導入され、その後GAになりました。Multi-value index (MySQLでサポート) は、インデックスの値とデータ行のN:1マッピングを可能にし、クエリでJSON配列を格納する行に特定の値が含まれるかを迅速にチェックできるようにしました。

たとえば、次のようなデータをカラムに格納しているとします：

{

    "user":"Bob",

    "user_id":31,

    "zipcode":[94477,94536]

}

データがblobとして格納されている場合でも、郵便番号が配列として直接格納されている場合でも、特定の郵便番号がどの行に存在するかを判断するためのmulti-value indexを作成することができます。

このインデックスは、JSONデータを論理的に解析して、生成されたカラムとそのカラムのセカンダリインデックスを生成する式を使用して作成されます。JSONをblobとして格納し、複数レベルのネストを横断するクエリを実行する必要がある場合でも、単にこの横断を行うインデックスを作成し、見つかった値でフィルタリングするだけです。

使用方法と考慮事項の詳細については、Multi-value indexのドキュメントをご参照ください。

TTLの高速化 (GA)

TiDB 6.5のリリースブログで実験的な機能として紹介されていましたが、今回の安定版でGAになりました。TiDB 6.5ですでに安定していましたが、この機能のGAでは、TiDBノード間で並列実行することで、より良いパフォーマンスとリソース利用を実現します。これにより、クラスタ内のデータをスキャンして削除するために多くのタスクを発行する作業を、TiDBノードで共有することができます。並行処理可能なタスクの数は設定可能です。また、適切なオブザーバビリティを得るために、この機能に関連する多くのメトリクスが用意されています。

レイトマテリアライゼーションでアナリティクスの高速化

TiDBのカラムナストレージエンジンであるTiFlashは、このバージョンでレイトマテリアライゼーションをGA化しました。TiFlashで処理の対象行が非常に選択性が高い場合、TiDBオプティマイザはレイトマテリアライゼーションを使用することができます。有効にすると、TiDBはテーブルスキャンの一部をプッシュダウンし、フィルター条件を満たす行を選択することができます。その後、データベースは、これらの行のデータに基づいて、さらなる計算のために追加の列をスキャンし、それにより、データ処理のIOスキャンと計算を削減します。この結果、ディスクから読み込まれるデータが少なくなります。

この機能の影響は、ワークロードとデータ分布によります。シナリオによってはレイテンシーを大幅に削減することができます (我々のテストでは最大70％) 。TiDBのQuery Optimizerは、この機能を使うべきかどうかを判断することができるので、デフォルトでオンにしておいても問題ないでしょう。

新しいTiKVアーキテクチャによるスループットの向上とスケーリング時間の短縮 (実験的) 

TiDB 6.6では、TiKVストレージのアーキテクチャに大きな変更を加えました。このアーキテクチャはまだ実験的なものであり、デフォルトではオフになっており、新規のクラスタでのみ有効にすることができます。

TiDB 6.6以前のストレージアーキテクチャは、各キーレンジ (TiKV “リージョン”) がノード内の単一のストレージエンジンを共有するものでした。新しいアーキテクチャでは、すべてのキーレンジ (シャードとも呼ばれる) を物理的に分離し、それぞれにストレージエンジンのインスタンスを持たせています。新しいアーキテクチャのメリットは非常に大きいです：

• 各シャードを各ノードのストレージエンジンに分離することで、書き込みがより分散され、スループットが向上します。一部のテストでは、書き込みスループットが300％近く向上しました。
• また、分離されたことで、ワークロードの干渉を複数の方法で緩和することができます。あるシャードのデータのコンパクションは、別のシャードのデータのファイルを必要とせず、干渉もしないため、ノード上でのコンパクションがより影響が少ないものになります。
• さらに、この変更により、ノードからノードへのシャードのスナップショットや移動も容易になり、クラスタのスケーリングが500%以上速くなりました。
• 実際にお客様のワークロードをテストしたところ、この新しいアーキテクチャでは、テールレイテンシーがほぼ半減しています。
• 最後に、この新アーキテクチャは、単一のクラスタのスケール可能な最大値を高めるために設計された、より多くの機能の基礎となるものです。

TiDB 7.1では、上記のパフォーマンスメリットの安定性を向上させ、ネットワークトラフィックの最適化を追加しています。この機能は、TiCDC、Backup & Restore、Lightning (インポート) などのツールでサポートを追加した時点でGA化する予定です。

詳細については、このアーキテクチャに関するドキュメントをご参照ください。

オンラインDDLの大幅な改善 (実験的) 

TiDB 6.5のリリースブログでは、ADD INDEXの高速化を導入し、その操作の速度を10倍向上させました。TiDB 7.0では、point-in-time recovery (PiTR) と互換性を持たせることで、この機能をGA化しました。安定版TiDB 7.1では、上記のTTLの改善と同様に、TiDBノードにDDLジョブを分散させるフレームワークを導入し、さらに性能を向上させました。

TiDB 7.1: 利用開始と詳細について

TiDBの最新LTS版であるTiDB 7.1では、これらの革新的なエンタープライズグレードの機能を提供できることを嬉しく思っています。さらに詳しい情報をご覧になりたい方は、今すぐTiDBをお試しください。

• TiDB 7.1 LTSをダウンロードする – インストールは数分で完了します。
• TiDB Slackコミュニティに参加すると、他のTiDBの実務家やエキスパートとの交流や、私たちのエンジニアリングチームとのリアルタイムのディスカッションができます。