TiDB 5.0 の新機能
発売日：2021年4月7日
TiDB バージョン: 5.0.0
v5.0 では、PingCAP は、企業が TiDB に基づいてアプリケーションを迅速に構築できるよう支援することに専念しており、データベースのパフォーマンス、パフォーマンスのジッター、セキュリティ、高可用性、災害復旧、SQL パフォーマンスのトラブルシューティングなどに関する心配から解放されます。
v5.0 の主な新機能または改善点は次のとおりです。
- TiFlash ノードを介して超並列処理 (MPP)アーキテクチャを導入します。これにより、TiFlash ノード間で大規模な結合クエリの実行ワークロードが共有されます。 MPP モードが有効になっている場合、TiDB は、コストに基づいて、MPP フレームワークを使用して計算を実行するかどうかを決定します。 MPP モードでは、計算中に結合キーが
Exchangeの操作で再配布されるため、各 TiFlash ノードに計算負荷が分散され、計算が高速化されます。ベンチマークによると、同じクラスター リソースで、TiDB 5.0 MPP は Greenplum 6.15.0 および Apache Spark 3.1.1 よりも 2 倍から 3 倍の速度向上を示し、一部のクエリは 8 倍のパフォーマンスを示します。 - クラスター化インデックス機能を導入して、データベースのパフォーマンスを向上させます。たとえば、TPC-C tpmC テストでは、クラスター化インデックスが有効になっている TiDB のパフォーマンスが 39% 向上しています。
- 非同期コミット機能を有効にして、書き込みレイテンシーを短縮します。たとえば、64 スレッドの Sysbench テストでは、非同期コミットを有効にしたインデックス更新の平均レイテンシーは、12.04 ミリ秒から 7.01 ミリ秒に 41.7% 短縮されました。
- ジッターを減らします。これは、オプティマイザの安定性を向上させ、システム タスクによる I/O、ネットワーク、CPU、およびメモリ リソースの使用を制限することによって実現されます。たとえば、8 時間のパフォーマンス テストでは、TPC-C tpmC の標準偏差は 2% を超えません。
- スケジューリングを改善し、実行計画を可能な限り安定させて、システムの安定性を高めます。
- Raft Joint Consensus アルゴリズムを導入し、リージョンメンバーシップの変更中にシステムの可用性を確保します。
- データベース管理者 (DBA) が SQL ステートメントをより効率的にデバッグするのに役立つ最適化
EXPLAIN機能と非表示のインデックス。 - 企業データの信頼性を保証します。 TiDB から Amazon S3 ストレージおよび Google Cloud GCS にデータをバックアップしたり、これらのクラウド ストレージ プラットフォームからデータを復元したりできます。
- Amazon S3 ストレージまたは TiDB/MySQL からのデータ インポートまたはデータ エクスポートのパフォーマンスを向上させ、企業がクラウド上でアプリケーションを迅速に構築するのに役立ちます。たとえば、TPC-C テストでは、1 TiB のデータをインポートするパフォーマンスが 254 GiB/h から 366 GiB/h に 40% 向上します。
互換性の変更
システム変数
tidb_executor_concurrencyシステム変数を追加して、複数のオペレーターの同時実行を制御します。前のtidb_*_concurrencyの設定 (tidb_projection_concurrencyなど) は引き続き有効ですが、使用すると警告が表示されます。tidb_skip_ascii_checkシステム変数を追加して、ASCII 文字セットが書き込まれるときに ASCII 検証チェックをスキップするかどうかを指定します。このデフォルト値はOFFです。tidb_enable_strict_double_type_checkシステム変数を追加して、double(N)のような構文をテーブル スキーマで定義できるかどうかを判断します。このデフォルト値はOFFです。デフォルト値の
tidb_dml_batch_sizeを20000から0に変更します。これは、バッチ DML ステートメントがINSERT INTO SELECT ...ではデフォルトで使用されなくなったことを意味しLOAD。代わりに、厳密なACIDセマンティクスに準拠するために大規模なトランザクションが使用されます。ノート：
変数のスコープがセッションからグローバルに変更され、デフォルト値が
20000から0に変更されました。アプリケーションが元のデフォルト値に依存している場合は、set globalステートメントを使用して、アップグレード後に変数を元の値に変更する必要があります。tidb_enable_noop_functionsシステム変数を使用して、一時テーブルの構文の互換性を制御します。この変数値がOFFの場合、CREATE TEMPORARY TABLE構文はエラーを返します。次のシステム変数を追加して、ガベージ コレクション関連のパラメーターを直接制御します。
デフォルト値の
enable-joint-consensusをfalseからtrueに変更します。これにより、ジョイント コンセンサス機能がデフォルトで有効になります。tidb_enable_amend_pessimistic_txnの値を0または1からONまたはOFFに変更します。次の新しい意味で、デフォルト値の
tidb_enable_clustered_indexをOFFからINT_ONLYに変更します。ON: クラスター化インデックスが有効です。非クラスター化インデックスの追加または削除がサポートされています。OFF: クラスター化インデックスは無効です。非クラスター化インデックスの追加または削除がサポートされています。INT_ONLY: デフォルト値。この動作は、v5.0 より前の動作と一致しています。alter-primary-key = falseと共に INT 型のクラスター化インデックスを有効にするかどうかを制御できます。ノート：
5.0 GA の
INT_ONLYの値tidb_enable_clustered_indexは、5.0 RC のOFFの値と同じ意味を持ちます。OFF設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、INT_ONLYと表示されます。
Configuration / コンフィグレーションファイルのパラメーター
- TiDB の構成項目を
index-limit追加します。その値のデフォルトは64で、範囲は[64,512]です。 MySQL テーブルは最大 64 個のインデックスをサポートします。その値がデフォルト設定を超え、テーブルに対して 64 を超えるインデックスが作成された場合、テーブル スキーマが MySQL に再インポートされると、エラーが報告されます。 - TiDB の構成項目を
enable-enum-length-limit追加して、MySQL の ENUM/SET の長さと互換性を保ち、一貫性を持たせます (ENUM の長さ < 255)。デフォルト値はtrueです。 pessimistic-txn.enable構成項目をtidb_txn_mode環境変数に置き換えます。performance.max-memoryの構成アイテムをperformance.server-memory-quotaに置き換えますtikv-client.copr-cache.enable構成アイテムをtikv-client.copr-cache.capacity-mbに置き換えます。項目の値が0.0の場合、この機能は無効になっています。アイテムの値が0.0より大きい場合、この機能は有効になります。デフォルト値は1000.0です。rocksdb.auto-tuned構成アイテムをrocksdb.rate-limiter-auto-tunedに置き換えます。raftstore.sync-log構成アイテムを削除します。デフォルトでは、書き込まれたデータは強制的にディスクにスピルされます。 v5.0 より前では、明示的にraftstore.sync-logを無効にすることができます。 v5.0 以降、構成値は強制的にtrueに設定されます。gc.enable-compaction-filter構成アイテムのデフォルト値をfalseからtrueに変更します。enable-cross-table-merge構成アイテムのデフォルト値をfalseからtrueに変更します。rate-limiter-auto-tuned構成アイテムのデフォルト値をfalseからtrueに変更します。
その他
- アップグレードの前に、TiDB 構成の値を確認してください
feedback-probability。値が 0 でない場合、アップグレード後に「回復可能なゴルーチンでpanic」エラーが発生しますが、このエラーはアップグレードには影響しません。 - データの正確性の問題を回避するために、列の型の変更中に
VARCHAR型とCHAR型の間の変換を禁止します。
新機能
SQL
List パーティショニング(実験的)
リスト パーティショニング機能を使用すると、大量のデータを含むテーブルを効果的にクエリおよび維持できます。
この機能を有効にすると、パーティションとパーティション間でのデータの分散方法がPARTITION BY LIST(expr) PARTITION part_name VALUES IN (...)式に従って定義されます。分割されたテーブルのデータ セットは、最大 1024 の個別の整数値をサポートします。 PARTITION ... VALUES IN (...)句を使用して値を定義できます。
リスト パーティショニングを有効にするには、セッション変数tidb_enable_list_partitionをONに設定します。
List COLUMNS パーティショニング(実験的)
List COLUMNS パーティショニングは、リスト パーティショニングの一種です。複数の列をパーティション キーとして使用できます。整数データ型のほかに、string、 DATE 、およびDATETIMEデータ型の列をパーティション列として使用することもできます。
List COLUMNS パーティショニングを有効にするには、セッション変数をtidb_enable_list_partitionからONに設定します。
見えないインデックス
パフォーマンスを調整するとき、または最適なインデックスを選択するときに、SQL ステートメントを使用してインデックスをVisibleまたはInvisibleに設定できます。この設定により、リソースを消費する操作 ( DROP INDEXやADD INDEXなど) の実行を回避できます。
インデックスの可視性を変更するには、 ALTER INDEXステートメントを使用します。変更後、オプティマイザーは、インデックスの可視性に基づいて、このインデックスをインデックス リストに追加するかどうかを決定します。
EXCEPTおよびINTERSECT演算子
INTERSECT演算子は集合演算子であり、2 つ以上のクエリの結果セットの共通部分を返します。ある程度、これはInner Join演算子の代わりになります。
EXCEPT演算子はセット演算子で、2 つのクエリの結果セットを結合し、最初のクエリ結果には含まれるが 2 番目のクエリ結果には含まれない要素を返します。
取引
ペシミスティック トランザクション モードでは、トランザクションに関連するテーブルに同時 DDL 操作またはSCHEMA VERSIONの変更が含まれている場合、システムはトランザクションのSCHEMA VERSIONを最新のものに自動的に更新して、トランザクションのコミットが成功するようにし、クライアントがInformation schema is changedのエラーを受け取るのを回避します。トランザクションは、DDL 操作またはSCHEMA VERSIONの変更によって中断されます。
この機能はデフォルトで無効になっています。この機能を有効にするには、 tidb_enable_amend_pessimistic_txnのシステム変数の値を変更します。この機能は v4.0.7 で導入され、v5.0 で次の問題が修正されています。
- TiDB Binlogが
Add Columnの操作を実行するときに発生する互換性の問題 - この機能を一意のインデックスと一緒に使用するときに発生するデータの不整合の問題
- 追加されたインデックスと一緒に機能を使用するときに発生するデータの不整合の問題
現在、この機能にはまだ次の非互換性の問題があります。
- 同時トランザクションがある場合、トランザクションのセマンティクスが変わる可能性があります
- この機能を TiDB Binlogと一緒に使用する場合に発生する既知の互換性の問題
Change Columnとの非互換性
文字セットと照合順序
安全
セキュリティ コンプライアンス要件 (一般データ保護規則(GDPR) など) を満たすために、システムは、出力エラー メッセージとログで情報 (ID やクレジット カード番号など) の感度を下げることをサポートしています。これにより、機密情報の漏洩を防ぐことができます。
TiDB は、出力ログ情報の感度を下げることをサポートしています。この機能を有効にするには、次のスイッチを使用します。
- グローバル変数
tidb_redact_log.デフォルト値は0で、感度低下が無効になっていることを意味します。 tidb-server ログの感度低下を有効にするには、変数の値を1に設定します。 - 設定項目
security.redact-info-log．デフォルト値はfalseで、感度低下が無効になっていることを意味します。 tikv-server ログの感度低下を有効にするには、変数の値をtrueに設定します。 - 設定項目
security.redact-info-log．デフォルト値はfalseで、感度低下が無効になっていることを意味します。 pd-server ログの感度低下を有効にするには、変数の値をtrueに設定します。 - tiflash-server の設定項目
security.redact_info_logと tiflash-learner の設定項目security.redact-info-log。デフォルト値はどちらもfalseで、感度低下が無効になっていることを意味します。 tiflash-server および tiflash-learner ログの感度低下を有効にするには、両方の変数の値をtrueに設定します。
この機能は v5.0 で導入されました。この機能を使用するには、システム変数と上記のすべての構成項目を有効にします。
パフォーマンスの最適化
MPPアーキテクチャ
TiDB は、TiFlash ノードを通じて MPPアーキテクチャを導入します。このアーキテクチャにより、複数の TiFlash ノードが大規模な結合クエリの実行ワークロードを共有できます。
MPP モードがオンの場合、TiDB は、計算コストに基づいて、計算のためにクエリを MPP エンジンに送信するかどうかを決定します。 MPP モードでは、TiDB はデータ計算 ( Exchange操作) 中に結合キーを再配布することにより、実行中の各 TiFlash ノードにテーブル結合の計算を分散し、計算を高速化します。さらに、TiFlash がすでにサポートしているアグリゲーション コンピューティング機能を使用して、TiDB はクエリの計算を TiFlash MPP クラスターにプッシュダウンできます。次に、分散環境は、実行プロセス全体を高速化し、分析クエリの速度を劇的に向上させるのに役立ちます。
TPC-H 100 ベンチマーク テストでは、TiFlash MPP は、従来の分析データベースの分析エンジンや Hadoop 上の SQL よりも大幅な処理速度を実現しています。このアーキテクチャにより、大規模な分析クエリを最新のトランザクション データに対して直接実行でき、従来のオフライン分析ソリューションよりも高いパフォーマンスを実現できます。ベンチマークによると、同じクラスター リソースで、TiDB 5.0 MPP は Greenplum 6.15.0 および Apache Spark 3.1.1 よりも 2 倍から 3 倍の速度向上を示し、一部のクエリは 8 倍のパフォーマンスを示します。
現在、MPP モードがサポートしていない主な機能は次のとおりです (詳細については、 TiFlash を使用するを参照してください)。
- テーブルの分割
- ウィンドウ関数
- 照合
- 一部の組み込み関数
- TiKV からのデータの読み取り
- OOM流出
- 連合
- 完全外部結合
クラスタ化されたインデックス
テーブル構造を設計したり、データベースの動作を分析したりするときに、主キーを持つ一部の列がグループ化およびソートされることが多く、これらの列に対するクエリが特定の範囲のデータまたは少量のデータを返すことが多い場合は、クラスター化インデックス機能を使用することをお勧めします。値が異なるデータの場合、対応するデータによって読み取りまたは書き込みのホットスポットの問題が発生することはありません。
一部のデータベース管理システムではインデックス構成テーブルとも呼ばれるクラスター化インデックスは、テーブルのデータに関連付けられたストレージ構造です。クラスター化インデックスを作成するときは、テーブルから 1 つ以上の列をインデックスのキーとして指定できます。 TiDB はこれらのキーを特定の構造に格納します。これにより、TiDB はキーに関連付けられた行を迅速かつ効率的に見つけることができるため、データのクエリと書き込みのパフォーマンスが向上します。
クラスター化インデックス機能を有効にすると、次の場合に TiDB のパフォーマンスが大幅に向上します (たとえば、TPC-C tpmC テストでは、クラスター化インデックスを有効にした TiDB のパフォーマンスが 39% 向上します)。
- データが挿入されると、クラスター化インデックスは、ネットワークからのインデックス データの 1 回の書き込みを減らします。
- 同等の条件を持つクエリに主キーのみが含まれる場合、クラスター化インデックスは、ネットワークからのインデックス データの 1 回の読み取りを減らします。
- 範囲条件を含むクエリに主キーのみが含まれる場合、クラスター化インデックスにより、ネットワークからのインデックス データの複数回の読み取りが削減されます。
- 同等または範囲条件を含むクエリに主キー プレフィックスが含まれる場合、クラスター化インデックスは、ネットワークからのインデックス データの複数回の読み取りを減らします。
各テーブルは、クラスター化インデックスまたは非クラスター化インデックスのいずれかを使用して、データを並べ替えて格納できます。これら 2 つのストレージ構造の違いは次のとおりです。
- クラスター化インデックスを作成する場合、テーブル内の 1 つ以上の列をインデックスのキー値として指定できます。クラスター化インデックスは、キー値に従ってテーブルのデータを並べ替えて格納します。各テーブルは、クラスター化インデックスを 1 つだけ持つことができます。テーブルにクラスター化インデックスがある場合、それはクラスター化インデックス テーブルと呼ばれます。それ以外の場合は、非クラスター化インデックス テーブルと呼ばれます。
- 非クラスター化インデックスを作成すると、テーブル内のデータは順不同の構造で格納されます。 TiDB は一意の ROWID をデータの各行に自動的に割り当てるため、非クラスター化インデックスのキー値を明示的に指定する必要はありません。クエリ中、ROWID は対応する行を見つけるために使用されます。データのクエリまたは挿入時に少なくとも 2 つのネットワーク I/O 操作があるため、クラスター化インデックスと比較してパフォーマンスが低下します。
テーブル データが変更されると、データベース システムはクラスター化インデックスと非クラスター化インデックスを自動的に維持します。
デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。次の 2 つの方法のいずれかで、主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成できます。
- テーブルを作成するときにステートメントにキーワード
CLUSTERED | NONCLUSTEREDを指定すると、システムは指定された方法でテーブルを作成します。構文は次のとおりです。
CREATE TABLE `t` (`a` VARCHAR(255), `b` INT, PRIMARY KEY (`a`, `b`) CLUSTERED);
または
CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT);
ステートメントSHOW INDEX FROM tbl-nameを実行して、テーブルにクラスター化インデックスがあるかどうかを照会できます。
- クラスター化インデックス機能を制御するには、システム変数
tidb_enable_clustered_indexを構成します。サポートされている値はON、OFF、およびINT_ONLYです。ON: すべての種類の主キーに対してクラスター化インデックス機能が有効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。OFF: すべての種類の主キーに対してクラスター化インデックス機能が無効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。INT_ONLY: デフォルト値。変数がINT_ONLYに設定され、alter-primary-keyがfalseに設定されている場合、デフォルトでは、単一の整数列で構成される主キーがクラスター化インデックスとして作成されます。この動作は、TiDB v5.0 以前のバージョンの動作と一致しています。
CREATE TABLEステートメントにキーワードCLUSTERED | NONCLUSTEREDが含まれている場合、ステートメントはシステム変数と構成アイテムの構成をオーバーライドします。
ステートメントでキーワードCLUSTERED | NONCLUSTEREDを指定して、クラスター化インデックス機能を使用することをお勧めします。このようにして、TiDB が必要に応じて同時にシステム内のクラスター化および非クラスター化インデックスのすべてのデータ型を使用することがより柔軟になります。
tidb_enable_clustered_index = INT_ONLYの使用はお勧めしませんINT_ONLYはこの機能の互換性を保つために一時的に使用されており、将来的には非推奨になるためです。
クラスター化インデックスの制限は次のとおりです。
- クラスター化インデックスと非クラスター化インデックス間の相互変換はサポートされていません。
- クラスター化インデックスの削除はサポートされていません。
ALTER TABLEステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。- クラスター化インデックスの再編成と再作成はサポートされていません。
- インデックスの有効化または無効化はサポートされていません。つまり、インデックスの非表示機能は、クラスター化されたインデックスに対して有効ではありません。
- クラスター化インデックスとして
UNIQUE KEYを作成することはサポートされていません。 - クラスター化インデックス機能を TiDB Binlogと一緒に使用することはサポートされていません。 TiDB Binlogを有効にすると、TiDB はクラスター化インデックスとして単一の整数主キーの作成のみをサポートします。 TiDB Binlogは、クラスター化されたインデックスを持つ既存のテーブルのデータ変更をダウンストリームに複製しません。
- クラスター化インデックス機能を属性
SHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSと共に使用することはサポートされていません。 - クラスターを新しいバージョンにアップグレードしてからロールバックする場合は、ロールバックの前にテーブル データをエクスポートし、ロールバック後にデータをインポートして、新しく追加されたテーブルをダウングレードする必要があります。他のテーブルは影響を受けません。
非同期コミット
データベースのクライアントは、データベース システムがトランザクション コミットを 2 フェーズ (2PC) で同期的に完了するまで待機します。トランザクションは、第 1 フェーズのコミットが成功した後にクライアントに結果を返し、システムは第 2 フェーズのコミット操作をバックグラウンドで非同期的に実行して、トランザクション コミットのレイテンシーを短縮します。トランザクション書き込みに含まれるリージョンが 1 つだけの場合、2 番目のフェーズは直接省略され、トランザクションは 1 フェーズ コミットになります。
Async Commit 機能を有効にした後、同じハードウェアと構成で、Sysbench が 64 スレッドで更新インデックスをテストするように設定されている場合、平均レイテンシーは 12.04 ミリ秒から 7.01 ミリ秒に 41.7% 減少します。
Async Commit 機能が有効になっている場合、1 つのネットワーク対話のレイテンシーを短縮し、データ書き込みのパフォーマンスを向上させるために、データベース アプリケーションの開発者は、トランザクションの一貫性を線形の一貫性から因果の一貫性に減らすことを検討することをお勧めします。因果整合性を有効にする SQL ステートメントはSTART TRANSACTION WITH CAUSAL CONSISTENCYです。
原因の一貫性が有効になった後、同じハードウェアと構成で、Sysbench が oltp_write_only を 64 スレッドでテストするように設定されている場合、平均レイテンシーは 11.86ms から 11.19ms に 5.6% 減少しました。
トランザクションの一貫性が線形一貫性から因果的一貫性に低下した後、アプリケーション内の複数のトランザクション間に相互依存関係がない場合、トランザクションはグローバルに一貫した順序を持ちません。
非同期コミット機能は、新しく作成された v5.0 クラスターに対してデフォルトで有効になっています。
以前のバージョンから v5.0 にアップグレードされたクラスターでは、この機能はデフォルトで無効になっています。この機能を有効にするには、 set global tidb_enable_async_commit = ON;ステートメントとset global tidb_enable_1pc = ON;ステートメントを実行します。
非同期コミット機能の制限は次のとおりです。
- 直接のダウングレードはサポートされていません。
デフォルトでコプロセッサーのキャッシュ機能を有効にする
5.0 GA では、コプロセッサーのキャッシュ機能がデフォルトで有効になっています。この機能を有効にすると、データ読み取りのレイテンシーを短縮するために、TiDB は tikv-server にプッシュされたオペレーターの計算結果を tidb-server にキャッシュします。
コプロセッサーのキャッシュ機能を無効にするには、 tikv-client.copr-cacheから0.0のcapacity-mbの構成項目を変更します。
delete from table where id <? Limit ?の実行パフォーマンスを改善delete from table where id <? Limit ?声明
delete from table where id <? limit ?ステートメントの p99 パフォーマンスは 4 倍向上します。
負荷ベースの分割戦略を最適化して、一部の小さなテーブルのホットスポット読み取りシナリオでデータを分割できないというパフォーマンスの問題を解決します
安定性の向上
不完全なスケジューリングによって引き起こされるパフォーマンス ジッターの問題を最適化する
TiDB スケジューリング プロセスは、I/O、ネットワーク、CPU、メモリなどのリソースを占有します。 TiDB がスケジュールされたタスクを制御しない場合、QPS と遅延により、リソースのプリエンプションが原因でパフォーマンスのジッターが発生する可能性があります。
次の最適化の後、8 時間のパフォーマンス テストで、TPC-C tpmC の標準偏差は 2% を超えません。
不要なスケジューリングとパフォーマンス ジッタを削減するための新しいスケジューリング計算式の導入
ノード容量がシステムで設定されたウォーターラインに常に近い場合、またはstore-limitが大きすぎて容量負荷のバランスを取る場合、システムは頻繁にリージョンを他のノードにスケジュールしたり、リージョンを元のノードに戻したりします。スケジューリングは I/O、ネットワーク、CPU、メモリなどのリソースを占有し、パフォーマンスのジッターを引き起こすため、このタイプのスケジューリングは必要ありません。
この問題を軽減するために、PD は新しい一連の既定のスケジュール計算式を導入します。 region-score-formula-version = v1を構成することで、古い式に戻すことができます。
デフォルトでクロステーブルのリージョン結合機能を有効にする
v5.0 より前では、TiDB はクロステーブルのリージョンマージ機能をデフォルトで無効にしています。 v5.0 以降、この機能はデフォルトで有効になっており、空のリージョンの数と、ネットワーク、メモリ、および CPU のオーバーヘッドを削減します。この機能を無効にするには、 schedule.enable-cross-table-mergeの構成アイテムを変更します。
システムがデフォルトでデータ圧縮速度を自動的に調整できるようにして、バックグラウンド タスクとフォアグラウンドの読み取りおよび書き込みの間の I/O リソースの競合のバランスをとります。
v5.0 より前では、バックグラウンド タスクとフォアグラウンドの読み取りおよび書き込みの間の I/O リソースの競合のバランスをとるために、システムがデータ圧縮速度を自動的に調整する機能がデフォルトで無効になっています。 v5.0 から、TiDB はデフォルトでこの機能を有効にし、アルゴリズムを最適化して、レイテンシーのジッターを大幅に削減します。
この機能を無効にするには、 rate-limiter-auto-tunedの構成アイテムを変更します。
デフォルトで GC 圧縮フィルター機能を有効にして、GC の CPU および I/O リソースの消費を削減します。
TiDB がガベージ コレクション (GC) とデータ圧縮を実行するとき、パーティションは CPU と I/O リソースを占有します。これら 2 つのタスクの実行中に重複データが存在します。
GC の CPU および I/O リソースの消費を削減するために、GC 圧縮フィルター機能はこれら 2 つのタスクを 1 つに結合し、同じタスクで実行します。この機能はデフォルトで有効になっています。 gc.enable-compaction-filter = falseを設定することで無効にできます。
TiFlash は、圧縮とデータの並べ替えによる I/O リソースの使用を制限します (実験的機能)。
この機能により、バックグラウンド タスクとフォアグラウンドの読み取りおよび書き込みの間の I/O リソースの競合が軽減されます。
この機能はデフォルトで無効になっています。この機能を有効にするには、 bg_task_io_rate_limitの構成アイテムを変更します。
スケジューリングの制約をチェックするパフォーマンスと、大規模なクラスター内の異常なリージョンを修正するパフォーマンスを向上させます
パフォーマンスのジッターを回避するために、実行計画を可能な限り変更しないようにします。
SQL バインディングはINSERT 、 REPLACE 、 UPDATE 、 DELETEステートメントをサポートします
パフォーマンスのチューニングまたはデータベースの保守時に、不安定な実行計画のためにシステムのパフォーマンスが不安定であることが判明した場合は、判断に従って手動で最適化された SQL ステートメントを選択するか、またはEXPLAIN ANALYZEでテストすることができます。最適化された SQL ステートメントを、アプリケーション コードで実行される SQL ステートメントにバインドして、安定したパフォーマンスを確保できます。
SQL BINDING ステートメントを使用して手動で SQL ステートメントをバインドする場合は、最適化された SQL ステートメントが元の SQL ステートメントと同じ構文であることを確認する必要があります。
SHOW {GLOBAL | SESSION} BINDINGSコマンドを実行すると、手動または自動でバインドされた実行計画の情報を表示できます。出力は v5.0 より前のバージョンと同じです。
実行計画を自動的に取得してバインドする
TiDB をアップグレードする場合、パフォーマンスのジッタを回避するために、ベースライン キャプチャ機能を有効にして、システムが最新の実行計画を自動的にキャプチャしてバインドし、システム テーブルに保存できるようにすることができます。 TiDB がアップグレードされた後、 SHOW GLOBAL BINDINGコマンドを実行してバインドされた実行計画をエクスポートし、これらの計画を削除するかどうかを決定できます。
この機能はデフォルトで無効になっています。サーバーを変更するか、グローバルシステム変数tidb_capture_plan_baselinesをONに設定することで有効にできます。この機能を有効にすると、システムはステートメントの概要から少なくとも 2 回出現する SQL ステートメントをbind-info-lease (デフォルト値は3s ) ごとにフェッチし、これらの SQL ステートメントを自動的にキャプチャしてバインドします。
TiFlash クエリの安定性を向上
システム変数tidb_allow_fallback_to_tikvを追加して、TiFlash が失敗したときにクエリを TiKV にフォールバックします。デフォルト値はOFFです。
TiCDC の安定性を向上させ、過剰な増分データの複製によって引き起こされる OOM の問題を軽減します
TiCDC v4.0.9 以前のバージョンでは、あまりにも多くのデータ変更をレプリケートすると、OOM が発生する可能性があります。 v5.0 では、Unified Sorter 機能がデフォルトで有効になっており、次のシナリオによって発生する OOM の問題を軽減しています。
- TiCDC のデータ レプリケーション タスクは長時間一時停止されます。その間、大量の増分データが蓄積され、レプリケートする必要があります。
- データ複製タスクは早いタイムスタンプから開始されるため、大量の増分データを複製する必要があります。
Unified Sorter は、以前のバージョンのmemory / fileソート エンジン オプションと統合されています。変更を手動で構成する必要はありません。
制限:
- 増分データの量に応じて、十分なディスク容量を用意する必要があります。空き容量が 128 GB を超える SSD を使用することをお勧めします。
高可用性と災害復旧
リージョンメンバーシップの変更中のシステムの可用性を向上させる
ユーザー文書 、 #18079 、 #7587 、 #2860
リージョンメンバーシップの変更プロセスでは、「メンバーの追加」と「メンバーの削除」の 2 つの操作が 2 つのステップで実行されます。メンバーシップの変更が完了するときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンド アプリケーションのエラーが返されます。
導入されたRaft Joint Consensus アルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。会員変更時の「会員追加」「会員削除」の操作をまとめて全会員に送信します。変更プロセス中、リージョンは中間状態にあります。変更されたメンバーに障害が発生した場合でも、システムは引き続き使用できます。
この機能はデフォルトで有効になっています。 pd-ctl config set enable-joint-consensusコマンドを実行してenable-joint-consensusの値をfalseに設定することで無効にできます。
メモリ管理モジュールを最適化して、システム OOM のリスクを軽減します
集計関数のメモリ使用量を追跡します。この機能はデフォルトで有効になっています。集計関数を含む SQL ステートメントが実行されるときに、現在のクエリの合計メモリ使用量がmem-quota-queryで設定されたしきい値を超えると、システムはoom-actionで定義された操作を自動的に実行します。
ネットワーク パーティション中のシステムの可用性を向上させる
データ移行
S3/ Auroraから TiDB にデータを移行する
TiDB データ移行ツールは、Amazon S3 (およびその他の S3 互換ストレージ サービス) をデータ移行の中間として使用し、 Auroraスナップショット データを直接 TiDB に初期化することをサポートし、Amazon S3/ Auroraから TiDB にデータを移行するためのより多くのオプションを提供します。
この機能を使用するには、次のドキュメントを参照してください。
TiDB Cloudのデータ インポート パフォーマンスを最適化する
TiDB Lightningは、 TiDB Cloudの AWS T1.standard 構成 (または同等の構成) に特化してデータ インポート パフォーマンスを最適化します。テスト結果は、 TiDB Lightningが 1 TB の TPC-C データを TiDB にインポートする速度を 254 GiB/h から 366 GiB/h に 40% 向上させることを示しています。
データの共有と購読
TiCDC を使用して TiDB を Kafka Connect (Confluent Platform) に統合 (実験的機能)
TiDB データを他のシステムにストリーミングするビジネス要件をサポートするために、この機能を使用すると、TiDB データを Kafka、Hadoop、Oracle などのシステムにストリーミングできます。
Confluent プラットフォームによって提供される Kafka コネクタ プロトコルは、コミュニティで広く使用されており、さまざまなプロトコルでのリレーショナル データベースまたは非リレーショナル データベースへのデータ転送をサポートしています。 TiCDC を Confluent プラットフォームの Kafka Connect に統合することで、TiDB は TiDB データを他の異種データベースまたはシステムにストリーミングする機能を拡張します。
診断
SQL パフォーマンスの問題のトラブルシューティングでは、パフォーマンスの問題の原因を特定するために詳細な診断情報が必要です。 TiDB 5.0 より前では、 EXPLAINステートメントによって収集された情報は十分に詳細ではありませんでした。問題の根本原因は、ログ情報、監視情報、さらには推測に基づいてしか判断できないため、非効率的である可能性があります。
TiDB v5.0 では、パフォーマンスの問題をより効率的にトラブルシューティングできるように、次の改善が行われています。
EXPLAIN ANALYZEステートメントを使用してすべての DML ステートメントを分析し、実際のパフォーマンス プランと各オペレーターの実行情報を表示することをサポートします。 #18056EXPLAIN FOR CONNECTIONステートメントを使用して、実行中のすべての SQL ステートメントのリアルタイム ステータスをチェックすることをサポートします。たとえば、ステートメントを使用して、各演算子の実行時間と処理された行数を確認できます。 #18233- オペレーターによって送信された RPC リクエストの数、ロックの競合を解決する期間、ネットワークレイテンシー、RocksDB 内の削除されたデータのスキャンされた量、RocksDB のヒット率など、
EXPLAIN ANALYZEステートメントの出力でオペレーターの実行に関する詳細を提供します。キャッシュします。 #18663 - スローログに SQL ステートメントの詳細な実行情報を自動的に記録するサポート。スローログの実行情報は、
EXPLAIN ANALYZEステートメントの出力情報と一致しています。これには、各オペレーターが消費した時間、処理された行数、および送信された RPC 要求の数が含まれます。 #15009
展開とメンテナンス
クラスター展開操作のロジックを最適化して、DBA が一連の標準的な TiDB 運用クラスターをより迅速に展開できるようにします。
TiDB の以前のバージョンでは、TiUP を使用して TiDB クラスターを展開する DBA は、環境の初期化が複雑で、チェックサム構成が過剰で、クラスター トポロジ ファイルの編集が難しいことに気付きました。これらの問題はすべて、DBA の導入効率の低下につながります。 TiDB v5.0 では、TiUP を使用した TiDB の展開効率が、以下の項目によって DBA 向けに改善されています。
- TiUP クラスタは、より包括的なワンクリック環境チェックを実行し、修復の推奨事項を提供する
check topo.yamlコマンドをサポートしています。 - TiUP クラスタは、環境チェック中に検出された環境問題を自動的に修復する
check topo.yaml --applyのコマンドをサポートしています。 - TiUP クラスタは、DBA がグローバル ノード パラメータの編集と変更をサポートするためのクラスタ トポロジ テンプレート ファイルを取得する
templateコマンドをサポートしています。 - TiUP は、
edit-configコマンドを使用してremote_configパラメータを編集し、リモート Prometheus を構成することをサポートしています。 - TiUP は、
external_alertmanagersパラメータを編集して、edit-configコマンドを使用して異なる AlertManager を設定することをサポートしています。 - tiup-clusterの
edit-configサブコマンドを使用してトポロジ ファイルを編集する場合、構成アイテムの値のデータ型を変更できます。
アップグレードの安定性を向上
TiUP v1.4.0 より前では、 tiup-clusterを使用した TiDB クラスターのアップグレード中に、クラスターの SQL 応答が長時間ジッターし、PD オンライン ローリング アップグレード中に、クラスターの QPS が 10 秒から 30 秒の間でジッターしました。
TiUP v1.4.0 はロジックを調整し、次の最適化を行います。
- PD ノードのアップグレード中、TiUP は再起動された PD ノードのステータスを自動的にチェックし、ステータスが準備完了であることを確認した後、次の PD ノードのアップグレードにロールバックします。
- TiUP は PD ロールを自動的に識別し、最初にフォロワー ロールの PD ノードをアップグレードし、最後に PD リーダー ノードをアップグレードします。
アップグレード時間を最適化する
TiUP v1.4.0 より前では、DBA がtiup-clusterを使用して TiDB クラスターをアップグレードする場合、多数のノードを持つクラスターの場合、アップグレードの合計時間が長くなり、特定のユーザーのアップグレード時間枠の要件を満たすことができません。
v1.4.0 から、TiUP は次の項目を最適化します。
tiup cluster upgrade --offlineサブコマンドを使用した高速オフライン アップグレードをサポートします。- デフォルトでアップグレード中にローリング アップグレードを使用して、ユーザーのリージョンリーダーの再配置を高速化します。これにより、TiKV のローリング アップグレードの時間が短縮されます。
- ローリング アップグレードを実行する前に、
checkサブコマンドを使用してリージョンモニターのステータスを確認します。アップグレードの前にクラスターが正常な状態であることを確認して、アップグレードの失敗の可能性を減らします。
ブレークポイント機能をサポート
TiUP v1.4.0 より前では、DBA がtiup-clusterを使用して TiDB クラスターをアップグレードするときに、コマンドの実行が中断された場合、すべてのアップグレード操作を最初からやり直す必要がありました。
TiUP v1.4.0 は、 tiup-cluster replayサブコマンドを使用してブレークポイントから失敗した操作を再試行することをサポートし、アップグレードの中断後にすべての操作を再実行することを回避します。
保守・運用の機能強化
TiUP v1.4.0 では、TiDB クラスターを運用および保守するための機能がさらに強化されています。
- ダウンタイム TiDB および DM クラスターでのアップグレードまたはパッチ操作をサポートして、より多くの使用シナリオに適応します。
- クラスターのバージョンを取得するために、 tiup-clusterの
displayサブコマンドに--versionパラメーターを追加します。 - スケールアウトするノードに Prometheus のみが含まれる場合、Prometheus ノードが存在しないことによるスケールアウトの失敗を回避するために、監視構成の更新操作は実行されません。
- 入力 TiUP コマンドの結果が正しくない場合にエラー メッセージにユーザー入力を追加して、問題の原因をより迅速に突き止めることができるようにします。
テレメトリー
TiDB は、データ テーブルの数、クエリの数、新しい機能が有効になっているかどうかなど、テレメトリにクラスターの使用状況の指標を追加します。
詳細およびこの動作を無効にする方法については、 テレメトリーを参照してください。