TiDB5.0RCリリースノート

発売日：2021年1月12日

TiDBバージョン：5.0.0-rc

TiDB v5.0.0-rcは、TiDBv5.0の先行バージョンです。 v5.0では、PingCAPは、企業がTiDBに基づいてアプリケーションを迅速に構築し、データベースパフォーマンス、パフォーマンスジッター、セキュリティ、高可用性、ディザスタリカバリ、SQLパフォーマンスのトラブルシューティングなどの心配から解放するのを支援することに専念します。

v5.0では、主な新機能または改善点は次のとおりです。

• クラスター化されたインデックス。この機能を有効にすると、データベースのパフォーマンスが向上します。たとえば、TPC-C tpmCテストでは、クラスター化インデックスを有効にした場合のTiDBのパフォーマンスが39％向上します。
• 非同期コミット。この機能を有効にすると、書き込みレイテンシが短縮されます。たとえば、Sysbench olpt-insertテストでは、非同期コミットが有効になっている場合のTiDBの書き込み遅延が37.3％減少します。
• ジッタの低減。これは、オプティマイザの安定性を向上させ、システムタスクによるI / O、ネットワーク、CPU、およびメモリリソースの使用を制限することによって実現されます。たとえば、72時間のパフォーマンステストでは、Sysbench TPSジッターの標準偏差が11.09％から3.36％に減少します。
• Raft Joint Consensusアルゴリズム。これにより、リージョンメンバーシップの変更中にシステムの可用性が保証されます。
• 最適化されたEXPLAINの機能と非表示のインデックス。データベース管理者（DBA）がSQLステートメントをより効率的にデバッグするのに役立ちます。
• エンタープライズデータの信頼性が保証されています。 TiDBからAWSS3ストレージとGoogleCloudGCSにデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。
• AWSS3ストレージまたはTiDB/MySQLからのデータインポートまたはデータエクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。たとえば、TPC-Cテストでは、1TiBデータのインポートのパフォーマンスが254GiB/hから366GiB/ hに40％向上します。

SQL

クラスター化されたインデックスのサポート（実験的）

クラスター化インデックス機能を有効にすると、次の場合にTiDBのパフォーマンスが大幅に向上します（たとえば、TPC-C tpmCテストでは、クラスター化インデックスを有効にした場合のTiDBのパフォーマンスが39％向上します）。

• データが挿入されると、クラスター化されたインデックスにより、ネットワークからのインデックスデータの書き込みが1回減ります。
• 同等の条件のクエリに主キーのみが含まれる場合、クラスター化インデックスはネットワークからのインデックスデータの読み取りを1回減らします。
• 範囲条件を含むクエリに主キーのみが含まれる場合、クラスター化インデックスは、ネットワークからのインデックスデータの複数の読み取りを削減します。
• 同等または範囲の条件を持つクエリに主キープレフィックスが含まれる場合、クラスター化インデックスは、ネットワークからのインデックスデータの複数の読み取りを削減します。

クラスター化インデックスは、テーブル内のデータの物理ストレージ順序を定義します。テーブル内のデータは、クラスター化インデックスの定義に従ってのみソートされます。各テーブルには、クラスター化されたインデックスが1つだけあります。

ユーザーは、 tidb_enable_clustered_indexの変数を変更することにより、クラスター化インデックス機能を有効にできます。有効にすると、この機能は新しく作成されたテーブルでのみ有効になり、複数の列を持つか、単一の列に非整数型である主キーに適用されます。主キーが単一列の整数型である場合、またはテーブルに主キーがない場合、データはクラスター化されたインデックスの影響を受けることなく、以前と同じ方法で並べ替えられます。

たとえば、テーブル（ tbl_name ）にクラスター化されたインデックスがあるかどうかを確認するには、 select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}'を実行します。

• ユーザードキュメント
• 関連する問題： ＃4841

非表示のインデックスをサポートする

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

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

