🚀

TiDB v8.1.0 の新機能/変更点を紹介！

2024/05/29に公開

MySQL

祝 2024 年 5 月 24 日に TiDB の v8.1.0 がリリースされました！

詳細なリリースの内容については、上記のリリースノートにまとまっているのですが、今回は、今回追加された機能についてをざっくりまとめていこうと思います！

v7.6.0 -> v8.1.0の機能比較

クラスタースナップショットの復元速度向上
多数のテーブル作成速度向上
Active PD Followerの導入
バルクDMLの提供
スキーマ情報のキャッシュ設定
グローバルソート機能(GA)
クロスデータベースバインディング
TiProxyのサポート(GA)
DMのMySQL8.0の正式サポート
その他

TiDBにおける LTS / DMRの違いについて

TiDBでは、新機能を頻繁にリリースするサイクルと安定したリリースするサイクルの両立を図るために、LTSとDMRと呼ばれるリリースバージョンがあります。

LTS - Long Term Supportの略

約6ヶ月間隔でリリース
新機能追加
不具合修正を含むパッチリリース

DMR - Development Milestone Releaseの略

約2ヶ月間隔でリリース
新機能追加
不具合修正を含むパッチリリースは提供されない
- DMRで発生した不具合の修正は、次のDMR/LTSに含まれる
- DMRのパッチリリースバージョンは常に0となる(v7.2.0, v7.3.0 など)

今回のバージョンアップはこのうちのLTSに該当するものです。
なお※(実験的な機能)については、今後廃止される可能性もあるので注意してください。

1: クラスタースナップショットの復元速度向上

そもそもTIDBにおけるバックアップの仕組みは2種類存在します。

TiDBにおけるバックアップの仕組み

ログバックアップ

ログバックアップタスクはすべての TiKV ノードで実行され続け、指定されたストレージに TiDB データの変更を小さなバッチで定期的にバックアップ

スナップショット(完全)バックアップ

クラスターのスナップショットを指定されたストレージにバックアップ

今回のアップデートのポイントは？

クラスタースナップショットの復元速度が向上する機能(coarse-grained Region scattering algorithmによるスナップショット復元となる)がGAされたというものです。
SSTファイルのダウンロードと取り込み操作の相互影響の軽減、テーブル統計の復元処理の高速化などを最適化します。
今までは、--granularity="coarse-grained"のパラメータを指定する形だったのが、デフォルトで有効化した形になります。

SSTファイルって何？と思われた方は、以下のブログをチェック！

2: 多数のテーブル作成速度向上 (※実験的な機能)

TiDB V7.6.0で導入されたシステム変数として、tidb_ddl_versionがサポートされました。
この機能は、TiDB DDLの新バージョンv2を使用するかしないかを設定できるものになります。
https://docs.pingcap.com/tidb/v7.6/ddl-v2

今回のアップデートでは、この機能の変数名が変更されtidb_enable_fast_create_tableになったというものです。

この機能何が嬉しいのか？

例えば、バルクでテーブル作成をするような(※外部キー制約は含められない)場合、このシステム変数をONにしておくと、ステートメント内のテーブル作成でパフォーマンスが最適化される形になります。

3: Active PD Followerの導入(※実験的な機能)

多数のリージョンを持つようなTiDBクラスターの場合、ハートビート処理とタスクのスケジュール設定により、PD LeaderへのCPU負荷が急増します。
RaftはPDでも実装されているため、Leader/Followerが存在します。システム変数、pd_enable_follower_handle_regionをONに設定すると、TiDBはリージョン情報要求を全てのPDサーバに均等に分散し、PD Followerもリージョン要求を直接処理できることで、Leaderへの負荷を軽減する動きをします。

※ なお、ここでいうリージョンは、ストレージにおいて小さく区切った保存領域を指し、地理的な話ではないことは注意してください。

4: バルクDMLの提供(※実験的な機能)

