【NewSQL】シャーディングはもうやらない。フルマネージドなスケーラブルRDBを使ってみよう

スケーラブルなRDB環境が実現できる夢のようなNewSQLの分散データベースTiDB。
世界での普及が進み、更にDBaaSマネージドサービスとしての普及が加速しています。

このスライドでは、マネージドサービスであるTiDB Cloudのメリット・使われ方・アーキテクチャなど、事例やデモを交えて紹介します。ぜひTiDB Cloudをお試しください。

TiDB Cloudクイックスタート：https://docs.pingcap.com/ja/tidbcloud/tidb-cloud-quickstart
アーカイブ動画：https://youtu.be/Tf9kNT4ZApI

Transcript

1. Introduction of PingCAP and TiDB シャーディングはもうやらない。 フルマネージドなスケーラブルRDBを使ってみよう
 PingCAP株式会社 CTO 林正記（Hayashi Masaki） 

2. 本日のセッションの位置づけ https://pingcap.co.jp/event/ 2022年4月14日(木) 14:00-15:30 TiDB ソフトウェアの紹介・デモ 2022年4月21日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - Ruby編 2022年5月12日(木) 14:00-15:30 TiDB Cloudの紹介・デモ 2022年5月19日(木) 14:00-15:00 最新TiDB 6.0のポイント 2022年5月26日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - Java編 2022年6月9日(木) 14:00-15:30 TiDB ソフトウェアの紹介・デモ 2022年6月16日(木) 14:00-15:00 TiDB Cloudのリリースノート解説 2022年6月23日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - PHP編
3. 製品概要

4. データベースの現実的な課題 - RDBの性能
 RDB (ex. MySQL) NoSQL (ex. Cassandra) CAPの考え方 CA AP クエリ SQL API, SQL(CQL) 　- トランザクション 〇 X 　- JOIN 〇 X Readスケーラビリティ 〇 リードレプリカ テーブル再設計 ◎ 分散アーキテクチャ Writeスケーラビリティ △ Writerは単一ボトルネック （要シャーディング） ◎ 分散アーキテクチャ - NoSQLでは難しい領域もある。
 - 慣れてるのでSQLでお願いします。性能もよろしく。
 - マイクロサービスっぽくしたけど複数サービスで同じテーブル使いたい

5. シャーディングという方法
 Sharding Sharding Tool (ex. Vitess, Galera,…) 互換性 ◎ 〇 (分離レベル・クエリサポート等) スケールアウト(Write) +データリバランス x (テーブル再設計+アプリ改修) △ (製品によって、テーブル再設計+アプ リ改修やWriteScaleしない等) スケールイン x (テーブル再設計+アプリ改修) △ (製品によって、テーブル再設計+アプ リ改修) （Shardをまたいだ） 分散トランザクション /JOIN x (アプリ側で実装 or NG) △ (製品によってアプリ側で実装や性能 劣化問題で非推奨) メタデータ(ユーザー等)管理 x (各DBで管理) x (各DBで管理) マネージドサービス 〇 △ (製品によって日本Regionがない) FW Upgrade △ (複雑 or ダウンタイム発生) △ (複雑 or ダウンタイム発生) - スケーラビリティ獲得の手段 - 複数のDBサーバーを使用して、テーブルを再設計・分割するという茨
6. NewSQLという選択肢
 RDB (ex. MySQL) NoSQL (ex. Cassandra) New SQL (ex. TiDB) CAPの考え方 CA AP CP+HA クエリ SQL API, SQL(CQL) SQL 　- トランザクション 〇 X 〇 　- JOIN 〇 X 〇 Readスケーラビリティ 〇 リードレプリカ テーブル再設計 ◎ 分散アーキテクチャ ◎ 分散アーキテクチャ テーブル再設計不要 Writeスケーラビリティ △ Writerは単一ボトルネック （要シャーディング） ◎ 分散アーキテクチャ ◎ 分散アーキテクチャ (大きい1テーブル対応可) - RDB + スケーラビリティの直接的回答
 - 有名プロトコルを互換しているので、RDBのスキルセットを活かせる