• ユーザードキュメント
• 関連する問題： ＃9246

EXCEPTおよびINTERSECT演算子をサポートする

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

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

• ユーザードキュメント
• 関連する問題： ＃18031

取引

悲観的なトランザクションの実行の成功率を高める

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

• ユーザードキュメント
• 関連する問題： ＃18005

文字セットと照合順序

文字セットの大文字と小文字を区別しない比較ソートをサポートします。

• ユーザードキュメント
• 関連する問題： ＃17596

安全

エラーメッセージとログファイルの感度低下をサポート

TiDBは、ID情報やクレジットカード番号などの機密情報の漏洩を防ぐために、エラーメッセージとログファイルの機密解除をサポートするようになりました。

ユーザーは、さまざまなコンポーネントの感度低下機能を有効にできます。

• TiDB側では、tidb-serverのSQLステートメントを使用してtidb_redact_log=1変数を設定します。
• TiKV側の場合は、tikv-serverでsecurity.redact-info-log = true構成を設定します。
• PD側は、pd-serverでsecurity.redact-info-log = true構成を設定します。 ＃2852 ＃3011
• TiFlash側の場合、tiflash-serverでsecurity.redact_info_log = true構成を設定し、tiflash-learnerでsecurity.redact-info-log = trueを設定します。

ユーザードキュメント

関連する問題： ＃18566

パフォーマンスの向上

非同期コミットのサポート（実験的）

非同期コミット機能を有効にすると、トランザクションの待ち時間を大幅に短縮できます。たとえば、この機能を有効にすると、Sysbench oltp-insertテストのトランザクションの待機時間は、この機能を無効にした場合よりも37.3％低くなります。

以前は非同期コミット機能がなかったため、書き込まれるステートメントは、2フェーズトランザクションコミットが終了した後にのみクライアントに返されていました。現在、非同期コミット機能は、2フェーズコミットの最初のフェーズが終了した後にクライアントに結果を返すことをサポートしています。次に、2番目のフェーズがバックグラウンドで非同期に実行されるため、トランザクションコミットの待ち時間が短縮されます。

ただし、非同期コミットが有効になっている場合、トランザクションの外部整合性は、 tidb_guarantee_external_consistency = ONが設定されている場合にのみ保証されます。非同期コミットを有効にすると、パフォーマンスが低下する可能性があります。

ユーザーは、グローバル変数tidb_enable_async_commit = ONを設定することにより、この機能を有効にできます。

• ユーザードキュメント
• 関連する問題： ＃8316

インデックス選択におけるオプティマイザーの安定性を向上させる（実験的）

常に比較的適切なインデックスを選択するオプティマイザーの機能は、クエリのレイテンシーが安定しているかどうかを大きく左右します。統計モジュールを改善およびリファクタリングして、同じSQLステートメントに対して、統計が欠落しているか不正確であるためにオプティマイザーが毎回複数の候補インデックスから異なるインデックスを選択しないようにしました。オプティマイザが比較的適切なインデックスを選択するのに役立つ主な改善点は次のとおりです。

• 複数列のNDV、複数列の順序の依存関係、複数列の関数従属性などの情報を統計モジュールに追加します。
• 統計モジュールをリファクタリングします。
  • CMSKetchからTopNの値を削除します。
  • TopNの検索ロジックをリファクタリングします。
  • ヒストグラムからTopNの情報を削除し、ヒストグラムのインデックスを作成して、バケットNDVのメンテナンスを容易にします。

関連する問題： ＃18065

不完全なスケジューリングまたは不完全なI/Oフロー制御によって引き起こされるパフォーマンスジッターを最適化する

TiDBスケジューリングプロセスは、I / O、ネットワーク、CPU、メモリなどのリソースを占有します。 TiDBがスケジュールされたタスクを制御しない場合、QPSと遅延により、リソースのプリエンプションが原因でパフォーマンスジッターが発生する可能性があります。次の最適化の後、72時間のテストで、Sysbench TPSジッターの標準偏差が11.09％から3.36％に減少しました。

