TiDB5.0の新機能
発売日：2021年4月7日
TiDBバージョン：5.0.0
v5.0では、PingCAPは、企業がTiDBに基づいてアプリケーションを迅速に構築し、データベースパフォーマンス、パフォーマンスジッター、セキュリティ、高可用性、ディザスタリカバリ、SQLパフォーマンスのトラブルシューティングなどの心配から解放するのを支援することに専念しています。
v5.0では、主な新機能または改善点は次のとおりです。
- TiFlashノードを介して超並列処理（MPP）アーキテクチャを導入します。これは、TiFlashノード間で大規模な結合クエリの実行ワークロードを共有します。 MPPモードが有効になっている場合、TiDBはコストに基づいて、MPPフレームワークを使用して計算を実行するかどうかを決定します。 MPPモードでは、結合キーは計算中に
Exchangeの操作で再分配されます。これにより、計算圧力が各TiFlashノードに分配され、計算が高速化されます。ベンチマークによると、同じクラスタリソースを使用すると、TiDB5.0MPPはGreenplum6.15.0およびApacheSpark3.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アルゴリズムを導入し、リージョンメンバーシップの変更中にシステムの可用性を確保します。
EXPLAINの機能と非表示のインデックスを最適化します。これにより、データベース管理者（DBA）がSQLステートメントをより効率的にデバッグできます。- エンタープライズデータの信頼性を保証します。 TiDBからAmazonS3ストレージとGoogleCloudGCSにデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。
- AmazonS3ストレージまたはTiDB/MySQLからのデータインポートまたはデータエクスポートのパフォーマンスを向上させます。これにより、企業はクラウド上でアプリケーションを迅速に構築できます。たとえば、TPC-Cテストでは、1TiBデータのインポートのパフォーマンスが254GiB/hから366GiB/ 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以前の動作と一致しています。 INTタイプのクラスター化インデックスをalter-primary-key = falseと一緒に有効にするかどうかを制御できます。ノート：
5.0 GAの
tidb_enable_clustered_indexのINT_ONLYの値は、5.0RCのOFFの値と同じ意味です。OFF設定の5.0RCクラスタから5.0GAにアップグレードすると、INT_ONLYと表示されます。
Configuration / コンフィグレーションファイルのパラメーター
- TiDBの
index-limitの構成アイテムを追加します。その値のデフォルトは64で、範囲は[64,512]です。 MySQLテーブルは最大64個のインデックスをサポートします。その値がデフォルト設定を超え、テーブルに対して64を超えるインデックスが作成された場合、テーブルスキーマがMySQLに再インポートされると、エラーが報告されます。 - MySQLのENUM/SETの長さ（ENUMの長さ<255）と互換性があり、一貫性があるように、TiDBの
enable-enum-length-limitの構成項目を追加します。デフォルト値は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でない場合、アップグレード後に「回復可能なゴルーチンのパニック」エラーが発生しますが、このエラーはアップグレードには影響しません。 - データの正確性の問題を回避するために、列タイプの変更中に
VARCHARタイプとCHARタイプの間の変換を禁止します。
新機能
SQL
リストの分割（実験的）
リスト分割機能を使用すると、大量のデータを含むテーブルを効果的に照会および保守できます。
この機能を有効にすると、パーティションとパーティション間でのデータの分散方法がPARTITION BY LIST(expr) PARTITION part_name VALUES IN (...)式に従って定義されます。パーティションテーブルのデータセットは、最大1024個の個別の整数値をサポートします。 PARTITION ... VALUES IN (...)句を使用して値を定義できます。
リストの分割を有効にするには、セッション変数tidb_enable_list_partitionをONに設定します。
COLUMNSパーティショニングのリスト（実験的）
リスト列のパーティショニングは、リストパーティショニングの変形です。複数の列をパーティションキーとして使用できます。整数データ型に加えて、文字列、 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で修正された次の問題があります。
- TiDBBinlogが
Add Columnの操作を実行するときに発生する互換性の問題 - この機能を一意のインデックスと一緒に使用すると発生するデータの不整合の問題
- 追加されたインデックスと一緒に機能を使用するときに発生するデータの不整合の問題
現在、この機能にはまだ次の非互換性の問題があります。
- 同時トランザクションがある場合、トランザクションのセマンティクスが変わる可能性があります
- この機能をTiDBBinlogと一緒に使用すると発生する既知の互換性の問題
Change Columnとの非互換性
文字セットと照合順序
utf8mb4_unicode_ciとutf8_unicode_ciの照合をサポートします。 ユーザードキュメント ＃17596- 照合の大文字と小文字を区別しない比較ソートをサポートする
安全
セキュリティコンプライアンス要件（一般データ保護規則、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はクエリの計算をTiFlashMPPクラスタにプッシュダウンできます。次に、分散環境は、実行プロセス全体を加速し、分析クエリの速度を劇的に向上させるのに役立ちます。
TPC-H 100ベンチマークテストでは、TiFlash MPPは、従来の分析データベースの分析エンジンおよびHadoop上のSQLよりも大幅な処理速度を実現します。このアーキテクチャを使用すると、従来のオフライン分析ソリューションよりも高いパフォーマンスで、最新のトランザクションデータに対して直接大規模な分析クエリを実行できます。ベンチマークによると、同じクラスタリソースを使用すると、TiDB5.0MPPはGreenplum6.15.0およびApacheSpark3.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、およびOFFINT_ONLY。ON：クラスター化インデックス機能がすべてのタイプの主キーに対して有効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。OFF：すべてのタイプの主キーに対してクラスター化インデックス機能が無効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。INT_ONLY：デフォルト値。変数がINT_ONLYに設定され、alter-primary-keyがfalseに設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスター化インデックスとして作成されます。動作は、TiDBv5.0以前のバージョンの動作と一致しています。
CREATE TABLEステートメントにキーワードCLUSTERED | NONCLUSTEREDが含まれている場合、そのステートメントはシステム変数の構成と構成項目をオーバーライドします。
ステートメントでキーワードCLUSTERED | NONCLUSTEREDを指定して、クラスター化インデックス機能を使用することをお勧めします。このように、TiDBは、必要に応じて、システム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を同時に使用する方が柔軟です。
tidb_enable_clustered_index = INT_ONLYを使用することはお勧めしません。これは、この機能を互換性のあるものにするためにINT_ONLYが一時的に使用され、将来的に非推奨になるためです。
クラスタ化インデックスの制限は次のとおりです。
- クラスタ化インデックスと非クラスタ化インデックス間の相互変換はサポートされていません。
- クラスタ化インデックスの削除はサポートされていません。
ALTER TABLEステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。- クラスタ化されたインデックスの再編成と再作成はサポートされていません。
- インデックスの有効化または無効化はサポートされていません。つまり、非表示インデックス機能はクラスター化インデックスには効果的ではありません。
- クラスタ化されたインデックスとして
UNIQUE KEYを作成することはサポートされていません。 - クラスター化インデックス機能をTiDBBinlogと一緒に使用することはサポートされていません。 TiDB Binlogを有効にすると、TiDBはクラスター化インデックスとして単一の整数主キーの作成のみをサポートします。 TiDB Binlogは、クラスター化インデックスを持つ既存のテーブルのデータ変更をダウンストリームに複製しません。
- クラスタ化インデックス機能を属性
SHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSと一緒に使用することはサポートされていません。 - クラスタが新しいバージョンにアップグレードされてからロールバックされる場合は、ロールバック前にテーブルデータをエクスポートし、ロールバック後にデータをインポートして、新しく追加されたテーブルをダウングレードする必要があります。他のテーブルは影響を受けません。
非同期コミット
データベースのクライアントは、データベースシステムが2フェーズ（2PC）で同期的にトランザクションコミットを完了するのを待ちます。トランザクションは、第1フェーズのコミットが成功した後、結果をクライアントに返します。システムは、トランザクションのコミット待ち時間を短縮するために、バックグラウンドで第2フェーズのコミット操作を非同期的に実行します。トランザクション書き込みに1つのリージョンのみが含まれる場合、2番目のフェーズは直接省略され、トランザクションは1フェーズコミットになります。
同じハードウェアと構成で非同期コミット機能を有効にした後、Sysbenchが64スレッドで更新インデックスをテストするように設定されている場合、平均遅延は12.04msから7.01msに41.7％減少します。
非同期コミット機能が有効になっている場合、1つのネットワーク相互作用の待ち時間を短縮し、データ書き込みのパフォーマンスを向上させるために、データベースアプリケーション開発者は、トランザクションの整合性を線形整合性から因果整合性に下げることを検討することをお勧めします。因果整合性を有効にするSQLステートメントはSTART TRANSACTION WITH CAUSAL CONSISTENCYです。
同じハードウェアと構成で因果整合性を有効にした後、Sysbenchが64スレッドでoltp_write_onlyをテストするように設定されている場合、平均遅延は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はtidb-serverのtikv-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のCPUおよびI/Oリソースの消費を減らすために、デフォルトでGC圧縮フィルター機能を有効にします
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に設定することで、これを有効にできます。この機能を有効にすると、システムはbind-info-lease回ごとにステートメントの概要から少なくとも2回表示されるSQLステートメントをフェッチし（デフォルト値は3s ）、これらのSQLステートメントを自動的にキャプチャしてバインドします。
TiFlashクエリの安定性を向上させる
システム変数tidb_allow_fallback_to_tikvを追加して、TiFlashが失敗したときにクエリをTiKVにフォールバックします。デフォルト値はOFFです。
TiCDCの安定性を改善し、過剰な増分データの複製によって引き起こされるOOMの問題を軽減します
TiCDC v4.0.9以前のバージョンでは、あまりにも多くのデータ変更を複製すると、OOMが発生する可能性があります。 v5.0では、次のシナリオによって引き起こされるOOMの問題を軽減するために、統合ソーター機能がデフォルトで有効になっています。
- TiCDCのデータ複製タスクは長時間一時停止されます。その間、大量の増分データが蓄積され、複製する必要があります。
- データ複製タスクは早いタイムスタンプから開始されるため、大量の増分データを複製する必要があります。
ユニファイドソーターは、以前のバージョンのmemoryソートエンジンオプションと統合されていfile 。変更を手動で構成する必要はありません。
制限：
- 増分データの量に応じて、十分なディスク容量を提供する必要があります。 128GBを超える空き容量のSSDを使用することをお勧めします。
高可用性とディザスタリカバリ
リージョンメンバーシップの変更中のシステムの可用性を向上させる
リージョンメンバーシップの変更の過程で、「メンバーの追加」と「メンバーの削除」は、2つのステップで実行される2つの操作です。メンバーシップの変更が終了したときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。
導入されたRaftJointConsensusアルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」の操作を1つの操作にまとめて、すべてのメンバーに送信します。変更プロセス中、リージョンは中間状態になります。変更されたメンバーに障害が発生した場合でも、システムは引き続き使用できます。
この機能はデフォルトで有効になっています。 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。標準構成（または同等の構成）向けに、データインポートのパフォーマンスを最適化します。テスト結果は、TiDBLightningが1TBのTPC-CデータをTiDBにインポートする速度を254GiB/hから366GiB/ hに40％向上させることを示しています。
データ共有とサブスクリプション
TiCDC（実験的機能）を使用してTiDBをKafka Connect（コンフルエントプラットフォーム）に統合する
TiDBデータを他のシステムにストリーミングするというビジネス要件をサポートするために、この機能を使用すると、TiDBデータをKafka、Hadoop、Oracleなどのシステムにストリーミングできます。
Confluentプラットフォームによって提供されるKafkaコネクタプロトコルは、コミュニティで広く使用されており、さまざまなプロトコルでリレーショナルデータベースまたは非リレーショナルデータベースにデータを転送することをサポートしています。 TiCDCをConfluentプラットフォームのKafkaConnectに統合することにより、TiDBは、TiDBデータを他の異種データベースまたはシステムにストリーミングする機能を拡張します。
診断
SQLパフォーマンスの問題のトラブルシューティング中に、パフォーマンスの問題の原因を判別するために詳細な診断情報が必要です。 TiDB 5.0より前は、 EXPLAINのステートメントによって収集された情報は十分に詳細ではありませんでした。問題の根本的な原因は、ログ情報、監視情報、または推測に基づいてのみ判断できますが、これは非効率的である可能性があります。
TiDB v5.0では、パフォーマンスの問題をより効率的にトラブルシューティングできるように、次の改善が行われました。
EXPLAIN ANALYZEステートメントを使用してすべてのDMLステートメントを分析し、各オペレーターの実際のパフォーマンス計画と実行情報を表示することをサポートします。 ＃18056EXPLAIN FOR CONNECTIONステートメントを使用して、実行中のすべてのSQLステートメントのリアルタイムステータスを確認することをサポートします。たとえば、このステートメントを使用して、各演算子の実行期間と処理された行数を確認できます。 ＃18233EXPLAIN ANALYZEステートメントの出力で、オペレーターによって送信されたRPC要求の数、ロックの競合を解決する期間、ネットワークレイテンシー、RocksDBでスキャンされた削除データの量、RocksDBのヒット率など、オペレーターの実行に関する詳細を提供します。キャッシュ。 ＃18663- SQLステートメントの詳細な実行情報を低速ログに自動的に記録することをサポートします。スローログの実行情報は、各オペレーターが消費した時間、処理された行の数、送信されたRPC要求の数など、
EXPLAIN ANALYZEステートメントの出力情報と一致しています。 ＃15009
展開とメンテナンス
クラスタ展開操作のロジックを最適化して、DBAが一連の標準TiDB本番クラスタをより高速に展開できるようにします
以前のTiDBバージョンでは、TiUPを使用してTiDBクラスターを展開するDBAは、環境の初期化が複雑で、チェックサム構成が過剰であり、クラスタトポロジファイルを編集するのが難しいことに気付きました。これらの問題はすべて、DBAの展開効率を低下させます。 TiDB v5.0では、TiUPを使用したTiDBの展開効率が、次の項目を通じてDBAに対して改善されています。
- TiUP Clusterは、より包括的なワンクリック環境チェックを実行し、修復の推奨事項を提供する
check topo.yamlコマンドをサポートしています。 - TiUP Clusterは、環境チェック中に見つかった環境問題を自動的に修復する
check topo.yaml --applyコマンドをサポートしています。 - TiUP Clusterは、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 replay cluster1サブコマンドを使用してブレークポイントから失敗した操作を再試行することをサポートしています。
メンテナンスと運用の機能を強化する
TiUP v1.4.0は、TiDBクラスターを操作および保守するための機能をさらに強化します。
- より多くの使用シナリオに適応するために、ダウンタイムTiDBおよびDMクラスターでのアップグレードまたはパッチ操作をサポートします。
- tiup-clusterの
displayサブコマンドに--versionパラメーターを追加して、クラスタのバージョンを取得します。 - スケールアウトされるノードにPrometheusのみが含まれている場合、Prometheusノードがないことによるスケールアウトの失敗を回避するために、監視構成を更新する操作は実行されません。
- 入力TiUPコマンドの結果が正しくない場合に、エラーメッセージにユーザー入力を追加して、問題の原因をより迅速に特定できるようにします。
テレメトリー
TiDBは、データテーブルの数、クエリの数、新機能が有効になっているかどうかなど、テレメトリにクラスタ使用状況メトリックを追加します。
詳細とこの動作を無効にする方法の詳細については、 テレメトリーを参照してください。