重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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アルゴリズムを導入し、リージョンメンバーシップの変更中にシステムの可用性を確保します。
  • データベース管理者(DBA)がSQLステートメントをより効率的にデバッグするのに役立つEXPLAINの機能と非表示のインデックスを最適化します。
  • エンタープライズデータの信頼性を保証します。 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_size20000から0に変更します。これは、バッチDMLステートメントがINSERT INTO SELECT ...でデフォルトで使用されなくなったことを意味しLOAD 。代わりに、厳密なACIDセマンティクスに準拠するために大規模なトランザクションが使用されます。

    ノート:

    変数のスコープがセッションからグローバルに変更され、デフォルト値が20000から0に変更されます。アプリケーションが元のデフォルト値に依存している場合は、 set globalステートメントを使用して、アップグレード後に変数を元の値に変更する必要があります。

  • tidb_enable_noop_functionsのシステム変数を使用して、一時テーブルの構文の互換性を制御します。この変数値がOFFの場合、 CREATE TEMPORARY TABLE構文はエラーを返します。

  • 次のシステム変数を追加して、ガベージコレクション関連のパラメータを直接制御します。

  • デフォルト値のenable-joint-consensusfalseからtrueに変更します。これにより、デフォルトで共同コンセンサス機能が有効になります。

  • tidb_enable_amend_pessimistic_txnの値を0または1からONまたはOFFに変更します。

  • 次の新しい意味で、デフォルト値のtidb_enable_clustered_indexOFFからINT_ONLYに変更します。

    • ON :クラスター化インデックスが有効になります。非クラスター化インデックスの追加または削除がサポートされています。

    • OFF :クラスター化されたインデックスは無効です。非クラスター化インデックスの追加または削除がサポートされています。

    • INT_ONLY :デフォルト値。動作はv5.0以前の動作と一致しています。 INTタイプのクラスター化インデックスをalter-primary-key = falseと一緒に有効にするかどうかを制御できます。

      ノート:

      5.0 GAのtidb_enable_clustered_indexINT_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でない場合、アップグレード後に「回復可能なゴルーチンのpanic」エラーが発生しますが、このエラーはアップグレードには影響しません。
  • データの正確性の問題を回避するために、列タイプの変更中にVARCHARタイプとCHARタイプの間の変換を禁止します。

新機能

SQL