• ノード容量の変動（常に喫水線の近く）およびPDのstore-limit構成値の設定が大きすぎることによって引き起こされる冗長なスケジューリングの問題を減らします。これは、 region-score-formula-version = v2の構成項目を介して有効化される新しいスケジューリング計算式のセットを導入することによって実現されます。 ＃3269
• 空のリージョンの数を減らすためにenable-cross-table-merge = trueを変更して、クロスリージョンマージ機能を有効にします。 ＃3129
• TiKVバックグラウンドでのデータ圧縮は、多くのI/Oリソースを占有します。システムは、圧縮率を自動的に調整して、バックグラウンドタスクとフォアグラウンドの読み取りおよび書き込みの間のI/Oリソースの競合のバランスを取ります。 rate-limiter-auto-tunedの構成項目でこの機能を有効にすると、遅延ジッターが大幅に減少します。 ＃18011
• TiKVがガベージコレクション（GC）とデータ圧縮を実行すると、パーティションがCPUとI/Oリソースを占有します。これら2つのタスクの実行中に、重複するデータが存在します。 I / O使用量を削減するために、GC圧縮フィルター機能はこれら2つのタスクを1つに結合し、同じタスクで実行します。この機能はまだ実験的段階であり、 gc.enable-compaction-filter = trueを介して有効にすることができます。 ＃18009
• TiFlashがデータを圧縮またはソートするとき、それは多くのI/Oリソースを占有します。システムは、圧縮とデータの並べ替えによるI / Oリソースの使用を制限することにより、リソースの競合を軽減します。この機能はまだ実験的段階であり、 bg_task_io_rate_limitを介して有効にすることができます。

関連する問題： ＃18005

リアルタイムBI/データウェアハウジングシナリオでのTiFlashの安定性を向上させる

• DeltaIndexのメモリ使用量を制限して、大量のデータが発生するシナリオでの過剰なメモリ使用量によって引き起こされるシステムのメモリ不足（OOM）を回避します。
• フォアグラウンドタスクへの影響を減らすために、バックグラウンドデータソートタスクによって使用されるI/O書き込みトラフィックを制限します。
• キューコプロセッサータスクに新しいスレッドプールを追加します。これにより、コプロセッサーを高い同時実行性で処理するときに過剰なメモリ使用量によって引き起こされるシステムOOMが回避されます。

その他のパフォーマンスの最適化

• delete from table where id <?ステートメントの実行パフォーマンスを向上させます。そのP99のパフォーマンスは4倍向上します。 ＃18028
• TiFlashは、パフォーマンスを向上させるために、複数のローカルディスクでのデータの同時読み取りと書き込みをサポートします。

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

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

リージョンメンバーシップの変更の過程で、「メンバーの追加」と「メンバーの削除」は、2つのステップで実行される2つの操作です。メンバーシップの変更が終了したときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。導入されたRaftアルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」の操作を1つの操作にまとめて、すべてのメンバーに送信します。変更プロセス中、リージョンは中間状態にあります。変更されたメンバーに障害が発生した場合でも、システムは引き続き使用できます。ユーザーは、 pd-ctl config set enable-joint-consensus trueを実行してメンバーシップ変数を変更することにより、この機能を有効にできます。 ＃7587 ＃2860

• ユーザードキュメント
• 関連する問題： ＃18079

メモリ管理モジュールを最適化して、システムOOMのリスクを軽減します

• キャッシュ統計のメモリ消費を削減します。
• Dumplingツールを使用してデータをエクスポートする際のメモリ消費を削減します。
• データの暗号化された中間結果をディスクに保存することにより、メモリ消費を削減しました。

バックアップと復元

