無限にスケールできるRDB・TiDBの効果～移行までを考察する - PingCAPセッション

RDBのスケールの課題を直接的に解決するNewSQLデータベースの普及が進んでいます。
現実的に移行していくにはどのようなツールを使っていけるのか、NewSQLのメリットを振り返りながら考察していきます。

NewSQLの美味しさを理解する
NewSQLと呼ばれるスケーラブルなRDBが話題になっています。本スライドではTiDBを例にとってNewSQLのメリットや事例を紹介します。また、実際のシステム移行のためにどのようなツールがあるのかも含め確認していきます。

アーカイブ動画：https://youtu.be/iFNYr426xZA

Transcript

1. Introducing TiDB NewSQLの美味しさを理解する
 PingCAP株式会社 Japan CTO 林正記（Hayashi Masaki） 

2. PingCAPの自己紹介
 - NewSQL製品TiDBの開発主体
 - 2015年設立、シリーズDで280億円の資金調達を成功
 - WWでビジネス展開。2021年日本支社設立。
 - ハイライト
 TiDBはグローバルで1600社以上で採用

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

4. シャーディングという方法
 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サーバーを使用して、テーブルを再設計・分割するという茨
5. 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のスキルセットを活かせる

6. 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)

7. 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 ダウンタイム発生) 〇 (標準で問題が起きないように実施) - 既存ソリューションの組み合わせではないので、運用性が優れている。 - ノードをまたいだクエリで性能劣化等が起きないように作られている。
8. 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
9. 分散型SQLデータベース オンライン拡張とリアルタイム分析可能 用途①：OLTP 水平拡張可能なリレーショナルデータベース ーーー オンラインでの拡張 • シングルTiDBクラスターで400TB以上拡張 • シングルテーブルで数兆レコード対応 用途②：HTAP リアルタイム分析 ーーー トランザクション処理と分析処理 • トランザクションデータと連携した分析レポート • 数兆レコードを利用した分析が可能 世界で採用されるTiDB
 - オンラインスケールアウト/イン＋負荷分散 　　⇒書き込みスケール 　　⇒読み込みスケール - レプリケーション遅延排除 - MySQL 5.6/5.7 互換 - 列志向DBの統合による分析ワークロード対応
10. 日本のユーザー企業様でも注目の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/ 
 

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

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

13. （ご参考）TiKV内の保管イメージ テーブル定義
 TiKV内のKey-Value
 https://tikv.org/blog/how-tikv-reads-writes/
14. • 書き込みパフォーマンスの低下、および、容易な容量拡張ができない • 15億行のデータが格納されてリード /ライト性能に大きな影響が発生 • 通常のストレージでは、オンラインでのデータ容量拡張ができない • アプリ改修なしで、移行できること (MySQL互換) • ゲームのコアアプリケーション課 金アプリケーション 請求アプリケーション 事例 NetEase荒野行動(大容量・多アクセスによる性能劣化を解決)
 導入シナリオ 導入効果 導入理由 • キャパシティプランニングが不要により、 DBシャーデング不要 • 新しいノードのオンライン拡張が可能になった 急成長するゲームを支えるデータベースの選定 スタンドアローンMySQLの限界によるアプリ影響の懸念 一日当たり36億を超えるリクエスト処理、データベースへの数十ギガバイトのデータ書込による大量データ書き込み Act-Standbyで複数DBを分散運用 TiDBでシングルDBのように運用
15. 特長②：分析クエリ高速化、リアルタイム分析 データハブレイヤー（OLTP + リアルタイム分析）化することにより OLTPデータや非構造化データをリアルタイム分析に活用 OLTP ->DataHub DWH App TiDBの工夫 ①スケールアウト型RDB (NewSQL) 　　- RDBへの統合によるJOIN等への対応 　　- スケールアウト性 ②列志向MPPエンジン ③エコシステム拡充（SparkSQLとの統合）
16. 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 特長②：分析クエリ高速化、リアルタイム分析
17. 事例・活発度が分かる分析サービス OSS insight
 46億を超えるGitHub上のイベント分析するデータベースとして TiDB (TiFlash)を活用 ①各イベント発生の推移 ①GitHubイベント データを1分おきに同期 +TiFlash https://ossinsight.io/ ②Pull requests地域の表示 ②分析クエリを TiFlash(カラムストア ) で高速処理 ③ジャンル内での比較（人気言語等） etc…
18. ① 数百億行の挿入と変更をサポート 
 ② シャーティング（分割処理）不要、開発コスト削減、リリース期間を短縮 
 ③ ワンプラットフォームで分析処理も可能、データ移行が不要 
 ④ 構成がシンプル、運用が大幅に改善 
 多種多様な情報を蓄積
 配送情報の最適化、顧客情報の分析活用 
 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

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

21. 使用感

22. 現実的な移行に向けて

23. 既存のMySQLツールを利用可能 下記は検証済みのものになります。その他のツール利用が必要な場合はリクエストお願いいたします。 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
24. 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ノードに番号をキャッシュし払いだす方式のため、完全に順番とはならない
25. 特長③：クラウドネイティブ エコシステム
 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 データエクスポート機能 データインポート機能
 バックアップ・リカバリー機能
 診断・モニタリング

26. データ移行について MySQL その他 TiDB TiDB DM Qlik, DMS等 MySQLからの移行については、TiDBツールのDMを使用可能です。 それ以外からの移行については、3rd partyツールを使用することでデータ移行が可能です。
27. まとめ ①大量の書き込みスケールが必要！ データ量が増える事の性能劣化が悩み 
 　オンラインでのスケールアウトが可能・事前の詳細なサイジングは不要 
 ②シャーディング運用から脱却したい！ 
 　分散型アーキテクチャにより煩雑なシャーディング運用から脱却できる。 
 　シャーディングされたDBもそのまま一つのTiDBクラスターへ移行が可能。 
 ④リアルタイム分析をしたい！ 
 　今までリアルタイム分析の妨げになっていたETL処理が不要 
 　分析用コンポーネントによりトランザクションデータをワンシステムでリアルタイム分析が可能 
 ③AP(分析)ライクな複雑なクエリの性能を向上させてたい！ 
 　分析用コンポーネントを応用し特定のクエリだけ処理させて性能向上をさせることも可能 
 TiDB Cloud Free Trialはこちら https://tidbcloud.com/signup
28. Thank You! https://www.pingcap.com/ info@pingcap.com