分布式数据库-应用场景与对比测试2

今天接昨天的话题，讨论分布式数据库的对比测试的一些经验分享。从2013年开始，我和子衿技术团队进行过多次分布式数据库的对比测试，深知测试对比的难度，要想做到比较客观的评价一个分布式数据库，确实是比较难的，因为不同产品的技术架构、技术特点、擅长领域、技术短板等各不相同，要想做出一个较为客观的评价确实有很大的难度。

2014年，为了帮助一个客户选择数据仓库的数据库产品，我们对国内外的主流分布式数据库进行了一次全面的评测，当时参加评测的涵盖了当年最流行的商用数据库，包括TeraData、IBM DB2、 netezza、HP VERTICA、Greenplum、Oracle Exadata一体机、南大通用GBASE 8A、达梦DM MPP、曙光、腾讯、浪潮（星环）等。通过那次测试，在几个月时间里，和这些数据库厂商摸爬滚打，我们初步积累了一定的分布式数据库的测试经验，给我们后来进行各种类型的分布式数据库测试锻炼了一支队伍。

第一因素：节点数量。进行分布式数据库对比测试首先我们要考虑分布式数据库环境的节点数量问题，对于绝大多数分布式数据库来说，节点数量太少会导致无法发挥出分布式数据库的优势与性能特点，而节点数量太多，对于测试团队又有很高的要求，另外节点数量越多，测试用例所需要准备的数据量也越大。测试节点数量的选择还需要考虑最终建设数据库的节点数，远远超出今后试用数量的测试意义也并不很大。在测试节点数的选择上，一定要听取参测数据库厂商的建议，然后结合自己最终的应用场景与测试环境的限制，综合选择适当的节点数量。

第二因素：节点配置。分布式数据库的架构各异，不同的数据库对节点的配置要求也不相同。设计节点配置的时候一定要充分考虑各个数据库产品的配置要求，选择一个适当的配置。如果配置过低，会导致部分数据库无法发挥出器性能特点，配置过高，对于那些对于硬件配置要求较低的数据库产品来说又不公平。这些产品可能可以在较低的硬件配置下跑出高性能来，但是高硬件配置对其性能提升作用有限。最终节点硬件配置应该综合考虑这些因素，同时考虑今后在分布式数据库上硬件投入的多少，做科学合理的设计。如果设计不当，可能会有不少数据库产品在这一环节就已经被淘汰了。

第三因素：数据准备。分布式数据库绝对不少跑个Benchmark就可以进行选择了。一定要用你自己的测试用例测试数据进行严格的测试，否则Benchmark跑的再好，到了你的应用上照样拉稀。如果你要测试一个比较复杂的HTAP环境，那么需要精心准备测试数据。当我们的原始数据不足时，可以采用翻数的方式成倍拷贝数据，让数据达到测试所需的量级。另外因为不同的分布式数据库的数据分片策略会有不同的优化策略，因此在数据准备上应该允许各个厂商对表结构做一定的优化，比如表分区的方式、表分区的数量、表上的索引的结构，表PAGE的填充因子等，都允许进行调整。不过这些调整必须在正式测试进行之前完成，在整个测试过程中，不允许对数据进行重新分布、也不允许添加删除索引。如果厂家要求作此工作，那么所有的测试必须重新开始，以前的所有测试用例均应作废。分布式数据库的数据分布不同对不同的测试用例会有不同的效果。另外有些数据库产品会通过添加Bloom Filter、添加额外的索引、设计物化视图等方式来对某些SQL进行优化，这个也没有关系，如果在实际生产环境中，也可以通过这些方式来优化应用的性能，这些技术也不是不可以采用的，不过这些设计都会对数据的装载、大批量写入、大批量修改产生负面影响。因此这些设置必须在所有的测试开始前就完成。

第四因素：SQL改写。SQL改写应该是被允许的，因为不同的数据库因为实现方式与架构不同，对于某些复杂SQL的支持时不同的。大部分SQL改写是因为性能问题，还有一部分SQL改写是语法支持的问题。我们应该允许部分SQL改写，但是对于不同类型的SQL改写，应该适当的予以扣分。如果我们的测试中，针对某种数据库的兼容性测试在测试目的中占比较大，那么我们对于不兼容的SQL语法导致的改写要扣更多的分。而因为执行效率而改写的SQL是因为优化器技术的差异而导致的，如果我们对优化器的考察占比较大，那么因此改写的SQL扣分也可以加大。SQL改写一定要注意等价原则，改写后的SQL一定是实现同样功能的。这一点需要在数据验证时有所跟踪。

第五因素：数据验证。针对每条SQL的执行结果，必须有专门的工具进行数据比对，其结果集必须时完全相同，测试结果才能被确认。如果执行结果出现不正确的情况，并且无法在测试期间完成调整（通过补丁、参数调整等方式），那么这个数据库的所有测试成绩均应该被视为无效。

第六因素：即席查询。即席查询应该被设计为闭卷考试，如果整个测试大多数测试用例都是开卷考试，所有的测试用例都在测试开始前发给了考生。而即席查询的测试用例一定对于考生来说是闭卷的，临时性的。并且不同的考生使用的参数一定是存在一定差别，但是又基本上等价的。这种测试用例的设计十分考验测试组织者的水平。在分布式数据库测试的时候，每个参测厂商都会根据测试用例选择最适合整个测试的数据分片方式。但是在我们的实际应用环境中，不可能所有的SQL语句与业务都是在数据模型设计时就已经设计好的，生产数据一般也不能总是可以根据执行效率做重构。因此即席查询是必然要测试的内容，这也可以看出某个数据库在应对临时性需求或者新增需求时的适应性。在即席查询测试时，不允许对原有数据做除了添加索引外的调整优化。

第七因素：测试结果评价。对于如此复杂的测试，结果评价也十分重要。很多客户为了简化评价标准，会把所有的测试用例的总时长累加来进行排序评估。这种方法操作起来比较简单，但是容易混淆不同数据库之间的技术与性能差异。因为某些大型查询的效率直接决定了测试的成绩。而我们实际应用中最为常用的一些比较快的查询性能之间的差异就会被掩盖。因此按照每个测试用例设定分值，每个测试用例中的不同并发数分配响应的打分比重，按照最快的作为满分，线性评分的方式相对来说时比较科学的，不过对于测试团队来说，需要花更多的精力来设计打分表。

分布式数据库的评测与对比不仅仅是针对性能，还有一些其他的因素，比如部署安装、运维、监控、扩容缩容、高可用、容灾、破坏性场景测试等。由于测试内容十分复杂，做较为广泛的对比测试成本太高，只有部分大企业坐得起。有些测试场景，可以先不做实际测试，让各个厂商描述其支持情况，作为初评的依据。当该产品入围后，再做实际测试，这样也可以降低测试的成本。