7. NewSQLは完全分散型
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB Cluster
 TiKV Cluster
 負荷分散・領域管理 
 3ノードのみ必要 
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol データストアレイヤー 
 アプリケーション
 (MySQLClient利用可能)
 - １つのシステムっぽく見える。裏で勝手にロードバランスしてくれる 
 - 各コンポーネントは、ノードを追加することでリニアにスケールアウトが可能 
 - 完全分散型＝リードレプリカを通じたレプリケーション遅延もなくなる 
 SQL解析レイヤー
 (Parser, Optimizer)

8. NewSQLは運用性が優れている
 Sharding Sharding Tool (ex. Vitess, Galera,…) New SQL (ex. TiDB) 互換性 ◎ 〇 (分離レベル・クエリサポート等) 〇 スケールアウト(Write) +データリバランス x (テーブル再設計+アプリ改修) △ (製品によって、テーブル再設計+アプ リ改修やWriteScaleしない等) 〇 (オンラインで自動リバランス) スケールイン x (テーブル再設計+アプリ改修) △ (製品によって、テーブル再設計+アプ リ改修) 〇 (オンラインで自動リバランス) （Shardをまたいだ） 分散トランザクション /JOIN x (アプリ側で実装 or NG) △ (製品によってアプリ側で実装や性能 劣化問題で非推奨) 〇 (標準機能) メタデータ(ユーザー等)管理 x (各DBで管理) x (各DBで管理) 〇 (F1に基づく統合管理) マネージドサービス 〇 △ (製品によって日本Regionがない) 〇 FW Upgrade △ (複雑 or ダウンタイム発生) △ (複雑 or ダウンタイム発生) 〇 (標準で問題が起きないように実施) - 既存ソリューションの組み合わせではないので、運用性が優れている。 - ノードをまたいだクエリで性能劣化等が起きないように作られている。
9. NewSQL + MySQL互換？
 Feature Amazon Aurora Google Cloud Spanner YugaByteDB CockroachDB TiDB Elastic scalability (Both read and write) Automated failover and high availability Distributed ACID transactions SQL compatibility and protocol MySQL and PostgreSQL Proprietary （+PostgreSQL） PostgreSQL PostgreSQL MySQL Open Source License Apache 2.0 BSL and CCL Apache 2.0 HTAP
10. 分散型SQLデータベース オンライン拡張とリアルタイム分析可能 用途①：OLTP 水平拡張可能なリレーショナルデータベース ーーー オンラインでの拡張 • シングルTiDBクラスターで400TB以上拡張 • シングルテーブルで数兆レコード対応 用途②：HTAP リアルタイム分析 ーーー トランザクション処理と分析処理 • トランザクションデータと連携した分析レポート • 数兆レコードを利用した分析が可能 世界で採用されるTiDB
 - オンラインスケールアウト/イン＋負荷分散 　　⇒書き込みスケール 　　⇒読み込みスケール - レプリケーション遅延排除 - MySQL 5.6/5.7 互換 - 列指向DBの統合による分析ワークロード対応
11. 日本のユーザー企業様でも注目のTiDB
 - DMM.com様 ->検証レポート 
 　https://inside.dmm.com/entry/2021/12/12/tidb-on-aws-eks-poc-report - DeNA様 ->検証+次世代構想の中でTiDBをスコープに 
 　https://engineer.dena.com/posts/2021.11/optimize-db-operation-for-many-shards/ - PayPay様 ->TiDBへのデータ移行ストーリー 
 　https://www.youtube.com/watch?v=3GQAAbrQxKU 
 - さくらインターネット様 - 自社サービスとしてTiDBを採用 
 　https://knowledge.sakura.ad.jp/29695/ - db tech showcase (PayPay様・さくらインターネット様・ DMM.com様・CyberAgent様) 　https://www.youtube.com/watch?v=3GQAAbrQxKU&list=PL9kgs341MpSTq0Q2TDp6hfenWf9EafpT7 - Mercari, Merpay様 ->次世代システムの検討について 　https://www.youtube.com/watch?v=VJdzTbfOrqM&t=4281s
 - CyberAgent様 ->ブログ：クラウドネイティブな DB を使ってみよう！TiDBの社内ハンズオンを開催しました 
 　https://developers.cyberagent.co.jp/blog/archives/33416/ 
 

