© LY Corporation 検証を通して⾒えてきた TiDBの性能特性 2024/04/17 SIグループ クラウド統括本部 Database本部 Takuya Saeki / 佐伯 拓哉 

© LY Corporation 1.⾃⼰紹介 2.TiDBの選定理由 3.MySQL vs TiDB検証 4.まとめ 2 ⽬次 

© LY Corporation 1.⾃⼰紹介 2.TiDBの選定理由 3.MySQL vs TiDB検証 4.まとめ 3 ⽬次 

© LY Corporation Takuya Saeki / 佐伯 拓哉 LINEヤフー株式会社 Database本部 MySQL1team 2020 Yahoo! JAPAN新卒⼊社 旧Yahoo! JAPANの社内MySQL PFの開発・運⽤・保守をやってきました 最近は旧LINEのMySQL PF運⽤もやってます 4 ⾃⼰紹介 

© LY Corporation 1.⾃⼰紹介 2.TiDBの選定理由 3.MySQL vs TiDB検証 4.まとめ 5 ⽬次 

© LY Corporation • 社内VMのディスクサイズ上限(5TB) • Write Heavyなワークロードが1クラスタでは捌ききれない • ⼤量Writeに伴うレプリケーション遅延 6 MySQL運⽤上の課題 

© LY Corporation 現状はシャーディングで対応(50+ shards) • アプリケーションロジックの複雑化 • 運⽤コスト増 • 可⽤性の低下 7 シャーディングの課題 MySQL互換で⽔平スケール可能なデータベースソリューションがあれば… 

© LY Corporation 8 ⽔平スケーラブルなMySQL互換NewSQL 

© LY Corporation • ⽔平⽅向のスケーラビリティ (データ/Write負荷分散) • 強⼀貫性 • ⾼可⽤性 • MySQLとの互換性 • 豊富なエコシステム • オンプレ利⽤可能 • HTAPもいける etc… 9 TiDBのここがスゴイ 

© LY Corporation • アーキテクチャ/仕様の基本理解 • 社内オンプレ環境への展開⽅法 • Writeのスケーラビリティ検証 • 各種クエリのレイテンシ検証 10 TiDB調査 

© LY Corporation • アーキテクチャ/仕様の基本理解 • 社内オンプレ環境への展開⽅法 • Writeのスケーラビリティ検証 • 各種クエリのレイテンシ検証 11 TiDB調査 今⽇の内容 

© LY Corporation 1.⾃⼰紹介 2.TiDBの選定理由 3.MySQL vs TiDB検証 4.まとめ 12 ⽬次 

© LY Corporation go-tpcのtpccシナリオ(複数の販売区域と倉庫を持つ卸売り業者を模したOLTPベンチマークシナ リオ)によるパフォーマンステスト • MySQLとTiDBクラスタの⽐較 • スレッド数: 64,128,…,4096 • データサイズ: WAREHOUSE(倉庫数)=10000 • MySQL: 950GB/node • TiDB: 1380GB (max-replicas=3における全TiKVのdatadir合計) • 実⾏環境 13 Writeのスケーラビリティ検証1 – go-tpc tpcc MySQL (8.0.28) vCPU: 20core, Memory: 240GB, SSD: 2TB TiDB (v7.5) • TiDB(2-3nodes) vCPU: 16core, Memory: 120GB, SSD: 1TB • TiKV(3-6nodes) vCPU: 16core, Memory: 120GB, SSD: 1TB • PD(3nodes) vCPU: 8core, Memory: 16GB, SSD: 100GB 

© LY Corporation • MySQLはスレッド数を変えてもあまり かわらず、66k[tpmC]で頭打ち • TiDBはスレッド数2048程度までス ケール、最⼩のTiDBx2,TiKVx3でも MySQL以上のtpmCを⽰した • TiKVノードに対しても良好なスケーラ ビリティ、TiDBx3,TiKVx6台構成では Max 207k[tpmC]とMySQLの3倍以上 のスループット 14 Writeのスケーラビリティ検証1 – go-tpc tpcc 66295.7 207785.3 0 50000 100000 150000 200000 250000 64 128 256 512 1024 2048 4096 #thread TPC-C Transaction Per Minute [tpmC] MySQL TiDBx2, TiKVx3 TiDBx3, TiKVx3 TiDBx3, TiKVx4 TiDBx3, TiKVx5 TiDBx3, TiKVx6 

