TiDBとMySQLの機能比較
ZOZO Advent Calendar 2022 カレンダー Vol.3 の 9 日目の記事です。
久しぶりのブログ更新になります。前回からだいぶ時間が空いてしまったので定期的に書けるようにしていかないとと反省しています。。
NewDBと呼ばれる新しいデータベースが登場し利用事例が増えてきました。その中でもMySQL互換のTiDBについて耳にする機会が増えたので、MySQLとの機能比較を行ってみました。DB選定や移行検討の際にお役に立てれば幸いです。
TiDBとは
TiDBはPingCAP社が開発した分散型データベースで、RDBMSとNoSQLの機能を組み合わせたデータベースです。
MySQL互換のSQL解析機能を持っているためアプリケーションからはMySQLと同様のアクセスが可能であり、水平方向のスケーラビリティ・協力な一貫性・高可用性を兼ね備えています。
MySQLとTiDBの比較
アプリケーションから利用する際の機能比較になります。インフラ・運用面、費用などは利用する環境によってパターンが多く出てしまうため、対象外とします。
トランザクション分離レベル
(一つの表にまとめるのが困難だったので別途切り出してます...)
- ダーティリード:コミットされていないデータを別トランザクションで読めてしまう
- ノンリピータブルリード:コミットされたデータを別トランザクションが読めてしまう
- ファントムリード:取得したデータに対して別トランザクションがInsert or Deleteしてコミットすると同じ条件で読み込むとデータが増減している
MySQL8
ダーティリード | ノンリピータブルリード | ファントムリード | |
---|---|---|---|
READ UNCOMMITTED | ◯ | ◯ | ◯ |
READ COMMITTED | ◯ | ◯ | |
REPEATABLE READ (デフォルト) |
|||
SERAIALAZABLE |
TiDB
ダーティリード | ノンリピータブルリード | ファントムリード | |
---|---|---|---|
READ UNCOMMITTED | ◯ | ◯ | ◯ |
READ COMMITTED | ◯ | ◯ | |
REPEATABLE READ (デフォルト) |
◯ | ||
SERAIALAZABLE |
- MySQL(InnnoDB)はREPEATABLE READでファントムリードが発生しない
- TiDBはREPEATABLE READでファントムリードが発生する
- TiDBトランザクション分離レベル
その他
項目 | MySQL8 | TiDB | 備考 |
---|---|---|---|
DDL |
|
||
権限 |
|
||
文字コードと順序 |
|
|
|
索引 (index) |
|
||
一時テーブル (temporary) |
|
||
ビュー (view) |
|
||
分割 (partition) |
|
||
自動採番 (auto increment) |
|
||
外部キー (foreign key) |
|
||
ユニーク制約 (unique index) |
|
||
検査制約 (check) |
|
||
型 (data type) |
|||
結合 (join) |
|
||
トリガー (trigger) |
|
||
ストアドプロシージャ、関数 (procedure/function) |
|
||
集計関数 (window function) |
|
|
まとめ
MySQL5.7をベースにしているだけあってMySQLと同等のことが行えそうです。ただ、
- 外部キーの動作
- auto increment
は、データの整合性・値を別途取得するなど、アプリでの対応が必要となり移行の際に改修ゼロとまではいかなそうです。外部キーはプロジェクトのルールで必須となっている場合もあるかと思うので、使えないのは厳しいかもしれませんね。 とは言いつつもここまで互換性があると、書き込み性能に困っているアプリケーションの移行先にTiDBが選ばれるのも分かる気がします。近い将来、機能差異もなくなるのではないかと思うと今後の動向を注目ですね。
次回はアプリケーション(SpringBoot+JPA)からTiDBを利用する記事を書こうと思います。