Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TiDBが生まれた背景 そして、TiDB Serverlessへ

TiDBが生まれた背景 そして、TiDB Serverlessへ

PingCAP-Japan

July 16, 2024
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

  1. RDBMS / NewSQL ※すべての製品が以下の通りではないですが、大別したイメージとして 
 RDBMS NewSQL ‧マスターとレプリカの明確な区別 ※エンドポイント管理 ‧マスターの性能に律速される ※特にWriteはボトルネック

    ‧機動的な性能の増減が困難 ‧アプリ側視点での構成がシンプル ※マルチマスター ‧ノード追加による性能向上 ※Read/Write共にスケール ‧リーダースイッチで障害時も⾃動フェイルオーバー  ※バージョンアップ時もダウンタイムなし App Computing Nodes App Read / Write ‧‧‧ Read Only Master Read replica リーダー:読み書き担当 フォロワー:バックアップ担当 (リーダーに) Read / Write チャンクの役割分担 Read / Write
  2. 分散型SQLデータベース: スループット/可⽤性向上を⽬指す TiDBのアーキテクチャー TiKV TiFlash TiDB TiDB TiFlash TiKV TiKV

    PD TSO / Data Location Metadata column型
  row型
 PD PD クエリ増加 ->ノード追加 容量拡張 ->ノード追加 • SQL解析を⾏う *MySQLプロトコルをKVに変換 • ParserやOptimizerを担う • HTAPではTiKV(row型)かTiFlash(column型)判断 コンピューティング  TiKV • OLTP⽤途の分散Key-Value Store※Rocks DB利⽤ • パーティショニングによるデータ分散管理 • Raftや2PCにより整合性担保  TiFlash *optional • HTAP利⽤時の追加コンポーネント • OLAP⽤途のカラム型ストア ストレージ     • データ配置場所の管理(Region管理) • 分散トランザクションで利⽤するTSOを発⾏ 司令塔 PD TiDB TiFlash TiKV
  3. ⾃動シャーディング‧負荷分散 Region毎の冗⻑化により耐障害性、負荷分散を実現 Region 3* Follower
 バックアップ 
 Region 1* Leader

    
 読み書き可能 
 Region 2* Follower
 バックアップ 
 Region 3* Follower
 バックアップ 
 Region 1* Follower
 バックアップ 
 Region 2* Leader 
 読み書き可能 
 Region 3* Leader 
 読み書き可能 
 Region 1* Follower
 バックアップ 
 Region 2* Follower
 バックアップ 
 例:ユーザーテーブル データサイズは、デフォルト96MB ※⼩さいサイズにする事で柔軟性を確保 96MB 96MB 96MB TiKV TiKV TiKV TiDB TiDB 分散配置されたLeaderが、読み書きを処理
  4. TiKV TiKVのアーキテクチャー Key-Value型データベース • CNCF Graduated Project • 書き込み性能の⾼いLSMツリー(追記型) •

    データ永続化:SSTファイルを圧縮して管理 (1,Tom) 
 (2,Jack) 
 (2,Jack) 
 ①
 ②
 Sorted String Table
 (1,Tom) 
 (2,Jack) 
 (1,Tom) 
 ③
 (1,Tom) 
 (2,Jack) 
 (1,Tom) 
 (2,Jack) 
 ④
 Background処理 Raft Engine Raft Engine Raft Engine
  5. はじまりはここから • 全ての始まりは 2015年ごろ • 3人のFounder(Max, Ed, Dylan)が作り始める • 元々、Ed,

    Maxは分散型RedisであるcodisというOSSを開発 • キャッシュレイヤーのスケーラビリティを解決後、 リレーショナル DBのスケーラビリティへ挑戦! https://github.com/CodisLabs/codis
  6. ユーザによる初期の使われ⽅ [目指していたもの ] ・MySQLのシャーディングソリューションを 置き換えるスケーラブルな OLTP [実際には・・・ ] ・人々は、ミッションクリティカルな DBを

    置き換えることへは慎重 ・TiDBをバックアップやレプリカとして利用 ・MySQLプロトコルをサポートし、 強力なSQLエンジンを持っていたので、 OLAP用途で利用され始める https://www.docswell.com/s/bohnen/K8G4JP-2024-07-09-120442#p6 https://qiita.com/bohnen/items/f28d5cb7acb9efd83712
  7. TiDBの利⽤パターン パターン
 1 Instance TiUP TiDBのセットアップから運⽤まで ※ローカルでも使える パターン
 2 Kubernetes

    パターン
 3 Cloud TiDB Operator K8sでのセットアップ‧運⽤ TiDB Cloud フルマネージドDBaaS ServerlessとDedicatedがある
  8. Serverless マルチテナント型 Dedicated 専有型 • マルチAZ / 各コンポーネントスケール(APIあり) • MySQLからの移⾏ツールもフルで使える

    ※DataMigration / ChangeFeed • OSSライクに柔軟なチューニング可能 • シングルAZ / Autoスケール ※マルチAZ版も予定 • BranchingやEdge Function⽤のDriver⽤意 • Vector Search※Public Beta機能搭載       のラインナップ
  9. TiDB Serverless 数十秒で起動し、自動でスケールする 従量課金のサーバレスデータベース サーバの管理不要 拡張が自動 ⾃動拡張 Pay as you

    go 従量課⾦ 自動フェイルオー バーと自己回復 ゼロ ダウンタイム + HTAP機能も使用 可能 リアルタイム分析 パフォーマンス改善 日本語による SQL生成支援 AI アシスタント MySQL driverや ORMツールからも 利⽤可能 MySQL互換 https://aws.amazon.com/jp/blogs/storage/how-pingcap-transformed-ti db-into-a-serverless-dbaas-using-amazon-s3-and-amazon-ebs/
  10. Shared Gateway Isolated SQL Layer Shared Storage Layer Gateway Gateway

    Gateway Virtual Cluster - Tenant 1 TiDB MPP Row Engine Row Engine Row Engine Virtual Cluster - Tenant 2 Resource Pool TiDB TiDB MPP Worker Columnar Engine Columnar Engine Columnar Engine TiDB MPP Virtual Cluster - Tenant n TiDB MPP MPP MPP TiDB ・・・ EBS EBS EBS EBS EBS EBS Shared Storage Pool Amazon S3 Shared Service Compacti on Checksu m Analyze Coproces sor Import Export DDL PD TSO Scheduling API Server Architecture
  11. POINT 1 NewSQL POINT 2 HTAP POINT 3 MySQL互換 POINT

    4 OSS POINT 5 Serverless Write含むスループットと 可⽤性の向上(耐障害性/VerUpもオンライン) ハイブリッドワークロード対応 (OLTP + OLAP) MySQL エコシステムも利⽤ 既存ナレッジを最⼤限活かす フルマネージド / Serverless $0から利⽤可能