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

by PingCAP-Japan

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

製品・プロジェクト  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型  テストアプリ  来年リリース予定

Slide 4

Slide 4 text

2010 NewSQL    - リレーショナルモデル&SQL   - 増強した拡張性  - 分析クエリには不向き   2020 19XX Traditional RDBMS     - リレーショナルモデル & SQL   - ACIDトランザクション   - 拡張性に弱点  2000 KVS/NoSQL    - 簡単なデータモデル   - 高いスループットを実現   - 複雑なクエリと  ACIDトランザクションが   サポートされていないのが弱点   +α  （TiDB）    - トランザクション処理とリアルタイム分析クエリを両立   進化したSQLデータベース  NewSQL ＋ HTAP製品  TiDBの位置づけ 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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処理） 

Slide 8

Slide 8 text

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処理） 

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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アーキテクチャー 

Slide 11

Slide 11 text

- 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アーキテクチャー 

Slide 12

Slide 12 text

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”; データ量が増えた場合にバッチ処理へバッチ処理なしでリアルタイムに結果を出力が可能に個別ユーザの集計するクエリが多くなると遅くなるとクエリでは対応できない為、バッチ処理が必須 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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アーキテクチャー 

Slide 15

Slide 15 text

並列度を高め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アーキテクチャー 

Slide 16

Slide 16 text

データストアレイヤー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アーキテクチャー 

Slide 17

Slide 17 text

冗長構成  ノードが分かれているので、ＤＣを超えて配置可能   データベース単体でＤＲも実現可能   （クエリーの応答が断ではなく）   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アーキテクチャー 

Slide 18

Slide 18 text

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アーキテクチャー 

Slide 19

Slide 19 text

- データアクセスの自動負荷分散   負荷のかかっているブロックを分割して分散可能 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アーキテクチャー 

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

特定のキー/データの持ち方   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  

Slide 23

Slide 23 text

特定のキー/データの持ち方   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  

Slide 24

Slide 24 text

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:[email protected] 6: 5: 7: 6: put @ 5 5: Region 2  Joeのデータがあるノード   ① BobとJoeのデータのLockが取れるか確認   ② ロックが取れたらCOMMIT処理へ   （BobのPrimaryのLockを解除) 

Slide 25

Slide 25 text

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:[email protected] 6: 5: 7: 6: put @ 5 5: Region 2  Joeのデータがあるノード   ② BobのPrimaryのLockを解除しデータ確定に  

Slide 26

Slide 26 text

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によるスナップショット 

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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によるスナップショット 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 】  

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

検証環境の準備方法   AWS上でTiDB Cloud（フルマネージド）を無償で利用可能  (簡単構築、3ステップで完了)  TiDB Cloudコンソール上の操作   1. Serverless Tierを選択   左図、上段タブで選択     2. regionの指定   左図、中段プルダウンリストで選択     3. Createボタン   左図、下段「Create」ボタン押下でデータベースサービス稼働   ※20GB程度の容量まで  ※ トラフィック・フィルターによる制限のみサポート   【 Cluster作成画面】   【 Connect画面】   https://tidbcloud.com/console/clusters

Slide 35

Slide 35 text

クラウドアプリのスタートをご支援！  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 予定数に達し次第終了する可能性があります。 