私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT に参加しました。オンライン参加。簡単に所感をまとめます。
所感
特に全体的に共通して言われてたのは書き込みのスケーラビリティと MySQL 互換であること。今回、既存システムの DB を移行する事例が多かった気がするので、互換性の高さが大きなメリットになったんだろうと思いました。たしかにアプリケーションコードを変更しなくてもいいのは助かる。あと、学習コストが低く抑えられるっていうのもいい。
HTAP という言葉は初めて知りました。Google Cloud だと Spanner + Big Query みたいなもんなのかしら。LINE ヤフーさんの話は性能検証の観点として参考になりました。
Spanner にも go-tpc みたいなツールあるのかな...。あと、プッシュダウンみたいな考え方は Spanner にもあったような気がする。(たぶん)
GitHub - pingcap/go-tpc: A toolbox to benchmark TPC workloads in Go
以下、メモから抜粋。(資料が公開されたらリンク追加します)
最近たまに見かけるTiDBってなんだ？
- TiDB
- NewSQL
- トランザクション
- スケーラビリティ
- computing nodes
- マルチマスター
- PKのレンジでチャンクを持つ
- リーダー: R/W
- フォロワー: バックアップ
- 自動フェイルオーバー
- HTAP
- OLTP + OLAP
- トランザクションと分析のワークロードを実現
- アーキテクチャ
- TiKV
- Row型
- ストレージ
- 分散型 KVS
- PD
- チャンクの物理的な配置場所を管理
- TiFlash
- Column型
- TiKVからレプリケーションして使う
- Serverless
- マルチテナント
- Dedicated
- 専有型
検証を通して見えてきたTiDBの性能特性
- Write Heavy
- 書き込みのスケーラビリティ
- go-tpc
- TPC-C シナリオ
- パフォーマンステスト
- 書き込みのスケーラビリティ
- PK range update
- QPS
- 小さい range だと MySQL の方が高速
- range が増えても TiDB は安定する
- クエリレイテンシ
- inner join / 相関サブクエリ
- TiDB の方が5倍以上早い
- 大きめのクエリで TiKV にプッシュダウンできると早くなる
- TiKV 側で複数ノードで並列処理できるため
@cosmeのTiDB採用までの道のりとか
- SQL Server/MySQL → TiDB
- Aurora
- 強制バージョンアップ
- 無停止バージョンアップ
- ローリングアップデート
DMMプラットフォームがTiDBを採用した背景
- TiDB Cloud
- 書き込みのスケール
- 強整合性
- 耐障害性
- DB起因のダウンタイムを避けたい
- パフォーマンスはRDBに劣る
- APIレベルのレイテンシ劣化は100ms未満
- Spannerの方がDBとしては完成されている
- インターリーブ
- MySQLプロトコル互換
- テーブル定義の変更が不要
- アプリケーションコードの変更不要
- MySQLエコシステムを活用できる
- 学習コストが低く抑えられる
コロプラでの長期運用プロジェクトでMySQLからTiDB移行の検証について
- MySQL互換
- スケールアウト/スケールイン
- メンテナンスなしでバージョンアップ可能
- ローリングアップデート
- データ圧縮によるディスク削減
- 1/3くらいまで圧縮できた
- 大量データのときに TiKV 上でリージョン分割が発生
- リージョン間のやりとりで TiKV の負荷上昇
- PKやインデックス追加で軽減できる
- 広い範囲を見るクエリは苦手
- それを補完するのが TiFlash
- トランザクション分離レベル
- REPEATABLE READ
- InnoDB エンジンに依存するロジックの改善は必要
長期間TiDBを使ってきた話
- メンテナンス/スケールアウトが容易
- tiup コマンド
- TiFlash
- OLTP + HTAP が1システムで実現できる
- dashboard 便利
- TiProxy
- TiDB の前段にいるプロ棋士
- 無停止アップデート
- ローリングアップデートしても外から見るとコネクションは切れない
- TiFlash 活用
- ヒント句で TiFlash のテーブルを読むようにする
あとで読む。
