重要

古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。TiDBデータベースの最新の安定バージョンを使用することをお勧めします。

重要

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

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を設定します。

ユーザードキュメント

パフォーマンスの向上

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

非同期コミット機能を有効にすると、トランザクションの待ち時間を大幅に短縮できます。たとえば、この機能を有効にすると、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の保守を容易にするためにヒストグラムのインデックスを作成します。

不完全なスケジューリングまたは不完全な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 = tureを介して有効にすることができます。＃18009
TiFlashがデータを圧縮またはソートするとき、それは多くのI/Oリソースを占有します。システムは、圧縮とデータの並べ替えによるI / Oリソースの使用を制限することにより、リソースの競合を軽減します。この機能はまだ実験的段階であり、 bg_task_io_rate_limitを介して有効にすることができます。

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

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

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

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

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

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

リージョンメンバーシップの変更の過程で、「メンバーの追加」と「メンバーの削除」は、2つのステップで実行される2つの操作です。メンバーシップの変更が終了したときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。導入されたRaftJointConsensusアルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。メンバーシップ変更時の「メンバーの追加」と「メンバーの削除」の操作を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