• Backup＆Restoreツール（BR）は、AWSS3およびGoogleCloudGCSへのデータのバックアップをサポートしています。 （ ユーザードキュメント ）
• Backup＆Restoreツール（BR）は、AWSS3およびGoogleCloudGCSからTiDBへのデータの復元をサポートしています。 （ ユーザードキュメント ）
• 関連する問題： ＃89

データのインポートとエクスポート

• TiDB Lightningは、AWSS3ストレージからTiDBへのAuroraスナップショットデータのインポートをサポートしています。 （関連する問題： ＃266 ）
• 1TiBのデータをDBaaST1.standardにインポートするTPC-Cテストでは、パフォーマンスが254 GiB/hから366GiB/ hに40％向上します。
• Dumplingは、TiDB /MySQLからAWSS3ストレージへのデータのエクスポートをサポートしユーザードキュメント （実験的）（関連する問題： ＃8 ）

診断

より多くの情報を収集した最適化されたEXPLAIN機能は、ユーザーがパフォーマンスの問題をトラブルシューティングするのに役立ちます

ユーザーがSQLパフォーマンスの問題をトラブルシューティングするときは、パフォーマンスの問題の原因を特定するための詳細な診断情報が必要です。以前のTiDBバージョンでは、 EXPLAINステートメントによって収集された情報は十分に詳細ではありませんでした。 DBAは、ログ情報、監視情報、または推測に基づいてのみトラブルシューティングを実行しましたが、これは非効率的である可能性があります。 TiDB v5.0では、ユーザーがパフォーマンスの問題をより効率的にトラブルシューティングできるように、次の改善が行われました。

• EXPLAIN ANALYZEは、すべてのDMLステートメントの分析をサポートし、実際のパフォーマンス計画と各オペレーターの実行情報を示します。 ＃18056
• ユーザーはEXPLAIN FOR CONNECTIONを使用して、実行中のSQLステートメントの状況情報を分析できます。この情報には、各オペレーターの実行時間と処理された行の数が含まれます。 ＃18233
• EXPLAIN ANALYZEの出力には、オペレーターから送信されたRPCリクエストの数、ロックの競合を解決する期間、ネットワークレイテンシ、RocksDBでスキャンされた削除データの量、RocksDBキャッシュのヒット率などの詳細情報が表示されます。 ＃18663
• SQLステートメントの詳細な実行情報は、 EXPLAIN ANALYZEの出力情報と一致する低速ログに記録されます。この情報には、各オペレーターが消費した時間、処理された行の数、および送信されたRPC要求の数が含まれます。 ＃15009

ユーザードキュメント

展開とメンテナンス

• 以前は、TiDB Ansibleの構成情報がTiUPにインポートされると、TiUPはユーザー構成をansible-imported-configsディレクトリに配置していました。ユーザーが後でtiup cluster edit-configを使用して構成を編集する必要がある場合、インポートされた構成はエディターインターフェイスに表示されなかったため、ユーザーが混乱する可能性がありました。 TiDB v5.0では、TiDB Ansible構成がインポートされると、TiUPは構成情報をansible-imported-configsとエディターインターフェイスの両方に配置します。この改善により、ユーザーはクラスタ構成を編集しているときに、インポートされた構成を確認できます。
• 複数のミラーを1つにマージし、コンポーネントをローカルミラーに公開し、コンポーネントの所有者をローカルミラーに追加することをサポートする拡張mirrorコマンド。 ＃814
  • 大企業、特に金融業界では、本番環境の変更は慎重に検討されます。各バージョンでユーザーがインストールにCDを使用する必要がある場合は、問題が発生する可能性があります。 TiDB v5.0では、TiUPのmergeコマンドは、複数のインストールパッケージを1つにマージすることをサポートしているため、インストールが簡単になります。
  • v4.0では、ユーザーは自作ミラーを公開するためにtiup-serverを起動する必要がありましたが、これは十分に便利ではありませんでした。 v5.0では、ユーザーはtiup mirror setを使用して現在のミラーをローカルミラーに設定するだけで、自作ミラーを公開できます。