12. 特長①：スケールアウト + MySQL互換
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB Cluster
 TiKV Cluster
 負荷分散・領域管理 
 3ノードのみ必要 
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol データストアレイヤー 
 アプリケーション
 (MySQLClient利用可能)
 - TiDB : MySQLプロトコルを理解
 - TiKV : 3,5面コピー、AZ障害にも対応可能 
 SQL解析レイヤー
 (Parser, Optimizer)

13. MySQL互換は100%ではないので注意 ①MySQL互換 　ストアドプロシージャ・トリガー・外部キー制約　等未サポート 　※互換性 <https://docs.pingcap.com/tidb/stable/mysql-compatibility> ②トランザクション ・分離レベル…スナップショットアイソレーションを使用 - Repeatable Read (デフォルト。MySQL Repeatable Readと同様ファントムリードも防ぐ） - Read Committed 　※参考リンク <https://docs.pingcap.com/tidb/stable/transaction-isolation-levels> ・モード - 悲観ロック（デフォルト） - 楽観ロック 　※参考リンク <https://docs.pingcap.com/tidb/stable/pessimistic-transaction> ③Auto_Increment 　- それぞれのTiDBノードに番号をキャッシュし払いだす方式のため、完全に順番とはならない
14. 既存のツールを利用可能 下記は検証済みのものになります。その他のツール利用が必要な場合はリクエストお願いいたします。 https://docs.pingcap.com/appdev/dev/app-dev-overview Connector 　- [Go] MySQL connector 　- [Java] JDBC/MySQL connector 　- [Python] python/mysql-connector 　- [Ruby] Mysql2 　- [PHP] PDO_MYSQL ORM frameworks 　- [Go] GORM 　- [Java] Hibernate 　- [Python] Django / SQLAlchemy 　- [Ruby] ActiveRecord 　- [PHP] Laravel
15. • 書き込みパフォーマンスの低下、および、容易な容量拡張ができない • 15億行のデータが格納されてリード /ライト性能に大きな影響が発生 • 通常のストレージでは、オンラインでのデータ容量拡張ができない • アプリ改修なしで、移行できること (MySQL互換) • ゲームのコアアプリケーション課 金アプリケーション 請求アプリケーション 事例 NetEase荒野行動(大容量・多アクセスによる性能劣化を解決)
 導入シナリオ 導入効果 導入理由 • キャパシティプランニングが不要により、 DBシャーデング不要 • 新しいノードのオンライン拡張が可能になった 急成長するゲームを支えるデータベースの選定 スタンドアローンMySQLの限界によるアプリ影響の懸念 一日当たり36億を超えるリクエスト処理、データベースへの数十ギガバイトのデータ書込による大量データ書き込み Act-Standbyで複数DBを分散運用 TiDBでシングルDBのように運用
16. 特長②：クラウドネイティブ AWS Region GCP Region ①コミュニティ版 ②エンタープライズ ③TiDB Cloud タイプ Software Managed Service 課金単位 無償 vCPU数 インスタンス/容量/転送 プラットフォーム サーバー（EC2上含む） Kubernetes（AWS EKS含む） AWS、GCP サポート コミュニティサポート -24x7 エンタープライズサポート -Techincal training and consulting
17. 特長②：クラウドネイティブ TiDB Cloud：よりアプリ開発に注力できるマネージドサービス

18. 特長②：クラウドネイティブ Kubernetes対応
 https://aws.amazon.com/jp/blogs/startups/achieve-better-price-to-performance-for-tidb-graviton2-processors/ Achieve Better Price to Performance for TiDB on Amazon EKS with Graviton2 Processors https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-on-aws-eks 

