MySQLインターフェースNewSQL TiDBの実力とは

このスライドは分散型NewSQLデータベースであるTiDBについて紹介します。

トピック
・TiDBについて
・TiDBのデータ保持について
・ローカル環境での構築

アーカイブ動画：
https://youtu.be/EJTsz8x-lng

Transcript

1. MySQLインターフェースNewSQL
 TiDBの実力とは

2. • TiDBについて
 • TiDBのデータ保持について 
 • ローカル環境での構築 

3. 製品・プロジェクト
 ACIDサポート KVS 
 
 • 2016年04月 リリース 
 • 260+ contributors 
 • CNCF Graduated Project 
 (成熟したプロダクトとして認定) 
 カオスエンジニアリング 
 
 • 2019年12月 リリース 
 • 2.6 K stars
 • 50+ contributors 
 分散型データベース 
 
 • 2015年04月 リリース 
 • GitHub's Top 100 Most Valuable 
 Repositories Out of 96 Millionに選出
 • 490+ contributors 
 クラウド型DataBase 
 フルマネージドサービス 
 サービス型
 サブスクリプション型
 NewSQL型
 RDB＋Analyze
 Key-Value型
 テストアプリ
 来年リリース予定
4. 2010 NewSQL
 
 - リレーショナルモデル&SQL 
 - 増強した拡張性
 - 分析クエリには不向き 
 2020 19XX Traditional RDBMS 
 
 - リレーショナルモデル & SQL 
 - ACIDトランザクション 
 - 拡張性に弱点
 2000 KVS/NoSQL
 
 - 簡単なデータモデル 
 - 高いスループットを実現 
 - 複雑なクエリと
 ACIDトランザクションが 
 サポートされていないのが弱点 
 +α
 （TiDB）
 
 - トランザクション処理と リアルタイム分析クエリを両立 
 進化したSQLデータベース
 NewSQL ＋ HTAP製品
 TiDBの位置づけ

5. 分散型SQLデータベース オンライン拡張とリアルタイム分析可能 OLTP 水平拡張可能なリレーショナルデータベース ーーー オンラインでの拡張 • シングルTiDBクラスターで600TB以上拡張 • シングルテーブルで数兆レコード対応 OLAP リアルタイム分析 ーーー トランザクション処理と分析処理 • トランザクションデータと連携した分析レポート • 数兆レコードを利用した分析が可能 TiDBアーキテクチャー

6. QPS100万近い値まで可能 ※理論値では、QPS300万達成可能
 容量は無限大（性能考慮で600TiB程度目安）の拡張性
 複数のデータベースをひとつのTiDBで
 運用できる能力
 TiDBアーキテクチャー

7. TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノードのみ必要 
 SQL解析レイヤー
 ( TiDB Cluster )
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD データストアレイヤー 
 ( TiKV Cluster )
 アプリ側でやっていたMVCC管理をTiDBノードで実装 
 KVSなどで苦労した整合性を悩まず、しかも MySQLプロトコルで使える
 Raftを採用したKVSのバックアップを兼ね備えた データ分散
 複数Cluster（TiDB,TiKV,PD）で運用
 役割別でCluster化することによりリソース管理の容易さを実現
 TiDBの司令塔
 TiDBアーキテクチャー（OLTP処理）

8. PingCAP.com TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB TiDB Cluster
 TiKV Cluster
 負荷分散・領域管理 
 3ノードのみ必要 
 SQL解析レイヤ
 PD Cluster
 TiDB TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TiKV TSO / Data Location
 Metadata
 PD PD PD データレイヤ
 gRPCやpush downを使ってKVS のやり取りでデータ読み書き 
 TiFlash Cluster 
 TiFlash Metadata
 kvdata
 kvdata
 OLAP用カラムデータ 
 読み取り専用 
 Delta Tree
 TiFlash TiDBアーキテクチャー（OLAP処理）