List パーティショニング(実験的

ユーザードキュメント

リスト分割機能を使用すると、大量のデータを含むテーブルを効果的に照会および保守できます。

この機能を有効にすると、パーティションとパーティション間でのデータの分散方法がPARTITION BY LIST(expr) PARTITION part_name VALUES IN (...)式に従って定義されます。パーティションテーブルのデータセットは、最大1024個の異なる整数値をサポートします。 PARTITION ... VALUES IN (...)句を使用して値を定義できます。

リストの分割を有効にするには、セッション変数tidb_enable_list_partitionONに設定します。

List COLUMNS パーティショニング(実験的

ユーザードキュメント

List COLUMNS パーティショニングは、リストパーティショニングの変形です。複数の列をパーティションキーとして使用できます。整数データ型に加えて、文字列、 DATE 、およびDATETIMEデータ型の列をパーティション列として使用することもできます。

List COLUMNS パーティショニングを有効にするには、セッション変数tidb_enable_list_partitionONに設定します。

目に見えないインデックス

ユーザードキュメント #9246

パフォーマンスを調整したり、最適なインデックスを選択したりする場合は、SQLステートメントを使用してインデックスをVisibleまたはInvisibleに設定できます。この設定により、 DROP INDEXADD INDEXなどのリソースを消費する操作の実行を回避できます。

インデックスの可視性を変更するには、 ALTER INDEXステートメントを使用します。変更後、オプティマイザーは、インデックスの可視性に基づいて、このインデックスをインデックスリストに追加するかどうかを決定します。

EXCEPTおよびINTERSECT演算子

ユーザードキュメント #18031

INTERSECT演算子は、2つ以上のクエリの結果セットの共通部分を返す集合演算子です。ある程度、それはInner Join演算子の代替です。

EXCEPT演算子は集合演算子であり、2つのクエリの結果セットを組み合わせて、最初のクエリ結果にはあるが2番目のクエリ結果にはない要素を返します。

取引

ユーザードキュメント #18005

悲観的トランザクションモードでは、トランザクションに関連するテーブルに同時DDL操作またはSCHEMA VERSION変更が含まれている場合、システムはトランザクションのSCHEMA VERSIONを最新に自動的に更新して、トランザクションコミットが成功するようにし、クライアントがInformation schema is changedエラーを受信しないようにします。トランザクションは、DDL操作またはSCHEMA VERSIONの変更によって中断されます。

この機能はデフォルトで無効になっています。この機能を有効にするには、 tidb_enable_amend_pessimistic_txnのシステム変数の値を変更します。この機能はv4.0.7で導入され、v5.0で修正された次の問題があります。

  • BinlogがAdd Columnの操作を実行するときに発生する互換性の問題
  • この機能を一意のインデックスと一緒に使用すると発生するデータの不整合の問題
  • 追加されたインデックスと一緒に機能を使用するときに発生するデータの不整合の問題

現在、この機能にはまだ次の非互換性の問題があります。

  • 同時トランザクションがある場合、トランザクションのセマンティクスが変わる可能性があります
  • この機能をBinlogと一緒に使用すると発生する既知の互換性の問題
  • Change Columnとの非互換性

文字セットと照合順序

  • utf8mb4_unicode_ciutf8_unicode_ciの照合をサポートします。 ユーザードキュメント #17596
  • 照合の大文字と小文字を区別しない比較ソートをサポートする

安全

ユーザードキュメント #18566

セキュリティコンプライアンス要件(一般データ保護規則、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流出
  • 連合
  • フルアウタージョイン

クラスター化されたインデックス

ユーザードキュメント #4841

テーブル構造を設計したり、データベースの動作を分析したりするときに、主キーを持つ一部の列がグループ化およびソートされることが多く、これらの列に対するクエリが特定の範囲のデータまたは少量を返すことが多い場合は、クラスター化インデックス機能を使用することをお勧めします値が異なるデータの場合、対応するデータによって読み取りまたは書き込みのホットスポットの問題が発生することはありません。

一部のデータベース管理システムではインデックス編成テーブルとも呼ばれるクラスター化インデックスは、テーブルのデータに関連付けられたストレージ構造です。クラスター化インデックスを作成するときに、テーブルの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-keyfalseに設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスター化インデックスとして作成されます。この動作は、TiDBv5.0以前のバージョンの動作と一致しています。

CREATE TABLEステートメントにキーワードCLUSTERED | NONCLUSTEREDが含まれている場合、そのステートメントはシステム変数の構成と構成アイテムをオーバーライドします。

ステートメントでキーワードCLUSTERED | NONCLUSTEREDを指定して、クラスター化索引機能を使用することをお勧めします。このように、TiDBは、システム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を必要に応じて同時に使用する方が柔軟性があります。

tidb_enable_clustered_index = INT_ONLYを使用することはお勧めしません。これは、この機能を互換性のあるものにするためにINT_ONLYが一時的に使用され、将来的に非推奨になるためです。

クラスター化インデックスの制限は次のとおりです。

  • クラスター化インデックスと非クラスター化インデックス間の相互変換はサポートされていません。
  • クラスタ化インデックスの削除はサポートされていません。
  • ALTER TABLEステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。
  • クラスター化されたインデックスの再編成および再作成はサポートされていません。
  • インデックスの有効化または無効化はサポートされていません。つまり、非表示インデックス機能はクラスター化インデックスには有効ではありません。
  • クラスター化されたインデックスとしてUNIQUE KEYを作成することはサポートされていません。
  • クラスター化インデックス機能をBinlogと一緒に使用することはサポートされていません。 TiDB Binlogを有効にすると、TiDBはクラスター化インデックスとして単一の整数主キーの作成のみをサポートします。 TiDB Binlogは、クラスター化インデックスを持つ既存のテーブルのデータ変更をダウンストリームに複製しません。
  • クラスタ化インデックス機能を属性SHARD_ROW_ID_BITSおよびPRE_SPLIT_REGIONSと一緒に使用することはサポートされていません。
  • クラスタが新しいバージョンにアップグレードされてからロールバックされる場合は、ロールバック前にテーブルデータをエクスポートし、ロールバック後にデータをインポートして、新しく追加されたテーブルをダウングレードする必要があります。他のテーブルは影響を受けません。

非同期コミット

ユーザードキュメント #8316

データベースのクライアントは、データベースシステムが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;ステートメントを実行します。

非同期コミット機能の制限は次のとおりです。

  • 直接ダウングレードはサポートされていません。

コプロセッサーのキャッシュ機能をデフォルトで有効にする

ユーザードキュメント #18028

5.0 GAでは、コプロセッサーのキャッシュ機能はデフォルトで有効になっています。この機能を有効にすると、データの読み取りの待ち時間を短縮するために、TiDBはtidb-serverのtikv-serverにプッシュダウンされた演算子の計算結果をキャッシュします。

コプロセッサーのキャッシュ機能を無効にするには、 tikv-client.copr-cacheから0.0capacity-mbの構成項目を変更します。

delete from table where id <? Limit ?の実行パフォーマンスを改善します。 delete from table where id <? Limit ?声明

#18028

delete from table where id <? limit ?ステートメントのp99パフォーマンスは4倍向上しています。

ロードベースの分割戦略を最適化して、一部の小さなテーブルのホットスポット読み取りシナリオではデータを分割できないというパフォーマンスの問題を解決します

#18005

安定性を向上させる

不完全なスケジューリングによって引き起こされるパフォーマンスジッターの問題を最適化する

#18005

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圧縮フィルター機能を有効にします

ユーザードキュメント #18009

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バインディングは、 INSERTREPLACEUPDATEDELETEステートメントをサポートします

パフォーマンスの調整またはデータベースの保守時に、実行プランが不安定なためにシステムパフォーマンスが不安定であることがわかった場合は、判断に従って手動で最適化された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の問題を軽減します

ユーザードキュメント #1150

TiCDC v4.0.9以前のバージョンでは、複製するデータの変更が多すぎるとOOMが発生する可能性があります。 v5.0では、次のシナリオによって引き起こされるOOMの問題を軽減するために、統合ソーター機能がデフォルトで有効になっています。

  • TiCDCのデータ複製タスクは長時間一時停止されます。その間、大量の増分データが蓄積され、複製する必要があります。
  • データ複製タスクは早いタイムスタンプから開始されるため、大量の増分データを複製する必要があります。

ユニファイドソーターは、以前のバージョンのmemoryソートエンジンオプションと統合されていfile 。変更を手動で構成する必要はありません。

制限:

  • 増分データの量に応じて、十分なディスク容量を提供する必要があります。 128GBを超える空き容量のSSDを使用することをお勧めします。

高可用性とディザスタリカバリ

リージョンメンバーシップの変更中のシステムの可用性を向上させる

ユーザードキュメント #18079 #7587 #2860

リージョンメンバーシップの変更の過程で、「メンバーの追加」と「メンバーの削除」は、2つのステップで実行される2つの操作です。メンバーシップの変更が終了したときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。

導入されたRaftアルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」の操作を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.standard構成(または同等のもの)専用にデータインポートパフォーマンスを最適化します。テスト結果は、 TiDB Lightningが1TBのTPC-CデータをTiDBにインポートする速度を254GiB/hから366GiB/ hに40%向上させることを示しています。

データ共有とサブスクリプション

TiCDC(実験的機能)を使用してTiDBをKafka Connect(コンフルエントプラットフォーム)に統合する

ユーザードキュメント #660

TiDBデータを他のシステムにストリーミングするというビジネス要件をサポートするために、この機能を使用すると、TiDBデータをKafka、Hadoop、Oracleなどのシステムにストリーミングできます。

Confluentプラットフォームによって提供されるKafkaコネクタプロトコルはコミュニティで広く使用されており、さまざまなプロトコルでリレーショナルデータベースまたは非リレーショナルデータベースにデータを転送することをサポートしています。 TiCDCをConfluentプラットフォームのKafkaConnectに統合することにより、TiDBは、TiDBデータを他の異種データベースまたはシステムにストリーミングする機能を拡張します。

診断

ユーザードキュメント

SQLパフォーマンスの問題のトラブルシューティング中に、パフォーマンスの問題の原因を判別するために詳細な診断情報が必要です。 TiDB 5.0より前は、 EXPLAINのステートメントによって収集された情報は十分に詳細ではありませんでした。問題の根本的な原因は、ログ情報、監視情報、または推測に基づいてのみ判断できますが、これは非効率的である可能性があります。

TiDB v5.0では、パフォーマンスの問題をより効率的にトラブルシューティングできるように、次の改善が行われました。

  • EXPLAIN ANALYZEステートメントを使用してすべてのDMLステートメントを分析し、各オペレーターの実際のパフォーマンス計画と実行情報を表示することをサポートします。 #18056
  • EXPLAIN FOR CONNECTIONステートメントを使用して、実行中のすべてのSQLステートメントのステータスをリアルタイムで確認することをサポートします。たとえば、このステートメントを使用して、各演算子の実行時間と処理された行の数を確認できます。 #18233
  • EXPLAIN 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は、 edit-configコマンドを使用してさまざまなAlertManagerを構成するためのexternal_alertmanagersパラメーターの編集をサポートしています。
  • 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は、データテーブルの数、クエリの数、新機能が有効になっているかどうかなど、テレメトリにクラスタ使用状況メトリックを追加します。

詳細とこの動作を無効にする方法の詳細については、 テレメトリーを参照してください。

このページの内容