| カテゴリ | 機能／改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | スケーラビリティ向上のためのPDの分解（実験的） | Placement Driver（PD）には、TiDBクラスタの正常な動作を保証するための複数の重要なモジュールが含まれています。クラスタのワークロードが増加すると、PD内の各モジュールのリソース消費量も増加し、これらのモジュール間で相互干渉が発生し、最終的にクラスタ全体のサービス品質に影響を与えます。v8.0.0以降、TiDBはこの問題に対処するため、PD内のTSOモジュールとスケジューリングモジュールを独立してデプロイ可能なマイクロサービスに分割しました。これにより、クラスタの規模が拡大するにつれて、モジュール間の相互干渉を大幅に削減できます。このアーキテクチャにより、より大規模なワークロードを持つ、より大規模なクラスタの構築が可能になりました。 |
| より大規模なトランザクション向けの一括DML（実験的） | 大規模なバッチ DML ジョブ（大規模なクリーンアップ ジョブ、結合、集計など）は、大量のメモリを消費する可能性があり、これまで非常に大規模な処理には制限がありました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、メモリ不足の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データ ロードに使用する場合、インポート、ロード、およびリストア操作とは異なります。 | |
| クラスタスナップショット復元速度の向上（GA） | この機能により、 BRはクラスタの規模の利点を最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備段階に参加できるようになります。この機能は、大規模クラスタにおける大規模データセットの復元速度を大幅に向上させます。実際のテストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。 | |
| テーブル数が膨大な場合のスキーマ情報のキャッシュの安定性を向上させる（実験的） | TiDBをマルチテナントアプリケーションの記録システムとして利用するSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブルを処理することは可能でしたが、ユーザーエクスペリエンス全体が低下する可能性がありました。TiDB v8.0.0では、 auto analyze用の優先度キューを実装することで状況が改善され、処理がより柔軟になり、より幅広いテーブルで安定性が向上します。 | |
| データベースの運用と可観測性 | インデックス使用統計の監視をサポートします | 適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用状況統計情報を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。 |
| データ移行 | TiCDCがSimpleプロトコルのサポートを追加 | TiCDCは、新しいプロトコルであるSimpleプロトコルを導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。 |
| TiCDCはDebeziumフォーマットプロトコルのサポートを追加しました。 | TiCDCは、新しいプロトコルであるDebeziumプロトコルを導入しました。TiCDCは、Debezium形式のメッセージを生成するプロトコルを使用して、データ変更イベントをKafkaシンクに発行できるようになりました。 |
| カテゴリ | 機能／改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | スケーラビリティ向上のためのPDの分離（実験的） | Placement Driver（PD）には、TiDBクラスタの正常な動作を保証するための複数の重要なモジュールが含まれています。クラスタのワークロードが増加すると、PD内の各モジュールのリソース消費量も増加し、これらのモジュール間で相互干渉が発生し、最終的にクラスタ全体のサービス品質に影響を与えます。v8.0.0以降、TiDBはこの問題に対処するため、PD内のTSOモジュールとスケジューリングモジュールを独立してデプロイ可能なマイクロサービスに分割しました。これにより、クラスタの規模が拡大するにつれて、モジュール間の相互干渉を大幅に削減できます。このアーキテクチャにより、より大規模なワークロードを持つ、より大規模なクラスタの構築が可能になりました。 |
| より大規模なトランザクション向けの一括DML（実験的） | 大規模なバッチ DML ジョブ（大規模なクリーンアップ ジョブ、結合、集計など）は、大量のメモリを消費する可能性があり、これまで非常に大規模な処理には制限がありました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、メモリ不足の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データ ロードに使用する場合、インポート、ロード、およびリストア操作とは異なります。 | |
| クラスタスナップショット復元速度の向上（GA） | この機能により、 BRはクラスタの規模の利点を最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備段階に参加できるようになります。この機能は、大規模クラスタにおける大規模データセットの復元速度を大幅に向上させます。実際のテストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。 | |
| テーブル数が膨大な場合のスキーマ情報のキャッシュの安定性を向上させる（実験的） | TiDBをマルチテナントアプリケーションの記録システムとして利用するSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブルを処理することは可能でしたが、ユーザーエクスペリエンス全体が低下する可能性がありました。TiDB v8.0.0では、 auto analyze用の優先度キューを実装することで状況が改善され、処理がより柔軟になり、より幅広いテーブルで安定性が向上します。 | |
| データベースの運用と可観測性 | インデックス使用統計の監視をサポートします | 適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用状況統計情報を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。 |
| データ移行 | TiCDCがSimpleプロトコルのサポートを追加 | TiCDCは、新しいプロトコルであるSimpleプロトコルを導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。 |
| TiCDCはDebeziumフォーマットプロトコルのサポートを追加しました。 | TiCDCは、新しいプロトコルであるDebeziumプロトコルを導入しました。TiCDCは、Debezium形式のメッセージを生成するプロトコルを使用して、データ変更イベントをKafkaシンクに発行できるようになりました。 |
| カテゴリ | 機能／改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | インスタンスレベルの実行プランキャッシュ（実験的） | インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。 |
| パーティションテーブルのグローバルインデックス（GA） | グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。 | |
| TSOリクエストの並列モード | 高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスタのスループットを向上させることができます。 | |
| キャッシュされたテーブルのクエリパフォーマンスを向上させる | キャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。 | |
| 信頼性と可用性 | 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート | 暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。 |
| リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートする | リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。 | |
| TiProxyはトラフィックのキャプチャと再生をサポートします（実験的）。 | TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。 | |
| 同時自動統計収集 | TiDBクラスタ内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスタの安定したパフォーマンスが確保されます。 | |
| SQL | ベクトル検索（実験的） | ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、セマンティック検索、推薦システムなど、さまざまなシナリオで活用できます。 |
| データベースの運用と可観測性 | TiKVとTiDBのCPU時間をメモリテーブルに表示する | CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。 |
| テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。 | ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。 | |
| IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします。 | AWS EC2 では、デフォルトのメタデータサービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリッククラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。 | |
| Security | ログバックアップデータのクライアント側暗号化（実験的） | ログバックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。 |
| カテゴリ | 機能／改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | インスタンスレベルの実行プランキャッシュ（実験的） | インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。 |
| パーティションテーブルのグローバルインデックス（GA） | グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。 | |
| TSOリクエストの並列モード | 高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスタのスループットを向上させることができます。 | |
| キャッシュされたテーブルのクエリパフォーマンスを向上させる | キャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。 | |
| 信頼性と可用性 | 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート | 暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。 |
| リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートする | リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。 | |
| TiProxyはトラフィックのキャプチャと再生をサポートします（実験的） | TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。 | |
| 同時自動統計収集 | TiDBクラスタ内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスタの安定したパフォーマンスが確保されます。 | |
| SQL | ベクトル検索（実験的） | ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核機能の一つとして、ベクトル検索は、検索拡張生成（RAG）、セマンティック検索、推薦システムなど、さまざまなシナリオで活用できます。 |
| データベースの運用と可観測性 | TiKVとTiDBのCPU時間をメモリテーブルに表示する | CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。 |
| テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。 | ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。 | |
| IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします | AWS EC2 では、デフォルトのメタデータサービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリッククラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。 | |
| セキュリティ | ログバックアップデータのクライアント側暗号化（実験的） | ログバックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。 |