TiDB 8.2 DMR新機能の紹介

ウェビナー開催日：2024年9月12日

このスライドでは、MySQL互換の分散型データベースTiDB 8.2 DMRの新機能について紹介します。
TiDB 8.2 DMRでは、TiProxyへの複数のロードバランスポリシーの追加、テーブル統計情報の読込の高速化、リソースコントロール機能の権限設定の強化など、TiDB 8.1以降にも続々と新機能を積極的に追加しています。
TiDB 8.2 DMRバージョンで追加された新機能は、2024年末に予定されている次のLTSでも利用可能となります。将来のLTSで予定されている新機能を事前に知っていただく機会としてご利用ください。

トピック：
・TiDB 8.2 DMR新機能の紹介
・TiDB 8.2 DMRをTiDB Cloudで利用するには

アーカイブ動画：https://youtu.be/wsSR8vvAMO8

Transcript

1. TiDB 8.2 DMR新機能の紹介 本多康夫 Technical support engineer at PingCAP Japan
2. これまでのウェビナースケジュール https://pingcap.co.jp/event/ 
 
 2023年9月14日(木) 14:00-15:00 TiDBとMySQLの互換性改善アップデート 2023年11月1日(木) 14:00-15:00 TiDB Operatorの紹介 2023年12月21日(木) 14:00-15:00 TiDB 7.4：MySQL 8.0互換性対応の紹介 2024年1月25日(木) 14:00-15:00 TiDB 7.5 LTS新機能の紹介 2024年2月29日(木) 14:00 - 15:00 TiDB Cloud APIとTerraform TiDB Cloud Providerの紹介 2024年3月28日(木) 14:00 - 15:00 TiProxyの紹介 2024年5月30日(木) 14:00 - 15:00 TiDB 8.0 DMR新機能の紹介 2024年7月25日(木) 14:00 - 15:00 TiDB Serverlessのベクトル検索機能の紹介 2024年9月12日(木) 14:00 - 15:00 TiDB 8.2 DMR新機能の紹介 ※過去開催アーカイブ：https://pingcap.co.jp/event-video/
3. 次回以降のウェビナースケジュール https://pingcap.co.jp/event/ 
 
 2024年10月予定 現在未定