19. 特長②：クラウドネイティブ エコシステム
 TiDB TiDB TiDB Application via MySQL Protocol TiKV TiKV TiFlash TiKV TiKV ... DistSQL API 
 KV API
 ... Worker Worker Worker Spark Driver ... Spark SQL Spark Cluster
 DistSQL API 
 PD PD PD PD Cluster Pump Pump Pump Drainer ... TiDB Binlog/CDC DM Worker DM Worker DM Master Upstream Database Downstream Database Lightning KV Importer KV Dumper TiDB Vision TiDB Insight TiDB Operator Chaos Mesh TiFlash データエクスポート機能 データインポート機能
 バックアップ・リカバリー機能
 診断・モニタリング

20. 一歩進んで使う

21. 特長③：リアルタイム分析 データハブレイヤー（OLTP + リアルタイム分析）化することにより OLTPデータや非構造化データをリアルタイム分析に活用 OLTP ->DataHub DWH App TiDBの工夫 ①スケールアウト型RDB (NewSQL) 　　- RDBへの統合によるJOIN等への対応 　　- スケールアウト性 ②列指向MPPエンジン ③エコシステム拡充（SparkSQLとの統合）
22. 特長③：リアルタイム分析 RowData ロー型配置データ Salesテーブル RowData RowData RowData カラム型配置データ Salesテーブル TiDB (Optimizer) SELECT AVG(s.price) FROM prod p, sales s WHERE p.pid = s.pid AND p.batch_id = ‘B1328’; TableScan(price,pid) TP or AP処理をTiDBで自動判別 リアルタイムで同期 price pid B1328 B1328 B1328 TiKV TiFlash 分析処理を高速化する列指向型ストアTiFlash
23. ① 数百億行の挿入と変更をサポート 
 ② シャーティング（分割処理）不要、開発コスト削減、リリース期間を短縮 
 ③ ワンプラットフォームで分析処理も可能、データ移行が不要 
 ④ 構成がシンプル、運用が大幅に改善 
 多種多様な情報を蓄積
 配送情報の最適化、顧客情報の分析活用 
 HTAPによるリアルタイム分析を実現し、IT効率を3倍以上向上
 OracleExadata 
 伝票情報
 支払い
 受領
 ...
 TiDB
 （40TiB利用中 400TiBまで可能 )
 • Oracle Exadataのデータベース容量上限により
 データの保存期間が要望を満たせない。
 • トランザクションのピーク時（12万QPS）の性能が頭打ち
 • スタンドアローンDBがボトルネックとなり障害リスクを抱えていた
 • DBシャーディングによりリアルタイム分析の妨げになっていた
 What Problem　- 課題 -
 Before
 After
 Why TiDB?　- 選定理由 - 車両情報
 ストアドプロシージャー
 によるアナリティクスデータ処 理
 AP処理をストアドで処理 
 Application
 伝票情報
 支払い
 受領
 ...
 車両情報
 書込ネックで 12万QPSで頭打ちに
 書込ネックが解消
 ※ ピーク36万QPSを現状サポート 
 HTAPでそのままAP処理可能 
 流通事例: ZTO Express

24. まとめ 多くのお客様との技術交流を通して５つのシーンでTiDBが求められました。 
 ①大量の書き込みスケールが必要！ データ量が増える事の性能劣化が悩み 
 　オンラインでのスケールアウトが可能・事前の詳細なサイジングは不要 
 ②シャーディング運用から脱却したい！ 
 　分散型アーキテクチャにより煩雑なシャーディング運用から脱却できる。 
 　シャーディングされたDBもそのまま一つのTiDBクラスターへ移行が可能。 
 ⑤リアルタイム分析をしたい！ 
 　今までリアルタイム分析の妨げになっていたETL処理が不要 
 　分析用コンポーネントによりトランザクションデータをワンシステムでリアルタイム分析が可能 
 ④AP(分析)ライクな複雑なクエリの性能を向上させてたい！ 
 　③の分析用コンポーネントを応用し特定のクエリだけ処理させて性能向上をさせることも可能 
 ③開発チームはMySQLユーザーが多いからMySQL互換のある分散型DBを使いたい！ 
 　基本的には、アプリ改修なしで使用することが可能　 
 　＊stored procedure、Trigger、外部キー制約は考慮ポイント 