© LY Corporation UPDATE t1 SET k=k+1 WHERE id BETWEEN {start} AND {start + range - 1}; 15 Writeのスケーラビリティ検証2 – PK Range UPDATE • PKでrange scanにしてUPDATE • {range}(1UPDATEあたりの更新件数): 10,100,…,100万 • {start}は MIN(id) ≤ {start} ≤ MAX(id)-range+1 の範囲で1クエリごとにランダム • スレッド数は64,128,…,4096で実⾏して最⼤QPSを結果に採⽤ • 実⾏環境 MySQL (8.0.28) vCPU: 20core, Memory: 240GB, SSD: 2TB TiDB (v7.5) • TiDB(3nodes) vCPU: 16core, Memory: 120GB, SSD: 1TB • TiKV(3-6nodes) vCPU: 16core, Memory: 120GB, SSD: 1TB • PD(3nodes) vCPU: 8core, Memory: 16GB, SSD: 100GB 

© LY Corporation • MySQLはrangeに伴いMaxQPSは低下 するが、⼩さいrangeだと⾼いQPSを ⽰した • ⼀⽅、TiDBはrangeが増えても安定し ており、TiKV台数に対してQPSは順調 にスケールし、⾼rangeではMySQL以 上のスループットを達成 16 Writeのスケーラビリティ検証2 – PK Range UPDATE 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 10 100 1000 10000 100000 1000000 #range Max QPS MySQL TiKVx3 TiKVx4 TiKVx5 TiKVx6 

© LY Corporation • PKで1件引いてくる超単純なSELECT • cはtext型のオフページカラム • 単体レイテンシ結果を計測(100回平均) 17 各種クエリのレイテンシ検証1 – Single PK Read SELECT c FROM t1 WHERE id={PK}; 

© LY Corporation • TiDBはMySQLの4倍以上のレイテンシ • TiDB→TiKVのrpcリクエストがほとん どを占めている • コンピューティングとストレージ分離 しているためノード間通信がレイテン シに乗ってくる • TiKV(RocksDB)はLSM-tree構造で、 ⼀般にread性能は LSM < B+ 18 MySQL TiDB 0.32ms 1.38ms -- TiDBのEXPLAIN ANALYZE mysql> EXPLAIN ANALYZE SELECT c FROM t1 WHERE id=1; +-------------+---------+---------+------+---------------+--------------------------------------------------------------------------< | id | estRows | actRows | task | access object | execution info < +-------------+---------+---------+------+---------------+--------------------------------------------------------------------------< | Point_Get_1 | 1.00 | 1 | root | table:t1 | time:1.38ms, loops:2, RU:0.557254, Get:{num_rpc:1, total_time:1.35ms},< +-------------+---------+---------+------+---------------+--------------------------------------------------------------------------< 各種クエリのレイテンシ検証1 – Single PK Read 

© LY Corporation • 外部表100万件、両テーブルのPKで結合するJoinクエリ • Dependent SubqueryはTiDBでは相関解除されMerge Joinに変換されている 19 各種クエリのレイテンシ検証2 – Inner Join/相関サブクエリ -- Inner Join SELECT t1.c FROM t1 INNER JOIN ON t1.id = t2.id WHERE t1.id BETWEEN 1 AND 1000000; -- Dependent Subquery SELECT t1.id, (SELECT COUNT(*) FROM t2 WHERE t2.id = t1.id) as count FROM t1 WHERE t1.id BETWEEN 1 AND 1000000; 

© LY Corporation • TiDBはMySQLの1/5以下のレイテンシ を⽰す結果 • 外部表取得や結合処理がTiKVコプロセッ サーにプッシュダウンされており、複数 TiKVノードで並列処理 • NLJのMySQLと⽐べて並列処理による効 果が⼤きく出た 20 各種クエリのレイテンシ検証2 – Inner Join/相関サブクエリ 0 500000 1000000 1500000 2000000 2500000 3000000 Inner Join Dependent Subquery Latency [µs] (Range 1,000,000) MySQL TiDB 

© LY Corporation • TiDBはMySQLの1/5以下のレイテンシ を⽰す結果 • 外部表取得や結合処理がTiKVコプロセッ サーにプッシュダウンされており、複数 TiKVノードで並列処理 • NLJのMySQLと⽐べて並列処理による効 果が⼤きく出た 21 各種クエリのレイテンシ検証2 – Inner Join/相関サブクエリ 

© LY Corporation • スループット • 台数に対して良好なスケーラビリティ • MySQLでは捌ききれない量も対応可能 • レイテンシ • ⼩規模クエリならMySQLの⽅が早い傾向 • ⼤規模かつTiKVコプロセッサーにプッシュダウンできるとTiDBの⽅が早くなり得る • QPS/実⾏クエリともに⼤規模/スケーラビリティが要求されるにTiDBの強みが出てくる (⼩規模利⽤ならMySQLの⽅がパフォーマンスはいいかも) • Next • 導⼊に向けて議論/実際のWrite Heavyなワークロードで検証 22 まとめ 

© LY Corporation fin 23