4. おことわり • 本ウェビナー募集開始後、 TiDB 8.3.0 DMRが2024年8月22日にリリースされました ◦ ウェビナーの内容に TiDB 8.3.0 DMRの紹介を追加いたします ◦ すべての TiDB 8.2.0 DMRの機能はTiDB 8.3.0 DMRに含まれます
5. アジェンダ • TiDB LTS、DMRとは何か • TiDB 8.3.0 RMR新機能の紹介 • TiDB 8.2.0 RMR新機能の紹介 • TiDB 8.3.0 DMRを試すには • Q&Aとお知らせ
6. TiDB LTS、DMRとは何か
7. • 新機能を頻繁にリリースするサイクルと、比較的安定したリリースするサイクルの両立を図る • LTS - Long Term Supportの略 ◦ 約6ヶ月間隔でリリースされます ◦ 新機能が追加されます ◦ 不具合の修正を含むパッチリリース (例: TiDB 7.5.3やTiDB 8.1.1)も提供されます • DMR - Development Milestone Releaseの略 ◦ 約2ヶ月間隔でリリースされます ◦ 新機能が追加されます ◦ 不具合の修正を含むパッチリリースは提供されません ▪ DMRで発生した不具合の修正は次の DMRまたはLTSに含まれます ▪ DMRのパッチリリースバージョンは常に 0となります(v8.2.0, v8.3.0) TiDB LTS、DMRとは何か
8. • 2024年8月20にリリース TiDB 8.3.0 DMR
9. • 2024年7月11にリリース TiDB 8.2.0 DMR
10. • 次のTiDB LTSでは、これまでのDMRの新機能が累積して含まれます • DMR自体を導入しなくても、その新機能について前もって知っていただく機会となります • DMR自体をお試しいただき、フィードバックをいただくことで次の LTSでの機能が改善される可能性もあり ます DMRについて知る意義
11. TiDB 8.3.0 DMR新機能の紹介
12. • 解決する課題 ◦ 従来、パーティション表へのインデックスは「ローカルインデックス」のみ追加可能 ◦ プライマリキー制約、ユニークインデックスをパーティションキーに含める必要があった • ローカルインデックス ◦ テーブルのパーティションキーとインデックスのパーティションキーが同じ • グローバルインデックス ◦ テーブルのパーティションキーとインデックスのパーティションキーが異なる ◦ プライマリーキー制約とユニークインデックスをテーブルのパーティションキーと独立 • 制限事項 ◦ グローバルインデックスが付与されたパーティションテーブルに対するパーティションを変更する DDL(例: ADD PARTITION, DROP PARTITION, REORGANIZE PARTITION) ▪ グローバルインデックスの更新を伴います ▪ これらの操作はグローバルインデックスの更新が完了してから DDLの操作が完了します パーティション表にグローバルインデックス追加可能
13. • tidb_enable_global_index ◦ デフォルトはOFFのため、グローバルインデックスを利用するには ONに変更する mysql> set tidb_enable_global_index = on; Query OK, 0 rows affected (0.00 sec) mysql> select @@session.tidb_enable_global_index; +------------------------------------+ | @@session.tidb_enable_global_index | +------------------------------------+ | 1 | +------------------------------------+ 1 row in set (0.00 sec) • GLOBALキーワードを付与する mysql> CREATE TABLE t1 ( -> col1 INT NOT NULL, -> col2 DATE NOT NULL, -> col3 INT NOT NULL, -> col4 INT NOT NULL, -> UNIQUE KEY uidx12(col1, col2) GLOBAL , -> UNIQUE KEY uidx3(col3) -> ) -> PARTITION BY HASH(col3) -> PARTITIONS 4; Query OK, 0 rows affected (0.02 sec) パーティション表にグローバルインデックス追加可能
14. • 解決する課題 ◦ 従来:TiKVから検索される行の「すべての」列が TiDBに返されていた ◦ 多くの列があるテーブルのうち、ごく一部の列だけ返す場合に、不要なネットワークのデータ転送が 発生していました ◦ projection(射影)処理をTiKVにpushdownすることで、検索に必要な列だけ TiDBに返されます • projectionのpushdownが有効な処理 ◦ JSON関数を利用して、比較的長い JSON型の列から特定の属性のみ返す処理 SELECT JSON_EXTRACT(data, '$.name') FROM user ◦ JSON値属性を返す関数(JSON_DEPTHなど) SELECT JSON_DEPTH(data), name FROM users;. ◦ テーブルの一部の列のみ返す処理 SELECT name FROM users; projection(射影)のpushdownがデフォルトで有効
15. • tidb_opt_projection_push_down ◦ 本パラメータはTiDB 6.1.0で追加されデフォルト値は OFFでした ◦ TiDB 8.3.0以降の新規インストールでデフォルトは ONになります mysql> select @@global.tidb_opt_projection_push_down; +----------------------------------------+ | @@global.tidb_opt_projection_push_down | +----------------------------------------+ | 1 | +----------------------------------------+ ◦ TiDB 8.3.0 DMRへのアップグレードではデフォルト値は OFFのままです projection(射影)のpushdownがデフォルトで有効
16. • 解決する課題 ◦ TiDBでの統計情報取得処理 (analyze)にかかるオーバーヘッドが大きい ◦ where句、集計やjoinに利用されないカラムであってもすべてのカラムの統計情報を取得する • tidb_analyze_column_options ◦ 設定可能な値 : ▪ ALL すべてのカラムの統計情報を取得する (従来通り) ▪ PREDICATE 過去に実行されたSQLを元に、必要なカラムの統計情報を取得する ◦ TiDB 8.3.0以降の新規インストールのデフォルトは PREDICATE mysql> select @@global.tidb_analyze_column_options; +--------------------------------------+ | @@global.tidb_analyze_column_options | +--------------------------------------+ | PREDICATE | +--------------------------------------+ ◦ TiDB 8.3.0 DMRへのアップグレードでは ALLが設定されます ▪ 従来の動作を維持するため ◦ TiFlashなど非定型的なクエリーが多い場合は ALLに設定することを検討ください ▪ where句、集計やjoinに利用されるカラムが一定にならないと考えられるため 統計情報取得時に不要なカラムを除外可能
17. • 解決する課題 ◦ 複数のTiProxyサーバーを構成時、 TiProxyサーバー自体のフェイルオーバーが発生時 ▪ TiProxyに接続するアプリケーションが、 TiProxyのアドレスを書き換える必要があった ◦ 複数のTiProxyに対して透過的な仮想 IPアドレス(VIP)を設定可能になりました • tiproxy.toml ファイルに設定可能な項目 ◦ virtual-ip ▪ 仮想IPアドレスを CIDR形式(例: “10.0.1.10/24”)の文字列で指定 ▪ 複数のTiProxyがある場合に、一つだけがこの VIPをバインドします ▪ デフォルト値は ”” (空文字)で、VIPを設定しません ◦ interface ▪ 仮想IPアドレスをbindするネットワークインターフェース名 (例: “eth0”) ▪ デフォルト値は ”” (空文字)で、VIPを設定しません TiProxyに仮想IPアドレスを追加可能
18. • 解決する課題 ◦ TiDBサーバーからTiKVバッチ処理を改善 ◦ 従来のバッチ処理に加えて、スループットが大きいときにバッチにリクエストを追加可能 • tikv.toml ファイルに設定可能な項目 ◦ batch-policy ▪ 意味: TiDBからTiKVへのバッチ処理戦略を設定する ▪ 設定可能な値 • “basic” : TiDB 8.3.0未満のバージョンと同じ動作 • “standard” : 動的にバッチサイズを変更 (高スループットシナリオ用 ) • “positive” : 常にバッチにリクエストを追加 (待ち時間が増加する可能性 ) ▪ デフォルト値は ”standard” TiDBからTiKVへのバッチ処理性能の改善
19. • 解決する課題 ◦ 多数のテーブルが単一 TiDBクラスタにある場合(例: マルチテナント) ◦ INFORMATION_SCHEMAにあるテーブルの検索性能が遅くなることがありました • 下記INFORMATION_SCHMAのテーブルへの検索性能が向上しています ◦ CHECK_CONSTRAINTS ◦ COLUMNS ◦ PARTITIONS ◦ SCHEMATA ◦ SEQUENCES ◦ TABLE_CONSTRAINTS ◦ TIDB_CHECK_CONSTRAINTS ◦ TiDB_INDEXES ◦ TIDB_INDEX_USAGE ◦ VIEWS INFORMATION_SCHEMAテーブル検索の高速化
20. • 解決する課題 ◦ 多数のテーブルを単一TiDBクラスタに作成する場合 ◦ create tableやcreate databaseの実行速度が長期化することがありました • tidb_enable_fast_create_table ◦ テーブルの作成高速化を有効にする ◦ デフォルトはOFFです mysql> select @@global.tidb_enable_fast_create_table; +----------------------------------------+ | @@global.tidb_enable_fast_create_table | +----------------------------------------+ | 0 | +----------------------------------------+ mysql> set global tidb_enable_fast_create_table = on; Query OK, 0 rows affected (0.01 sec) mysql> select @@global.tidb_enable_fast_create_table; +----------------------------------------+ | @@global.tidb_enable_fast_create_table | +----------------------------------------+ | 1 | +----------------------------------------+ • TiDB 8.1.0に比べて、create databaseが19倍などの高速化 TiDB 8.3.0 Release Notes | PingCAP Docs • 制限事項 ◦ 本パラメータを有効にした状態で作成されたテーブルは TiCDCでレプリケーションされません create table, create databaseの高速化
21. TiDB 8.2.0 DMR新機能の紹介
22. • 解決する課題 ◦ 従来のTiProxy (v1.0まで)で利用可能なロードバランスポリシーは、接続数を均一にするのみ ◦ 接続先のTiDBサーバーの負荷などは考慮されなかった • TiProxy v1.1.0以降で利用可能な6つのロードバランス方式 ◦ Status based : TiDBサーバーが終了すると、 TiProxyが接続を他のTiDBサーバーに切り替える ◦ Health based : 接続先のTiDBサーバーが健全ではない場合、 TiProxyが接続を他のTiDBサー バーに切り替える ◦ Memory based : 接続先のTiDBサーバーにOut Of Memory(OOM)の懸念がある場合、 他のTiDB サーバーに接続を切り替える ◦ CPU based : 接続先のTiDBサーバーのCPU使用率が他に比べて高い場合、他の TiDBサーバー に接続を切り替える ◦ Location based : TiProxyサーバーと地理的に近い TiDBサーバーに接続を行う ◦ Connection count based : 複数のTiDBサーバーへの接続数を均一にするようにする TiProxyへの複数のロードバランスポリシーの追加
23. • TiProxy v1.1.0(TiDB 8.2.0と同時にリリース)で利用可能なロードバランスポリシー ◦ tiproxy.tomlファイルに設定する項目 ◦ policy ▪ 設定可能な値 • 前ページの6つのロードバランス方式を下記の優先度で考慮します • resource : Status,Health,Memory,CPU,Location,Connection count • location : Status,Location,Health,Memory,CPU,Connection count • connection : Status, Connection count ▪ デフォルト値 • resource TiProxyへの複数のロードバランスポリシーの追加
24. • 解決する課題 ◦ テーブル数が多い環境で、統計情報の読み込みに時間がかかっていた • tidb.tomlファイルに設定する項目 ◦ stats-load-concurrency ▪ 設定可能な値の範囲 : 0から128の整数値 • 0は自動調整 • 1から128は並列度 ▪ デフォルト値 • TiDB 8.2.0以降のデフォルト値 : 0 ◦ 0は統計情報の読み込みの並列度を自動的に調整する • TiDB 8.2.0未満の場合のデフォルト値 : 5 ◦ 統計情報の読み込みの並列度が 5 ◦ TiDB 8.2.0未満の場合に指定可能な最小値は 1(0は指定できません) ◦ 最大10倍までの統計情報の読み込みの高速化が期待できる テーブル統計情報の読み込みの高速化
25. • 解決する課題 ◦ 利用するリソースグループの変更 SET RESOURCE GROUP文が任意のデータベースユーザーで実 行可能だった ◦ 意図しないリソースグループが利用される可能性があった • tidb_resource_control_strict_mode ◦ TiDB 8.2.0以降の新規インストールのデフォルトは ON mysql> select @@global.tidb_resource_control_strict_mode; +--------------------------------------------+ | @@global.tidb_resource_control_strict_mode | +--------------------------------------------+ | 1 | +--------------------------------------------+ ◦ TiDB 8.2.0 DMRへのアップグレードでは OFF(従来の動き)が設定されます • リソースグループを変更できる権限の追加 ◦ RESOURCE_GROUP_ADMIN ▪ リソースグループの作成、変更、削除を実施可能な権限 ▪ SET RESOURCE GROUP文を実行可能な権限 ◦ RESOURCE_GROUP_USER ▪ SET RESOURCE GROUP文を実行可能な権限 • なお、SUPER権限を持つユーザーは上記の操作が可能です リソースコントロール機能の権限設定の強化
26. • 解決する課題 ◦ JSON型のバリデーションを外部で行う必要があった ◦ JSON関数でTiKVにpushdown指定ないものがあった • JSON型のバリデーションを行う関数を追加 ◦ JSON_SCHEMA_VALID() • JSON型のTiKVへのpushdownを行う関数を追加 ◦ JSON_ARRAY_APPEND() ◦ JSON_MERGE_PATCH() ◦ JSON_REPLACE() JSON関連
27. • 解決する課題 ◦ TiDBサーバーでのソート処理は順次処理のみ • tidb_executor_concurrency ◦ TiDBサーバーで並列処理可能な SQL operator(実行計画に含まれる )の並列度 mysql> select @@global.tidb_executor_concurrency; +------------------------------------+ | @@global.tidb_executor_concurrency | +------------------------------------+ | 5 | +------------------------------------+ ◦ デフォルト値は 5、設定可能な範囲は 1から256の整数値 • 本パラメータはTiDB 5.0から存在しています ◦ 従来は、index lookup, hash join, hash aggregationなどのSQL operatorに対応していた ◦ TiDB 8.2からsort処理もtidb_executor_concurrencyの設定に基づき並列に処理されます パラレルソート
28. • 解決する課題 ◦ SQLの実行計画をキャッシュできない場合がある ◦ キャッシュできない場合の理由をユーザーが知る方法がなかった • INFORMATION_SCHEMA.STATEMENTS_SUMMARYに列を追加 ◦ PLAN_CACHE_UNQUALIFIED ▪ 該当SQLがプランキャッシュにヒットしなかった回数 ◦ PLAN_CACHE_UNQUALIFIED_LAST_REASON ▪ 最後に該当SQLがプランキャッシュにヒットしなかった理由 ▪ 例 • query has uncorrelated sub-queries is un-cacheable • query has 'database' is un-cacheable 実行計画がキャッシュされない理由の表示
29. TiDB 8.3.0 DMRを試すには
30. • ローカル(tiup playground) ◦ macOS, Linux, Windows WSL環境ではtiup playgroundを利用してTiDB 8.3.0をお試しいただけま す % tiup playground v8.3.0 • TiDB Dedicated ◦ TiDB DedicatedでのデフォルトのTiDBバージョンはLTSのみです ◦ TiDB DedicateクラスタをTiDB 8.3.0 DMRへのバージョンアップにて対応します ◦ テクニカルサポートあてにアップグレードを希望する旨のチケットを起票ください • TiDB Serverless ◦ TiDB Serverlessではマルチテナント構成のため、バージョンが固定されております ◦ TiDB ServerlessではTiDB 8.3.0 DMRのご利用はできません • Note: ◦ TiDBのDMRバージョンは新機能の検証などの目的で提供しており、本番環境でのご利用は推奨し ておりません TiDB 8.3.0を試すには
31. Q&Aとお知らせ
32. • TiDB関連の製品名称が下記の通り変更となりました ◦ TiDB Dedicated → TiDB Cloud Dedicated ◦ TiDB Serverless → TiDB Cloud Serverless ◦ TiDB → TiDB Self-Managed ▪ TiDB Self-Managed はTiDBクラスタをお客様環境に tiupあるいはTiDB Operatorを利用した 環境で利用される場合の製品名称です。 製品名称の変更
33. Thank You! 
 https://www.pingcap.com/
 info@pingcap.com