25. Demo

26. アーキテクチャ
 

27. スケールアウトアーキテクチャ
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB Cluster
 TiKV Cluster
 負荷分散・領域管理 
 3ノードのみ必要 
 SQL解析レイヤー
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol データストアレイヤー 
 アプリケーション
 (MySQLClient利用可能)
 - SQL解析レイヤーとデータストアレイヤーを分割（Google Spanner着想） 
 - 全てのコンポーネントがスケール可能（テーブルの分割等は不要） 

28. （ご参考）TiKV内の保管イメージ テーブル定義
 TiKV内のKey-Value
 https://tikv.org/blog/how-tikv-reads-writes/
29. データレイアウト
 [A, C) [C, H) [H, X) Key Space Region 3 Region 2 Region 3 Region 1 Region 2 Region 3 Region 1 Region 2 Region 1 TiKV TiKV TiKV TiKV - 全てのノードにデータが均等に3つにコピーされて分散されている。 
 - Region(32MB)という単位で保存されており、rangeパーティショニングとなっている 
 - 少なくとも２つ(過半数以上)にデータが入った段階で書き込み成功となる 
 - スケールアウトすると直ちにデータの移動が始まる 

30. ※参考 : Spannerとの違い
 TiDB Spanner データ単位 32MB 数GB パーティション Range Range データ分割トリガー 容量・ホットスポット(Region) 　⇒ホットスポットを避ける仕組み 容量・ワークロード ①データ配置設計 （PKの設計推奨） - Auto_Increment 　⇒通常推奨。 Region分割・32MB等の理由で、ある程 度負荷が分散される - Auto_Random - UUID ①データ配置設計 （JOINの検討） データ単位が小さいため、複数ノードに分散さ れているので通常は設計範囲外 -インターリーブ ②スケールアウト ノード追加のみ （ノード追加後、データが 32MB単位で再配置が始まり、 負荷分散がすぐに始まる） 負荷かけ(ウォームアップ)によるSplit生成 （Splitの生成(による性能向上 )のため）
31. IO
 [A, C) [C, H) [H, X) Key Space Region 3 (Follower) Region 2 (Leader) Region 3 (Follower) Region 1 (Leader) Region 2 (Follower) Region 3 (Leader) Region 1 (Follower) Region 2 (Follower) Region 1 (Follower) TiKV TiKV TiKV TiKV - Regionの中の1つがLeaderとしてIOを行う 
 - Leaderが障害を起こすと、FollowerがLeaderを引き継ぐ 
 
 TiDB TiDB
32. （参考）データ整合性を担保するRaft
 a = 1
 b = 2
 Log
 Raft Module TiDB
 TiKV Node 1
 Region 1
 a = 1
 b = 2
 Store 1(Leader) a = 1
 b = 2
 Log
 Raft Module TiKV Node 2
 Region 1
 a = 1
 b = 2
 Store 1(candidate) 
 a = 1
 b = 2
 Log
 Raft Module TiKV Node 3
 Region 1
 a = 1
 b = 2
 リーダーとなるRegionにのみアクセス 
 リーダーから各Regionにデータをレプリケート 
 Store 1(follower) Region : データチャンクの単位 
 - 過半数を得られたものを正とする
 　- 書き込み成功：2ノード入った段階 
 　- ノード障害時のリーダー選出：２ノードの投票が得られたノード 
 - データの一意性はこれによって保たれる（Ex. Split Brain時）
 　- 1ノードしかデータが入っていない時：アプリ…古いデータが正しい(未ACK)。 TiDB…古いデータが正しい(1ノード) 
 　- 2ノードにデータが入っている時：アプリ…新しいデータが正しい(ACK済)。 TiDB…新しいデータが正しい(2ノード) 

33. （参考）2PCによるトランザクション管理
 分散トランザクション
 [A, C) [C, H) [H, X) Key Space Region 3 Region 2 Region 3 Region 1 Region 2 Region 3 Region 1 Region 2 Region 1 TiKV TiKV TiKV TiKV TiDB
 - 複数RegionへのトランザクションはParcolator技術由来の2PCを利用 