9. msレベルで常に同期、クエリ実行したタイミングの最新データで分析をするアーキテクチャーを採用 
 レプリケーション遅延などによるデータ不整合の心配がない 
 4
 3
 TiKV(Leader)
 TiFlash
 TiDB
 ② TiKV側に最新のデータが来ていないか確認
 ① 読み込み要求
 ③ 差があれば、同期を開始
 ④同期完了後に処理開始
 TiKVとTiFlashデータはリアルタイム同期を実現

10. PingCAP.com TiDB TiDB TiDB Cluster
 TiKV Cluster
 SQL解析レイヤ
 PD Cluster
 TiDB TiKV TSO / Data Location
 Metadata
 PD Application via MySQL Protocol データレイヤ
 TiFlash Cluster 
 Metadata
 kvdata
 kvdata
 メインの仕事は、MySQLプロトコルをKV形式に変更 
 TiKV(row型)かTiFlash(cloum型)が良いか判別、joinでは、hash joinや、sort merge joinを使うかなどを判断 
 Raftによるデータの整合性の担保や、coprocessorによるTiDBから プッシュダウンされた処理も実施 
 TiFlashのlarnerのデータ配置なども Row型のデータを保持 
 TiDBにアクセス場所の指示だ しやデータ分割やマージ TSO の払い出し
 
 基本読み取り専用のクラスターHBaseの worker的な処理(MPP)を実施 Column型 のデータを保持
 TiDBアーキテクチャー

11. - Analytics処理の有無 
 AnalyticsとトランザクションをTiDBプラットフォームで利用可能 
 コマンド一つで連携、構築可能 
 必要なテーブル単位でレプ リケート指定可能 TiFlash RowData RowData RowData RowData TiKV すべてリアルタイムデータ 利用 テーブル単位で分析したいデータを指定可能 
 シナリオ1:APのみ検索
 TiDB
 TiFlash
 シナリオ2:TPのみ検索 
 TiDB
 TiKV
 シナリオ3:TP+AP検索
 TiDB
 TiKV
 TiFlash
 TiFlash Clusterで簡単リアルタイム分析が可能
 TiDBがコストベースでクエリを判別し、適切なクラスターを選択
 TiDBアーキテクチャー

12. TiDBアーキテクチャー
 ポイントセレクトからビックデータまですべてのクエリを 高速に返すことが可能
 特定ユーザのwindow関数
 例）SELECT name,DATE_FORMAT(`time`, '%Y%M') as gtime , AVG(sales) OVER (PARTITION BY gtime) FROM tenant_master as tm, user_sales as us where tm.name = “pingcap”; データ量が増えた場合にバッチ処理へ バッチ処理なしでリアルタイムに結果を出力が可能に 個別ユーザの集計するクエリが多くなると遅くなるとクエ リでは対応できない為、バッチ処理が必須

13. HTAPで実現できるリアルタイム集計
 米国運輸省からの航空機の離陸と着陸の1987年から現在までの定刻条件の集計処理
 OLTPだけでは苦手だった集計クエリが高速化にランキング集計やマイページの統計情報出力で活躍 
 MySQLでは、4～5分かかっていたクエリが1秒未満に
 TiDBアーキテクチャー

14. SQL解析レイヤーTiDB Clusterの特徴
 MySQLインターフェースに準拠、マルチマスター構成、TiKVへ処理をオフロード
 LB
 TiDB TiDB mysql > SELECT table_name,column_name FROM tableA WHERE column_name > [ 検索条件 ]; 
 全ノードでinsert,updateのSQL対応が可能な為、LBでまとめる事が可能
 SQLをKVのデータへ変換を行いTiKVへ処理、もしくは、検索条件をTiKVに処理 をオフロードさせる
 TiDB クエリの増加 
 ノード追加で対応 
 ノード追加は、ステートレスな役割のため、即座に追加可能
 TiDBアーキテクチャー

