腾讯云tdsql mysql版分布式数据库的测评

1、TDSQL介绍

tdsql mysql版是腾讯云推出的分布式数据库,重点在于“分布式”。在单例mysql中假设你的订单表中的数据极速增长,可能就会碰到单机瓶颈。而tdsql可以将订单表中的数据平均(几乎)分布在多个实例之中,从而降低数据库的压力。而且还能支持一键横向扩容,增加新的实例。

与此类似的开源方案其实也不少,比如mycatshardingspheremysql route等。而我们为什么要选择商业方案而不是开源方案呢。因为一旦选择开源方案,就意味着必须自己运维,而招聘一个具有专业数据库中间件运维知识的技术人员的成本,那还不如直接选择商业公司的产品。出了问题不太想要自己操心,而且稳定性相对来说也会好很多。

2、TDSQL的架构和适用场景

tdsql不像sharding-jdbc一样需要在客户端增加额外依赖。将sql的路由转发、sql下推等动作放到了mysql的proxy中。也就是说,客户端的jdbc其实都是直接链接的proxy,具体这个sql发送到哪台mysql实例,则会由proxy自行解析判断。

tdsql架构图

其实分布式的特点就决定了他的适用场景,如果你的业务符合以下特点,就建议使用tdsql:

  • 绝大部分是单表查询
  • 查询条件相对简单
  • 数据量大(至少TB级别)
  • 大部分表有合适的分区键

3、TDSQL的槽点

3.1 主键不能单调递增

对于分布式表来说,你可以设置主键是自动增长的,但是tdsql并不能保证他是单调递增的。这将导致之前那些按照id进行排序的sql,必须改成显式的按照创建字段进行排序。而这个改动又有可能进而影响到索引的使用,explain时会发现Extra中多了Using filesort,影响了性能。而之前按id排序是没这个问题的,因为id本身是主键,在索引节点中能找到值,不需要回表。

3.2 对于分布式表会自动创建一级分区

分布式表会对shardingkey字段强制创建hash分区,这将导致执行一些left join时横扫多个分片,从而导致性能降低。

解释leftjoin语句

3.3 自带控制台监控时间粒度太小

最小的监控时间粒度为1分钟。而我在数据库中做了一个操作,需要等2-3分钟才能看到控制台中监控的变化,这给运维带来了极大的不便。因为执行一些风险较高的sql时,我们想要实时的监控数据库的状态以便知道对生产环境的影响。

tdsql控制台

3.4 监控分组不合理

无法体现分片和节点之间的从属关系:

tdsql实例分组

3.5 慢sql日志的时间跨度太小

一个慢sql会划分为很多个时间段的慢日志,而没提供一个慢日志文件合并的功能,当需要分析长时间的慢日志时,非常麻烦。

tdsql慢日志

3.6 慢查询分析模块缺少重要指标,且无法排序

不需要使用pt-query-digest,tdsql也默认提供一个慢日志分析的模块。但是还是有很多的不足。

  • 有几个重要的指标是缺少的:最大扫描行数和最大发送行数。这两个指标能够帮助运维发现并优化一些极端sql,从而提高生产系统的稳定性。

  • 其次就是无法对指标进行排序,默认是按照总耗时来排序。假设我需要按照锁的时间来排序呢?

tdsql慢查询分析模块-自定义列表字段

3.7 在慢查询日志中,无法反推找到原始sql

如果在tdsql中执行一些复杂sql,会被proxy改写,然后再将改写的sql下推到各个实例执行。但是在底层mysql实例中记录的慢sql日志是改写后的sql。假设需要优化这个sql,肯定还是要找到原始sql,才好定位到位置然后针对性的优化。

当你在慢sql中发现有带/*filter*/注解的sql时,就能确定该sql是有proxy改写产生的。