34. 耐障害性
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB Cluster
 TiKV Cluster
 負荷分散・領域管理 
 3ノードのみ必要 
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol Application via MySQL Protocol データストアレイヤー 
 アプリケーション
 (MySQLClient利用可能)
 - SQL解析レイヤーとデータストアレイヤーを分割（Google Spanner着想） 
 - 全てのコンポーネントがスケール可能（テーブルの分割等は不要） 
 SQL解析レイヤー
 (Parser, Optimizer)
 TiDB ・障害許容台数 　　無制限（0台になったらIOが行えなくなる） TiKV ・整合性…Raft, 2PCで担保 ・障害許容台数(Raftでリーダー選出ができる台数 ) 　　1台(3面コピー) 　　2台(5面コピー) PD ・障害許容台数 (Raftでリーダー選出ができる台数 ) 　　1台(3面コピー) 　　2台(5面コピー)
35. コンポーネントの役割 TiDB TiDB TiDB Cluster
 TiKV Cluster
 TiDB
 SQL解析レイヤ
 (Stateless)
 Placement Driver Cluster 
 TiDB TiKV TSO / 
 Data Location
 PD TiKV
 データレイヤ
 Metadata
 kvdata
 - MySQLプロトコルをKV形式に変更 - Optimization - TiKV(row型)かTiFlash(cloum型)が良いか判別、 joinでは、hash joinや、sort merge joinを使うなどの判断 - 分散Key-Value StoreとしてRocksDBにデータを保存。ログ用・データ保 存用の２つのインスタンスを保持。 - 32MBを1つのRegionとする、レンジによるパーティショニングによる分 散方式。 - 3面コピーによるデータ冗長性。障害時のデータの一意性などは Raftモ ジュールによって実現。 Region管理
 - Region管理（どのRegionがどのKVノードに 保存されているか） - 分散トランザクションなどで使用する TSOを発 行 Application via MySQL Protocol
36. TiDB Cloudデモ

37. Webポータルで管理するフルマネージドデータベースとして提供
 https://tidbcloud.com/console/clusters 
 ・ノード追加
 ・バックアップスケジュール作成
 ・リストア
 ・クラスター管理
 ・クエリログ確認
 ・各リソース状況確認
 　　　　　　　　etc
 管理全般（Webコンソール） 
 監視（Webコンソール）　 　
 障害発生時（弊社からご連絡） 
 TiDB Cloud運用 全体イメージ
 お客様 ・スケール
 ・バックアップ
 ・リストア
 ・ソフトウェアメンテナンス
 ・アップグレード
 ・負荷状況確認
 ・SQLメンテナンス
 ・技術問い合わせフロー
 ・アラート対応フロー
 webコンソールから各オペレーション可能 

38. Webポータルからクラスター作成
 管理 - クラスター作成
 ・ページ上の「Create Cluster」からクラスターを作成 
 　⇒クラスター名、Cloud、Region、TiDB・TiKV台数・容量などを選択 

39. (ご参考)TiDB Cloudで作られる構成
 MultiAZ構成とS3へのバックアップで冗長性を向上
 
 東京リージョン配置のTiDBクラウドは、MultiAZでコンポーネントを配置し単一のDC障害に耐えうる設計 
 また、バックアップデータは、S3への保存を行いクラッシュ・リカバリーに対応 

40. MySQLクライアントからの接続
 管理 - MySQLクライアントからの接続
 ・Cluster選択後、「Connect」 
 　⇒Public IP経由、VPC Peering等を選択可能 

41. クラスターの「Overview」→「QPS」、「Latency」、「Connections」、「TiKV Storage Size」、 
 「CPU」、「I/0」の状況が視覚的に表示され、パフォーマンスを容易に確認できます。 
 時間の選択が可能 
 監視 - 負荷状況確認
 各種リソース状況を見ることが可能、ノード追加の判断基準に

42. ・クラスターの「Diagnosis」→「Statement」からSQLのパフォーマンスや実行計画が画面上に 
 　表示され、SQLのチューニングを行うための項目を容易に確認できます。 
 
 監視 - クエリアナライザー
 クエリー状況を過去1ヵ月間で詳細まで確認が可能