15. 並列度を高めSQLの処理を高速化
 TiDBがアグリゲーションする事によりデータ量が増えた場合、 
 TiKVノードが増える為、並列度を向上させ性能劣化させない事 
 が可能
 データ量が増えてもSQLの性能を高速化させる技術
 TiKV TiKV TiKV データ量が増えた場合もノードも増えるため、並列度が向上
 TiKV TiKV TiKV TiKV バッチ処理による書き込みSQLの高速化
 最大256KeyをバッチでまとめてTiKVとのネットワーク 
 往復回数を減らし一度で書き込みを実施し高速化 
 TiDB batch(1⇒value1, 2⇒value2, 3⇒value3….256⇒value254)をまとめてワンリクエストでTiKVに 書き込みを実行
 column_name > [検索条件1/3]
 column_name > [検索条件1/3]
 column_name > [検索条件1/3]
 TiDB column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 TiDB TiDBアーキテクチャー

16. データストアレイヤーTiKV Clusterの特徴
 冗長構成、オンラインでの容量伸縮、ノーメンテナンス運用の実現
 TiKV A Region 3
 バックアップ 
 Region 1*
 読み書き可能 
 Region 2
 バックアップ 
 TiKV B Region 3
 バックアップ 
 Region 1
 バックアップ 
 Region 2*
 読み書き可能 
 TiKV C Region 3*
 読み書き可能 
 Region 1
 バックアップ 
 Region 2
 バックアップ 
 ユーザーテーブル
 データサイズは、デフォルト 96MB 
 ※小さいサイズにする事で柔軟性を確保
 Raftログによるコンセンサスアルゴリズム 
 ひとつの読込/書込ポイントと2つのバックアップ 
 ※ 圧縮を行っているので、バックアップありの状態でMySQL一台の容量とほぼ同じになる事も 
 96MB 96MB 96MB TiDBアーキテクチャー

17. 冗長構成
 ノードが分かれているので、ＤＣを超えて配置可能 
 データベース単体でＤＲも実現可能 
 （クエリーの応答が断ではなく） 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 オンラインでの容量伸縮
 96MBという小さいサイズで管理している為、 
 ノード追加した瞬間からデータ移行が開始 
 バックアップが読み書きを引き継ぐ機能により様々な問題を解決
 昇格（リーダ） 
 ノーメンテナンス運用を実現
 ファームウェアアップデート時にリーダーを 
 別ノードへ移動しローリングアップグレードが可能 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 TiKV バックアップデータを移動し 
 リーダーに昇格 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 昇格(リーダ) 
 まず、このノードをアップグレードしリーダを 移動しながら順に対応 
 TiDBアーキテクチャー

18. TiDBの司令塔 PD Clusterの特徴
 データ配置の完全自動化、クエリ情報の収集
 3ノードによる冗長構成 
 PD Cluster
 PD PD PD スケジューラーによるデータの自動運用
 アクセス先の偏りを調整 
 balance-leader-scheduler 
 データの偏りを調整 
 balance-region-scheduler 
 高負荷なデータを調整 
 hot-region-scheduler 
 アップグレード時にデータを退避 
 evict-leader-scheduler 
 データ量が減ったregionのマージ 
 region merge schedule 
 データ量が増えたregionの分割 
 region split schedule 
 heartbeats
 clusterCache
 coordinator
 balance leader 
 balance region 
 hot region 
 TiKV PD TiKVからのハートビートによりデータの状態を把握
 TiDBアーキテクチャー

19. - データアクセスの自動負荷分散 
 負荷のかかっているブロックを分割して分散可能 set config tikv split.qps-threshold=3000 ※例) qps3000で分割(デフォルト) 
 ユーザーテーブル
 3,000QPSを超えたら、 
 データ分割を行い
 リバランスを実施し性能担保 
 Region RegionA RegionB 仮にこのデータに4,000QPSが来たと想定
 ※ ID1に2,000QPS, ID2に2,000QPS想定
 分割したRegionで 
 2,000QPSになり閾値以下に！！ 
 PDスケジューラによる自動シャーディングの技術
 ユーザーテーブル
 ユーザーテーブル
 TiDBアーキテクチャー