`tidb_dml_type = "bulk"を設定することで利用可能です。
ユースケースとして、大規模なクリーンアップジョブ、結合、集計などの大量データが競合なく書き込まれるシナリオに適します。
機能としては、トランザクションを保証しつつ、OOMの問題を軽減しながら大規模なバッチDMLタスクを処理できます。

DMLステートメントの実行モードの違い

このtidb_dml_typeには、設定できる値は２つあります。

standard(デフォルト)

TiDBトランザクションはコミットされる前にメモリにキャッシュされます。

bulk

TiDBトランザクションの実行中、データはTiDBメモリに完全にキャッシュされるのではなく、メモリ使用量を削減し、書き込み負荷を軽減するためにTiKVに継続的に書き込まれる動きとなります。

5: スキーマ情報のキャッシュ設定(※実験的な機能)

システム変数として、tidb_schema_cache_sizeとして、[0, 9223372036854775807]の間の中でスキーマキャッシュのサイズを制御することができるようになりました。(デフォルトは0)

これにより、設定されたメモリサイズを意識し、LRUアルゴリズムを使用して、必要なテーブルをキャッシュし、スキーマ情報によって占有されるメモリを効果的に削減することができます。

6: グローバルソート機能(GA)

CREATE INDEXやIMPORT INTOなど処理で一時的なディスク容量を共有の外部ストレージに保存することでソートの効率化させる機能がグルーバルソート機能になります。
なお。現時点では、クラウドストレージとして、Amazon S3のみサポートしています。

グローバルソート機能の動き

グローバルソートは2段階で動作します。

①: データのスキャンと準備

Key-Valueペアを作成しS3へアップロード
Key-Valueペアの統計情報もS3へアップロード

②: データの分類と配布

S3から統計情報を利用
データを各TiDBサーバに再分割

7: クロスデータベースバインディング

データが異なるデータベース間でデータの一貫性を保ちながら、結合クエリを実行できるので、データ統合の複雑性が軽減できます。
特に、このようなクエリの場合に一貫した実行計画を適用できるため、全体的な処理性能が向上します。

ユースケース: SaaSやPaaSを構築している場合、各テナントのデータが別々に保存するケースがある。この時の分析などのクエリに効いてきます。

(検証)クロスデータベースバインディングを試すとどうなるのか？

試したクエリ

-- データベースの作成
CREATE DATABASE IF NOT EXISTS db1;
CREATE DATABASE IF NOT EXISTS db2;

-- テーブルの作成
CREATE TABLE db1.table1 (
    id INT PRIMARY KEY,
    value VARCHAR(100)
);
CREATE TABLE db2.table2 (
    id INT PRIMARY KEY,
    value VARCHAR(100)
);

-- サンプルデータの挿入
INSERT INTO db1.table1 (id, value) VALUES (1, 'A'), (2, 'B'), (3, 'C');
INSERT INTO db2.table2 (id, value) VALUES (1, 'X'), (2, 'Y'), (3, 'Z');

-- データベース間のバインドを作成
CREATE GLOBAL BINDING USING SELECT /*+ use_index(table1, value), use_index(table2, value) */ * FROM *.table1, *.table2;

-- データベースを統合したクエリでバインディングされているかを確認
SELECT * FROM db1.table1, db2.table2;
SELECT @@LAST_PLAN_FROM_BINDING;

実行結果画面

8: TiProxy(GA)

TiDB特化SQL Proxy: TiProxy がGAしました！

これは、TiDBの状態を把握してユーザーコネクションを振り分ける機能で、アップグレード時にもコネクションの切断がない動きとなります。

9: DMのMySQL8.0の正式サポート(GA)

TiDBのマイグレーションツールとして、Data Migration(DM)というツールを提供しています。
このDMがMySQL8.0を正式にサポートしたというのが機能追加となります。

10: Resource Controlにおける機能改善 (Runawayクエリ)

この機能は、一定時間を超えるクエリに対して制御が可能になったというものです。

これまでは？

リソースグループ「全体」に対してのリソース制御ができました。
ただ、個々のクエリに対して、実行時間の制御ができなかった

この機能により嬉しいことは？

個々のクエリに対して、一定の実行時間を超えるクエリ (Runawayクエリ)を制御することが可能になります。
一定時間を超えたクエリに対し優先度を下げたり、KILLすることが可能です。

Runawayクエリの制御方法 ①

Resource ControlのQUERY_LIMITに3つのパラメータが追加されました。

EXEC_ELAPSED: 実行時間
- クエリ実行時間がこの制限を超えるとRunawayクエリとして識別
ACTION:行うアクション
- EXEC_ELAPSEDを超えたクエリに対するアクション
  - ACTIONの操作として3つ
    - DRYRUN: information_schema.runaway_watchsテーブルにクエリを記録
    - COOLDOWN: 該当クエリの優先度を一番低くする
    - KILL: 該当クエリをKILL
WATCH: 同一クエリの判断基準
- 一定期間内に同じ/類似クエリが再度発生した場合、対応するアクションを実行します。
  - WATCHに設定できるもの3つ
    - EXACT: 全く同じ文字列のSQLのみを同一として扱う
    - SIMILAR: Plan digestが同一であれば同一SQLとして扱う
    - PLAN: Plan digestが同一であれば同一SQLとして扱う

11: インデックス使用統計の監視テーブル

適切なインデックス設計のための使用できる機能が導入されました。

INFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブル
=>現在の TiDB ノード上のすべてのインデックスの使用統計を取得可能

sys.schema_unused_indexesビュー
=> TiDB の最後の起動以降に使用されていないインデックスを記録

12: その他のアップデート

TiCDCのシンプルプロトコルのサポート

例えば、Kafka をダウンストリームとし、changefeed構成で”simple protocol”を指定すると、各行の変更または DDLイベントをメッセージとしてエンコードし、データ変更イベントをダウンストリームに送信します。

Debeziumプロトコルのサポート

データベースの変更をキャプチャするためのツールです。
キャプチャされた各データベースの変更を「イベント」と呼ばれるメッセージに変換し、Kafka に送信します。

TiCDCのクライアント認証のサポート

TiCDCが Mutual Transport Layer Security (mTLS) または TiDB ユーザー名とパスワードを使用したクライアント認証をサポートしました。

まとめ

いかがだったでしょうか？
ぜひ、tiup playgroundで試してみてください！