43. Webポータルからオンラインでスケールアウト・インが可能
 ・作成したクラスターのページ上の「Settings」→「Scale」と移動し 
 　Webコンソール上から構成変更が可能 
 
 ・スケールアウト・インしたいノード数に変更した後、 
 　「Confirm」を押下するだけで構成変更が開始 
 ※スケールアウト・イン実行中もクライアントから接続し、クエリを実行可能
 ※データの再配置はバックグラウンドで実行されます
 
 スケールアウト 
 所要時間
 備考
 TiDB
 1ノード
 約5分
 1ノード追加あたり 
 2〜3万QPS　拡張 
 
 TIKV
 ３ノード
 約8分
 
 ▪ノード追加の時間と費用（目安） 管理 - スケール

44. クラウドプラットフォームに依らず利用できるエコシステム
 TiDB TiDB TiDB Application via MySQL Protocol TiKV TiKV TiFlash TiKV TiKV ... DistSQL API 
 KV API
 ... Worker Worker Worker Spark Driver ... Spark SQL Spark Cluster
 DistSQL API 
 PD PD PD PD Cluster Pump Pump Pump Drainer ... TiDB Binlog/CDC DM Worker DM Worker DM Master Upstream Database Downstream Database dumpling Lightning KV Importer KV Dumper TiDB Vision TiDB Insight TiDB Operator Chaos Mesh TiFlash データエクスポート機能 データインポート機能
 バックアップ・リカバリー機能
 診断・モニタリング
 （参考）TiDBツール全体像

45. 作成したクラスターのページ上の
 「Backup」→「Auto Settings」と移動し
 「Backup Time」と「保存可能なバックアップ上限数」を
 設定することで自動でバックアップの取得も可能
 管理 - 自動バックアップ
 保持数を決めたスケジュールバックアップ方法

46. 作成したクラスターのページ上の
 「Backup」→「Manual」と移動しバックアップファイル名を
 設定することで手動でバックアップを作成可能
 管理 - 手動バックアップ
 保持期限なしで、任意のタイミングで取得可能なバックアップ方法

47. 作成したクラスターのページ上の
 「Backup」からリストアしたいバックアップファイルを選び
 「Action」の「Restore」をクリックして
 「Cluster Name」と「Root Password」を設定するだけで、
 新規クラスターにリストア可能
 管理 - リストア
 クラスターを再作成してのリストアを環境の提供

48. FAQ
 - Version up時の対応
 - モニタリングの外部連携

49. 終わりに

50. 今後のセミナー予定 https://pingcap.co.jp/event/ 2022年4月14日(木) 14:00-15:30 TiDB ソフトウェアの紹介・デモ 2022年4月21日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - Ruby編 2022年5月12日(木) 14:00-15:30 TiDB Cloudの紹介・デモ 2022年5月19日(木) 14:00-15:00 最新TiDB 6.0のポイント 2022年5月26日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - Java編 2022年6月9日(木) 14:00-15:30 TiDB ソフトウェアの紹介・デモ 2022年6月16日(木) 14:00-15:00 TiDB Cloudのリリースノート解説 2022年6月23日(木) 14:00-15:00 アプリケーション開発観点からのTiDB - PHP編
51. Free Trialのご案内 TiDB Cloud Free Trialはこちら https://tidbcloud.com/signup Developer Tierでは TiDB Cloudを無償で1年間ご利用頂けます。 容量制限はありますが、 本番と同等の機能を提供しているため、 アプリとの接続試験などが容易に。 ＊現在はAWSのみ対応
52. お問い合わせ先 お問い合わせ先 pingcapjp@pingcap.com 製品に関する問い合わせ以外にも ハンズオンや製品デモはじめ、 勉強会などの実施も可能です。 気兼ねなくご相談、ご連絡ください。 ＊右の画像はCyberAgent様向けに実施したハンズオンの様子 https://developers.cyberagent.co.jp/blog/archives/33416/
53. Thank You! https://www.pingcap.com/ info@pingcap.com