20. - データアクセスの自動負荷分散 
 オンメモリ上に全ての実行クエリ(最大10日間)の
 詳細情報の取得が可能にクエリの劣化や異常なクエリの発見に役立つ 
 ステートメント一覧
 標準出力項目
 トータル実行時間、平均レイテンシー、実行回数 
 該当のクエリをクリックすると実行計画、各種ステータスの状況確認が可能
 TiDBアーキテクチャー

21. • TiDBについて
 • TiDBのデータ保持について 
 • ローカル環境での構築 

22. 特定のキー/データの持ち方 
 Key
 Data(CF_DEFAULT) 
 Lock(CF_LOCK) 
 Write(CF_WRITE)
 Bob
 7: $3
 6:
 5: $10
 7:primary
 6:
 5:
 7:
 6: put@5
 5:
 Google Percolatorによるスナップショット
 特徴： ① 追記型
 ② Data Lock WriteのKVで役割を持たせMVCCを実現するRowデータを管理
 Google検索インデックスの更新に使用される増分データ処理のアーキテクチャ 
 CF_WRITEのshort_valueは、 
 ・ Put データ書き込み完了 
 ・ Delete データ削除
 ・ Rollback ロールバック
 ・ Lock select …. for update ステータス
 Column Family 
 Key
 Value
 備考
 CF_Default
 key, start_ts 
 value
 実データを保存 
 CF_Lock
 key
 start_ts, primary_key, ttl 
 2フェーズコミットのロック用 
 CF_Write
 key, commit_ts 
 start_ts [, short_value] 
 データのステータス管理用 
 ※ gc_life_timeの閾値で自動でデータ削除 
 ※ TS PDが発行するシステムユニークな増分ID 

23. 特定のキー/データの持ち方 
 Key
 Data(CF_DEFAULT) 
 Lock(CF_LOCK) 
 Write(CF_WRITE)
 Bob
 7: $3
 6:
 5: $10
 7:primary
 6:
 5:
 7:
 6: put@5
 5:
 Google Percolatorによるスナップショット
 BobのデータをSELECTしてきたケース
 Bobのデータを更新しているユーザＡ 
 Bobのデータを参照するユーザＢ 
 ① Writeの状態確認
 ② Writeの状態から読み取り可能なデータをSelect 

24. Google Percolatorによるスナップショット
 2PC(two phaze commit)によるトランザクション処理
 ノードをまたがるBobとJOEのデータ（トランザクション）を更新してきたケース
 データを更新しているユーザＡ
 Region 1
 Bobのデータがあるノード 
 Key
 Data
 Lock
 Write
 Bob
 7:$3
 6:
 5: $10
 7:primary
 6:
 5:
 7:
 6: put @ 5
 5:
 Key Data Lock Write Joe 7:$9 6: 5: $2 7:Primary@Bob.bal 6: 5: 7: 6: put @ 5 5: Region 2
 Joeのデータがあるノード 
 ① BobとJoeのデータのLockが取れるか確認 
 ② ロックが取れたらCOMMIT処理へ 
 （BobのPrimaryのLockを解除)

25. Google Percolatorによるスナップショット
 ノードをまたがるBobとJOEのデータを更新してきたケース
 Bobのデータを更新しているユーザＡ 
 Region 1
 Bobのデータがあるノード 
 Key
 Data
 Lock
 Write
 Bob
 8:
 7:$3
 6:
 5: $10
 8:
 7:
 6:
 5:
 8: put @ 7
 7:
 6: put @ 5
 5:
 Key Data Lock Write Joe 7:$9 6: 5: $2 7:Primary@Bob.bal 6: 5: 7: 6: put @ 5 5: Region 2
 Joeのデータがあるノード 
 ② BobのPrimaryのLockを解除しデータ確定に 

