一、单SQL性能对比
由于TiDB的并发能力优秀,但是单个SQL执行延迟较差,为了客观对比,所以只用1个线程来压测tidb和mysql,以观察延迟情况
二、并发SQL性能对比
TiDB:v6.5.2 MySQL:8.0.26 (单机)
三、结论
在无并发的情况下,TiDB的性远低于MySQL
所以使用TiDB一定要注意以下2点:
- 对于TP业务,一定要提高并发,发挥分布式数据库的优势
- 对单个SQL延迟异常敏感的业务,慎用TiDB
对比
- 提高并发后,TiDB的性能和MySQL相当。
- MySQL已经是上限:MySQL有单机处理的上限,不会上升。如果MySQL采用了半同步,或都 MGR的话,性能还会降低.
- TiDB只是初始值,没有上限,随着增加节点,性能不断线性上升
三、数据库选择
对于MySQL不能满足的场景,推荐使用tidb数据库。比如:
- tps超过5000
- qps超过8w
- 单个mysql实例超过2T(不符合开发规范)
- 单个库存储空间超过1T(不符合开发规范)
如果对响应延时有较高的要求,那么推荐使用MySQL
对于核心类业务系统,对稳定性要求高的,推荐使用MySQL
数据库架构选择
- MySQL复制架构当前主要推荐8.0.32版本的MGR以及semi-sync
- 新的集群上线,默认不再提供异步复制
- 对于semi-sync一主两从的管理工具
- 不推荐使用MHA
- 默认使用orchestrator
四、关系型数据库基础选型指标
指标 | MySQL | MRG | TiDB | |
tps | <5000 | <5000 | >5000 | |
qps | <5000 | <5000 | >5000 | |
容量(行数,总空间) | <2T | <2T | >2T | |
单SQL耗时 | <20ms | <20m | >20ms | |
跑批业务 | 延迟小 | 同步延迟大 | 中 | |
硬件成本 | 小 | 中 | 大 | |
故障恢复切换时间 | 慢 | 快 | 快 | |
架构简洁(依赖少,人工干预少) | 需要 | 少需要 | 不需要 | |
生态 | 强 | 中 | 一般 | |