Introducing PingCAP and TiDB DB性能でお悩みの方必見。 スケーラブルなRDB NewSQLはどこまでできるか。
 PingCAP株式会社 CTO 林正記（Hayashi Masaki） 


本日のセッションの位置づけ https://pingcap.co.jp/event/ 2022年4月14日(木) 14-15:30 TiDB ソフトウェアの紹介・デモ 2022年4月21日(木) 14-15 アプリケーション開発観点からのTiDB - Ruby編 2022年５月12日(木) 14-15:30 TiDB Cloudの紹介・デモ 2022年５月19日(木) 14-15 最新TiDB 6.0のポイント（仮） 2022年５月26日(木) 14-15 アプリケーション開発観点からのTiDB - Java編

製品概要


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


シャーディングという方法
 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サーバーを使用して、テーブルを再設計・分割するという茨

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のスキルセットを活かせる


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)


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 ダウンタイム発生) 〇 (標準で問題が起きないように実施) - 既存ソリューションの組み合わせではないので、運用性が優れている。 - ノードをまたいだクエリで性能劣化等が起きないように作られている。

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

分散型SQLデータベース オンライン拡張とリアルタイム分析可能 用途①：OLTP 水平拡張可能なリレーショナルデータベース ーーー オンラインでの拡張 ● シングルTiDBクラスターで400TB以上拡張 ● シングルテーブルで数兆レコード対応 用途②：HTAP リアルタイム分析 ーーー トランザクション処理と分析処理 ● トランザクションデータと連携した分析レポート ● 数兆レコードを利用した分析が可能 世界で採用されるTiDB
 - オンラインスケールアウト/イン＋負荷分散 　　⇒書き込みスケール 　　⇒読み込みスケール - レプリケーション遅延排除 - MySQL 5.6/5.7 互換 - 列志向DBの統合による分析ワークロード対応

日本のユーザー企業様でも注目の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/ 
 


特長①：スケールアウト + 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)


MySQL互換は100%ではないので注意 ①MySQL互換 　ストアドプロシージャ・トリガー・外部キー制約　等未サポート 　※互換性 ②トランザクション ・分離レベル…スナップショットアイソレーションを使用 - Repeatable Read (デフォルト。MySQL Repeatable Readと同様ファントムリードも防ぐ） - Read Committed 　※参考リンク ・モード - 悲観ロック（デフォルト） - 楽観ロック 　※参考リンク ③Auto_Increment 　- それぞれのTiDBノードに番号をキャッシュし払いだす方式のため、完全に順番とはならない

既存のツールを利用可能 下記は検証済みのものになります。その他のツール利用が必要な場合はリクエストお願いいたします。 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億行のデータが格納されてリード /ライト性能に大きな影響が発生 ● 通常のストレージでは、オンラインでのデータ容量拡張ができない ● アプリ改修なしで、移行できること (MySQL互換) ● ゲームのコアアプリケーション課 金アプリケーション 請求アプリケーション 事例 NetEase荒野行動(大容量・多アクセスによる性能劣化を解決)
 導入シナリオ 導入効果 導入理由 ● キャパシティプランニングが不要により、 DBシャーデング不要 ● 新しいノードのオンライン拡張が可能になった 急成長するゲームを支えるデータベースの選定 スタンドアローンMySQLの限界によるアプリ影響の懸念 一日当たり36億を超えるリクエスト処理、データベースへの数十ギガバイトのデータ書込による大量データ書き込み Act-Standbyで複数DBを分散運用 TiDBでシングルDBのように運用

特長②：クラウドネイティブ AWS Region GCP Region ①コミュニティ版 ②エンタープライズ ③TiDB Cloud タイプ Software Managed Service 課金単位 無償 vCPU数 インスタンス/容量/転送 プラットフォーム サーバー（EC2上含む） Kubernetes（AWS EKS含む） AWS、GCP サポート コミュニティサポート -24x7 エンタープライズサポート -Techincal training and consulting

特長②：クラウドネイティブ TiDB Cloud：よりアプリ開発に注力できるマネージドサービス


特長②：クラウドネイティブ 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 


特長②：クラウドネイティブ エコシステム
 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 データエクスポート機能 データインポート機能
 バックアップ・リカバリー機能
 診断・モニタリング


一歩進んで使う


特長③：リアルタイム分析 データハブレイヤー（OLTP + リアルタイム分析）化することにより OLTPデータや非構造化データをリアルタイム分析に活用 OLTP ->DataHub DWH App TiDBの工夫 ①スケールアウト型RDB (NewSQL) 　　- RDBへの統合によるJOIN等への対応 　　- スケールアウト性 ②列志向MPPエンジン ③エコシステム拡充（SparkSQLとの統合）

特長③：リアルタイム分析 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

① 数百億行の挿入と変更をサポート 
 ② シャーティング（分割処理）不要、開発コスト削減、リリース期間を短縮 
 ③ ワンプラットフォームで分析処理も可能、データ移行が不要 
 ④ 構成がシンプル、運用が大幅に改善 
 多種多様な情報を蓄積
 配送情報の最適化、顧客情報の分析活用 
 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


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


Demo


アーキテクチャ
 


スケールアウトアーキテクチャ
 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着想） 
 - 全てのコンポーネントがスケール可能（テーブルの分割等は不要） 


（ご参考）TiKV内の保管イメージ テーブル定義
 TiKV内のKey-Value
 https://tikv.org/blog/how-tikv-reads-writes/

データレイアウト
 [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パーティショニングとなっている 
 - 少なくとも２つ（過半数以上）にデータが入った段階で書き込み成功となる 
 - スケールアウトすると直ちにデータの移動が始まる 


※参考 : Spannerとの違い
 TiDB Spanner データ単位 32MB 数GB パーティション Range Range データ分割トリガー 容量・ホットスポット(Region) 　⇒ホットスポットを避ける仕組み 容量・ワークロード ①データ配置設計 （PKの設計推奨） - Auto_Increment 　⇒通常推奨。 Region分割・32MB等の理由で、ある程 度負荷が分散される - Auto_Random - UUID ①データ配置設計 （JOINの検討） データ単位が小さいため、複数ノードに分散さ れているので通常は設計範囲外 -インターリーブ ②スケールアウト ノード追加のみ （ノード追加後、データが 32MB単位で再配置が始まり、 負荷分散がすぐに始まる） 負荷かけ(ウォームアップ)によるSplit生成 （Splitの生成(による性能向上 )のため）

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

（参考）データ整合性を担保する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ノード) 


（参考）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を利用 


耐障害性
 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面コピー)