26. Column Family 
 Key
 Value
 CF_Write
 key, commit_ts 
 Lockステータスあり 
 悲観ロック
 楽観ロック
 Column Family 
 Key
 Value
 CF_Write
 key, commit_ts 
 Lockステータスあり 
 WAITでロック解放を待つ
 ロックでの待ちは発生なし
 Select … for updateによるロック挙動
 Google Percolatorによるスナップショット

27. 楽観ロック時
 両方のトランザクションをCommitした 場合、
 for updateがある為、 
 再度データ取得が必要でエラーとな る
 Select … for updateによるロック挙動
 Google Percolatorによるスナップショット

28. Google Percolatorによるスナップショット

29. Google Percolatorによるスナップショット

30. Column Family Key Value Data key, start_ts value Lock key start_ts, primary_key, ttl Write key, commit_ts start_ts [, short_value] トランザクションによる heartbeatが 途切れるとrollback処理へ TTLによるデータロック
 トランザクションがTTLを確認しノードダウン時などを検知 
 Google Percolatorによるスナップショット

31. • TiDBについて
 • TiDBのデータ保持について 
 • ローカル環境での構築 

32. VertualMachie(Linux) 
 検証環境の準備方法 
 1台のローカル内ＶＭにすべての機能をインストール可能 
 (簡単構築、２コマンドで完了)
 ローカルＶＭ環境(Linux)
 1. tiupコマンドのインストール 
 curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh 
 
 2. 永続性のあるデータでローカル環境で構築 
 tiup playground -T test 
 Monitor
 PD
 TiDB
 TiKV
 TiFlash
 ※ リッスンアドレス/ポート変換可能 
 ※ 永続データ保持も可能 
 ※ ローカル内で複数インスタンスデプロイ可能 
 ※ インターネットに接続できる環境であれば、上記2コマンドで構築完了 
 【 お客様PC 】 

33. TiDB Cloud : 無償トライアルのご案内
 https://tidbcloud.com/signup
 Serverless TierではTiDB Cloudを無償で1年間ご利用頂けます。
 ※容量制限はありますが本番と同等の機能を提供しているため、
 アプリとの接続試験などが
 容易にできます。

34. 検証環境の準備方法 
 AWS上でTiDB Cloud（フルマネージド）を無償 で利用可能
 (簡単構築、3ステップで完了)
 TiDB Cloudコンソール上の操作 
 1. Serverless Tierを選択 
 左図、上段タブで選択 
 
 2. regionの指定 
 左図、中段プルダウンリストで選択 
 
 3. Createボタン 
 左図、下段「Create」ボタン押下でデータベースサービス稼働 
 ※20GB程度の容量まで
 ※ トラフィック・フィルターによる制限のみサポート 
 【 Cluster作成画面 】 
 【 Connect画面 】 
 https://tidbcloud.com/console/clusters
35. クラウドアプリのスタートをご支援！
 TiDB Cloud 1年無料キャンペーン
 日本進出から１周年を記念し、TiDB Cloudをご利用いただいたことがないお客様を対象にTiDB Cloud1 年間相当の値引きキャンペーンを実施します。
 キャンペーン期間
 2022年5月18日～2023年3月31日　申込み分まで 
 キャンペーン内容
 最大700万円相当（TiDB Cloud典型構成で1年分相当）の値引きを提供します。 
 対象・適用条件
 下記条件をみたすお客様 ※1（最大10社※2） 
 　- TiDB Cloudを使用したことがないお客様 
 　- 事例・プロモーションにご協力いただけるお客様 
 　- 設立から1年以上経過しているお客様 
 適用方法
 フォームにご入力の上、キャンペーンにお申し込みください。審査結果およびキャンペーン の詳細について担当者より連絡いたします。 
 URL
 https://pingcap.co.jp/start-dash-202205/ 
 ※1 別途所定の審査あり
 ※2 予定数に達し次第終了する可能性があります。