TiDB 5.0 RC リリースノート

発売日：2021年1月12日

TiDB バージョン: 5.0.0-rc

TiDB v5.0.0-rcはTiDB v5.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ジョイントコンセンサスアルゴリズム。
最適化されたEXPLAIN機能と非表示のインデックスにより、データベース管理者 (DBA) は SQL ステートメントをより効率的にデバッグできるようになります。
エンタープライズデータの信頼性を保証します。TiDBからAWS S3storageやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドstorageプラットフォームからデータを復元したりできます。
AWS S3storageまたはTiDB/MySQLとの間でのデータインポート/エクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1TiBデータのインポートパフォーマンスが254GiB/時間から366GiB/時間へと40%向上しました。

SQL

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

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

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

クラスター化インデックスは、テーブル内のデータの物理的なstorage順序を定義します。テーブル内のデータは、クラスター化インデックスの定義に従ってのみソートされます。各テーブルには、クラスター化インデックスが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

Security

エラーメッセージとログファイルのわかりやすさをサポート

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フェーズコミットの第1フェーズが完了した後に結果をクライアントに返すようになりました。第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 = true . ＃18009から有効化できます。
TiFlash がデータを圧縮またはソートすると、大量の I/O リソースが消費されます。システムは、圧縮とデータソートによる I/O リソースの使用を制限することで、リソースの競合を軽減します。この機能はまだ実験的であり、 bg_task_io_rate_limitで有効化できます。

リアルタイム BI / データウェアハウスシナリオにおけるTiFlashの安定性を向上

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

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

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

高可用性と災害復旧

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

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

ユーザードキュメント
関連号: ＃18079

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

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

バックアップと復元

バックアップ＆リストアツール（BR）は、AWS S3とGoogle Cloud GCSへのデータのバックアップをサポートしています。（ユーザードキュメント）
バックアップ＆リストアツール(BR)は、AWS S3およびGoogle Cloud GCSからTiDBへのデータの復元をサポートしています。( ユーザードキュメント )
関連号: ＃89

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

TiDB Lightning は、 AWS S3storageから TiDB へのAuroraスナップショットデータのインポートをサポートしています。(関連問題: ＃266 )
1 TiB のデータを DBaaS T1.standard にインポートする TPC-C テストでは、パフォーマンスが 254 GiB/時間から 366 GiB/時間へと 40% 向上しました。
Dumpling は、TiDB/MySQL から AWS S3storageへのデータのエクスポートをサポートしています (実験的) (関連する問題: ＃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