コンポーネントの役割 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

デモ
 TiDB単体デモ（デプロイ、GUI、スケールアウト） 
 


デモ VPC AZ1 AZ2 AZ3 Subnet 10.0.4.0/22 Subnet 10.0.8.0/22 Subnet 10.0.12.0/22 Subnet 10.0.0.0/22 PD1 (GUI/Grafana) TiDB1 TiKV1 TiUP MySQL Client PD2 TiDB2 TiKV2 PD3 TiDB3 TiKV3 ①初期デプロイ
 tiupをダウンロード tiupコマンドを使用してTiDB全 体のデプロイをしていく AZ障害に対応できるように、 TiKVにlabelを張って分散していく Zone1 Zone2 Zone3

デモ VPC AZ1 AZ2 AZ3 Subnet 10.0.4.0/22 Subnet 10.0.8.0/22 Subnet 10.0.12.0/22 Subnet 10.0.0.0/22 PD1 (GUI/Grafana) TiDB1 TiKV1 TiUP MySQL Client PD2 TiDB2 TiKV2 PD3 TiDB3 TiKV3 ②MySQL Clientからの接続 
 MySQL ClientからTiDB1に接続 (実際の環境ではLB経由で TiDB1,2,3にアクセス)

デモ VPC AZ1 AZ2 AZ3 Subnet 10.0.4.0/22 Subnet 10.0.8.0/22 Subnet 10.0.12.0/22 Subnet 10.0.0.0/22 PD1 (GUI/Grafana) TiDB1 TiKV1 TiUP MySQL Client PD2 TiDB2 TiKV2 PD3 TiDB3 TiKV3 ③管理ツールからの確認 
 Grafana/GUIからの画面確認

デモ VPC AZ1 AZ2 AZ3 Subnet 10.0.4.0/22 Subnet 10.0.8.0/22 Subnet 10.0.12.0/22 Subnet 10.0.0.0/22 PD1 (GUI/Grafana) TiDB1 TiUP MySQL Client PD2 TiDB2 PD3 TiDB3 ④スケールアウト
 tiupからスケールアウト Zone1 Zone2 Zone3 TiKV1 TiKV2 TiKV3 TiKV4 TiKV5 TiKV6

デモ VPC AZ1 AZ2 AZ3 Subnet 10.0.4.0/22 Subnet 10.0.8.0/22 Subnet 10.0.12.0/22 Subnet 10.0.0.0/22 PD1 (GUI/Grafana) TiDB1 TiUP MySQL Client PD2 TiDB2 PD3 TiDB3 ⑤AZ障害
 MySQL Clientから負荷かけ Zone1 Zone2 Zone3 TiKV1 TiKV2 TiKV3 TiKV4 TiKV5 TiKV6

エコシステム 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 データエクスポート機能 データインポート機能
 バックアップ・リカバリー機能
 診断・モニタリング


今後のセミナー予定 https://pingcap.co.jp/event/ 2022年4月12日(木) 14-15:30 TiDB ソフトウェアの紹介・デモ 2022年4月21日(木) 14-15 アプリケーション開発観点からのTiDB - Ruby編 2022年５月12日(木) 14-15:30 TiDB Cloudの紹介・デモ 2022年５月19日(木) 14-15 最新TiDB 6.0のポイント（仮） 2022年５月26日(木) 14-15 アプリケーション開発観点からのTiDB - Java編

Free Trialのご案内 TiDB Cloud Free Trialはこちら https://tidbcloud.com/signup Developer Tierでは TiDB Cloudを無償で1年間ご利用頂けます。 容量制限はありますが、 本番と同等の機能を提供しているため、 アプリとの接続試験などが容易に。 ＊現在はAWSのみ対応

お問い合わせ先 お問い合わせ先 [email protected] 製品に関する問い合わせ以外にも ハンズオンや製品デモはじめ、 勉強会などの実施も可能です。 気兼ねなくご相談、ご連絡ください。 ＊右の画像はCyberAgent様向けに実施したハンズオンの様子 https://developers.cyberagent.co.jp/blog/archives/33416/

Thank You! https://www.pingcap.com/ [email protected]