重要

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

TiDB 5.0 RC リリースノート

発売日: 2021年1月12日

TiDB バージョン: 5.0.0-rc

TiDB v5.0.0-rc は、TiDB v5.0 の前バージョンです。v5.0 では、PingCAP は、企業がデータベースパフォーマンス、パフォーマンスジッター、セキュリティ、高可用性、災害復旧、SQL パフォーマンスのトラブルシューティングなどについて心配することなく、TiDB に基づくアプリケーションを迅速に構築できるようにすることに専念します。

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 テストでは、1 TiB データのインポートのパフォーマンスが 254 GiB/h から 366 GiB/h に 40% 向上します。

構文

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

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

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

クラスター化インデックスは、テーブル内のデータの物理的なstorage順序を定義します。テーブル内のデータは、クラスター化インデックスの定義に従ってのみ並べ替えられます。各テーブルには、クラスター化インデックスが 1 つだけあります。

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

たとえば、テーブル（ 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側では＃2852 -serverでsecurity.redact-info-log = true設定をします。3 ＃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競合のバランスをとるために、圧縮率を自動的に調整します。1 構成項目でこの機能を有効にすると、遅延ジッターが大幅に削減されます＃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/h から 366 GiB/h に 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