重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

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

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ジョイントコンセンサスアルゴリズム。これにより、リージョンメンバーシップの変更中にシステムの可用性が確保されます。
データベース管理者 (DBA) が SQL ステートメントをより効率的にデバッグするのに役立つ、最適化されたEXPLAIN機能と非表示のインデックス。
企業データの信頼性を保証します。 TiDB から AWS S3 ストレージおよび Google Cloud GCS にデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。
AWS S3 ストレージまたは TiDB/MySQL からのデータインポートまたはデータエクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築するのに役立ちます。たとえば、TPC-C テストでは、1 TiB のデータをインポートするパフォーマンスが 254 GiB/h から 366 GiB/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 = trueで有効にすることができます。 #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 つのステップで実行されます。メンバーシップの変更が完了するときに障害が発生した場合、リージョンは使用できなくなり、フォアグラウンドアプリケーションのエラーが返されます。導入されたRaft Joint Consensus アルゴリズムは、リージョンメンバーシップの変更中のシステムの可用性を向上させることができます。会員変更時の「会員追加」「会員削除」の操作をまとめて全会員に送信します。変更プロセス中、リージョンは中間状態にあります。変更されたメンバーに障害が発生した場合でも、システムは引き続き使用できます。ユーザーは、 pd-ctl config set enable-joint-consensus trueを実行してメンバーシップ変数を変更することで、この機能を有効にすることができます。 #7587 #2860

ユーザー文書
関連する問題: #18079

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

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

バックアップと復元

バックアップと復元ツール (BR) は、AWS S3 と Google Cloud GCS へのデータのバックアップをサポートしています。 ( ユーザー文書 )
Backup & Restore ツール (BR) は、AWS S3 および Google Cloud GCS から TiDB へのデータの復元をサポートしています。 ( ユーザー文書 )
関連する問題: #89

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

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