国产数据库对比测试应注意的七个要点

昨天一个朋友打电话来讨论，说他们在做国产数据库测试的时候，原本一个场景某数据库跑出来的性能与他们的预期差不多，不过数据库厂商不满意，于是上去调整了一通，居然性能大幅提升，并且远超出他们对产品的理解。实际上做国产数据库的对比测试是一件十分不容易的事情，往往想获得一个较为公正的结果，但是总是觉得被厂家牵着鼻子走。作为一个最近这十多年来参加过多次数据库基准测试和选型测试的我，今天就聊聊这个话题吧。

既然是对比测试，那么公平是第一位的，而针对现在数据库架构十分复杂，差异性很大，这种情况下，要公正十分困难，在第一个环节，底层硬件配置上就十分困难，有些时候只能使用等价配置。前阵子有个测试，参测的其他数据库都是分布式数据库，数据都是可以存储在本地的SSD盘上的，不过有一个参测厂商是使用共享存储读写分离架构的，那么就必须给他们提供集中式存储。而如果提供集中式存储，那么硬件环境就又不相同了。让分布式数据库也使用集中式存储？分布式数据库厂商对集中式存储的性能又提出了疑义。最后幸亏是后来那个厂家退出了，这件事才圆满解决了，否则我都有点蒙圈。

测试中第二件让人疑惑的事情就是能否让数据库厂商来操作测试或者操作测试环境。以我多年的经验来看，如果能够不让厂家接触测试环境，尽可能不要让他们接触。以前做基准测试的时候，IBM/HP等参加测试能力很强的企业都有十分丰富的应对此类测试的经验，别的厂商和他们一起测试，绝对不是在参加一个公平的测试。现在某些国产数据库厂商已经把IBM等的精髓学得差不多了，和他们一起玩，防不胜防。也有朋友担心不让厂家接触环境，会不会因为优化不到位而导致某些厂家的测试结果不客观呢？其实这一点容易解决，厂家可以旁观，或者对测试结果提出疑问，并且根据采集到的监控数据提出问题点，不过尽可能不要让厂家直接操作系统。否则就会出现我文章前面讲的场景，不知道厂家做了啥，系统莫名其妙的大幅提升了。

第四个问题是在测试过程中是否允许改写SQL语句，不同的数据库，其优化器和SQL引擎是有差异的，有些在ORACLE上能跑并且跑得不错的SQL，可能在国产库上跑得很差甚至无法执行。这一点其实很常见，也并不能说国产数据库就不行。如果通过等价改写能够解决这个问题，那么我们应该能够承认这个测试结果。只不过我们要记录一下，经过了等价改写。既然判断是等价改写，我们就需要严格比对输出的结果是否正确。

第五个问题是，是否允许在中途调整数据库参数或者表的分区分布。这一点严格上说应该不允许，不过对于一些较为复杂的测试，特别是在分布式数据库上的测试，刚开始的分布策略设计可能不够合理。有些时候做些调整，会有很大的性能提升。不过要注意的一点是，如果做了这方面的调整（哪怕是修改了一个参数），所有的已经测试过的测试项都必须重新测试一遍，并将以前所有的测试结果作废。为了确保测试进度，这种调整一定要做限制，比如每个厂商只允许调整一次。

第六个问题，SQL性能测试最好带有背景压力。我们经常会遇到测试时候性能不错，实战时候差强人意的情况。这是因为SQL在测试环境是独立运行的，没有任何背景压力干扰，高可用切换场景或者故障自愈场景也是如此，在没有一定负载下，都是很正常的，带一定的背景负载很可能就不同了。我们以前曾经见过某国产数据库，跑200并发BENCHMARK的时候性能不错，不过如果连上10000个空会话，再跑BENCHMARK，性能要打不少折扣。这可能是数据库在维护会话列表的代码上没有做好优化导致的，虽然是个小问题，不过如果没有注意，到了生产环境还是会引发问题的。

第七个问题是要关注SQL执行的稳定性问题，如果你的应用场景是对小SQL的执行延时有要求的，比如银行的核心交易系统，现在网联对核心交易超时的监控十分严格，那么SQL执行的稳定性就十分关键了。同样一条SQL是否执行起来忽快忽慢，相同的SQL是否经常出现多次执行执行计划不同，这也应该我们关注的。如果时间充裕，最好多跑几遍，最后算个标准差出来，做个比对。

实际上很多时候测试往往并不能对我们的决策产生多大的影响，有可能IT部门辛苦几个月干完了测试，突然某厂家与企业高层签署了战略合作协议，那活就白干了。不过测试中发现的问题，积累的经验，今后运维中还是有点价值的。