TiDBのすすめ - Why TiDB? How to play TiDB? -
はじめに
なぜTiDBなのか?
今までMySQL運用においてメジャーバージョンアップで長時間の計画停止が不可避な状態でした。それはクラウドの世界になっても変わらずです。特に大規模DB群になると停止時間も長くなり、その間勿論ユーザーは利用不可で固く言えば機会損失になります。また、たとえ計画停止であっても関係者への説明であったりその調整コストも大きく単純にユーザーへの影響のみならず、社内或いは社外関係者含めた対応コストも非常に大きい状況です。
この誰も幸せにならない状況を今までは私自身もやむを得ないと考えていましたが、TiDBの登場によってその常識を覆せるのではないか…と思いTiDBの検証を始めた次第です。
TiDBのアーキテクチャー
そもそものTiDBのアーキテクチャーです。大きく分けて下記のコンポーネントが存在しますが、これらが全て分散して存在することによりアプリケーションからの処理は勿論、各種DB運用もRolling Updateで実行する形になります。
一般的なOTLPワークロードではTiDB, TiKVのコンポーネントが利用されます。TiFlashと呼ばれるもので、これは分析系のOLAPワークロードに特化した内部的なColumner Databaseです。このTiFlashが優秀なのが実行計画のコストに基づきTiKVで処理するか、TiFlashで処理するか自動的に処理をしてくれます。従来は分析用のReplicaを容易することが一般的ではありましたが、TiFlashを用意しておけばこのようなReplicaは不要になります。Placement Driverの詳細はここでは触れませんがTiDB全体のメタデータの管理をしているサーバーだと理解いただければ一旦は問題ありません。
- TiDB
- SQLの実行計画や実行をするCompute Node
- TiKV
- OLTP用のデータが分散して格納されるKVS Node
- TiFlash
- OLAP用のデータが格納されるColmner DB Node
- Placement Driver
- 管理用のメタデータが格納される Node
引用:TiDB Docs
- 管理用のメタデータが格納される Node
TiDBに期待していること
端的に記載すると下記になります。
- MySQL互換による導入の容易さ
- TiDBはMySQL互換の分散DB
- 完全オンラインなので計画停止を撲滅可能
- scale up/down、バージョンアップも完全オンライン
- 分散DBであるためSharding運用の考慮が不要
- TiKVのスペックを増加させるのみ
- OLAPをTiFlashが透過的に処理するためReplicaが統合可能
- 内部的にTiFlash(ColumnerDB)を持っており透過的に問い合わせをしてくれる
- オンラインでのScale up/downによるコストメリット
- Online Scarable によってピーク時のみ最大スペックにすればよい
例えば、上記が実現するとどうなるでしょう?ビジネス側の人間は機会損失がなくなり且つ従来の計画停止の調整が不要になる、アプリ担当者は1つのendpointを意識すればよくなり難易度の高いSharding設計をしなくてもよくなる、インフラ担当者はDBの管理対象が減りそもそものDB構築作業から開放されるという世界観になると考えています。きっと10年後には『昔のDBは一々停止が必要だった…』とおじさんが昔話に興じているかもしれません。
私は上記未来を信じています。事実、Google Spannerは分散DBとして最もメジャーで、一部でその世界を実現しています。但し、Google Cloud限定であることと、多くの大規模DBが稼働するMySQLとの親和性は低いため、普及にも限界があります。私自身はGoogle Cloudを使っていたのですが、既存の大規模かつ重要なMySQLのデータベース群をSpannerに移行することはできませんでした。
上記の壁を破れるのはプラットフォームに依存しないオープンなTiDBである、と私は考えています。
TiDB Playgroundによるハンズオン
ここからはまずは触ってみることことにします。TiDBでは簡単にローカル環境で試せるPlayground環境が公式から提供されているのでまずはそれで手触りを確認してみましょう。今回は MAC で試してみます。
TiDB データベースプラットフォームのクイックスタートガイド
構成としてTiDBの実際の導入時の最小構成を意識して下記を起動してみることにします。
- tidb3台
- tikv3台
- tiflash1台
- tiproxy1台
TiDBのinstallをやってみよう
- まずは Tiup を install します
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
- tiupに対してPATHを通します。.bash_profileのPATHに下記を追加してください
/Users/${USER}/.tiup/bin/tiup
- tiup コマンドで起動します。"&"をつけてバックグラウンドで起動しておきます
tiup playground latest --db 3 --kv 3 --tiproxy 1 &
成功すると下記が出力されます。TiDB毎にendpointが出力されていますが実際の接続はTiProxy経由で実行します。
🎉 TiDB Playground Cluster is started, enjoy!
Connect TiDB: mysql --host 127.0.0.1 --port 4001 -u root
Connect TiDB: mysql --host 127.0.0.1 --port 4000 -u root
Connect TiDB: mysql --host 127.0.0.1 --port 4002 -u root
Connect TiProxy: mysql --host 127.0.0.1 --port 6000 -u root
TiDB Dashboard: http://127.0.0.1:2379/dashboard
Grafana: http://127.0.0.1:3000
- 実際に起動しているコンポーネントは下記で確認できます
tiup playground display
Pid Role Uptime
--- ---- ------
1461 pd 13m45.315835792s
1462 tikv 13m45.292767792s
1463 tikv 13m45.266129583s
1464 tikv 13m45.247316791s
1465 tidb 13m45.20931175s
1469 tidb 13m45.142490916s
1472 tidb 13m45.12311975s
1880 tiproxy 13m39.835374125s
2176 tiflash 13m4.989221541s
- tiproxy経由で接続してみましょう、MySQLユーザーにとって馴染み深い出力が見られるはずです
mysql --host 127.0.0.1 --port 6000 -u root -e "show databases;"
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| mysql |
| sys |
| test |
+--------------------+
TiDB DashboardからMetricsが見える状態にしよう
- ブラウザで下記URLを入力してください
ユーザー: root
パスワード: (入力なし)
http://127.0.0.1:2379/dashboard
2. 何故かprometheusが12020 portでLISTENしていたのでブラウザ上で下記URLから変更します
http://127.0.0.1:2379/dashboard/#/user_profile
3. ここまでで一通りのMetricsが見えるようになりました!
まとめ
なぜTiDBに注目しているのかのユースケースベースと実現できる世界観は従来の常識を覆すものがあると考えています。また、TiDB PlaygroundのInstallまでやってみましたが、非常に簡単でかつここで紹介した以外にも多くのオプションがあり簡単な検証や構成理解であればTiDB Playgroundで事足りる印象です。次回ではsysbenchによる負荷がけと各種Metricsの確認、またTiDBの大きな特徴であるKey Visualizerの機能を試していきたいと考えています。
Discussion