昨天的文章，最后简单说了一下数据库测试。最近很多用户都很关心数据库测试，因为他们都很关心信创数据库是怎么选的。前几天和一个客户谈信创数据库选型的时候，我的观点是，对于国产数据库的选型，目前一些国测的测试报告参考价值不大。数据库benchmark非常难，因为我这十年也帮客户组织过几次benchmark测试，我知道其中的辛酸。目前很多数据库厂商都以TPMC测试数据作为其数据库性能优秀的佐证。但实际上TPC-C的测试非常复杂，我们在自己的测试环境中跑几次BENCHMARK工具是无法得到结果的。BENCHMARK测试是一项成本非常高的测试，需要对软件、硬件、网络等环境进行细致的优化，才能取得好的成绩。还有一套评价结果有效性的标准。时间延迟的标准差和P90/P95/P99位置的时间延迟都是检验某个TPC-C测试结果是否有效的重要因素。这些不是任何用户或数据库供应商可以自己完成的。另一方面，用户的应用系统能够在一定的基础设施上运行良好的效果，TPC-C级别其实占比并不高。比如并发能力。我曾经和一家商业银行的行长算过一笔账。他们目前的系统在高峰期平均每秒交易量在1000笔左右，换算成TPMC大概是6万笔左右。即使未来5年增长5倍，也就是30万个TPMC。目前国内的2路服务器在运行国内任何数据库时，TPMC都可以轻松达到100万左右。因此，对于大多数非Internet服务，TPMC不是问题。数据库测试是一件非常复杂和昂贵的事情，公平地做好基准测试并不容易。十多年前，我帮一个客户比较了X86服务器和小型机的性能，做过Xeon服务器和IBM/HP/ORACLE小型机的对比测试。使用了用户拥有的数据和测试用例。为了保证公平，我们允许厂商做一定程度的优化，同时也颁布了非常严格的限制，比如不能使用异步提交，不能随意篡改数据，不能把REDO放到内存文件系统中等等。因为涉及到后续的集中采购，各厂家也都非常重视。我什至在一个厂商的工作区里找到了我几年前写的《ORACLE优化日记》的副本。看来这哥们准备学以致用了。.事实上，X86服务器在当时就已经展现出了极其强大的能力。一台不到10万元的服务器，基本可以和2万到300万元的小型机抗衡。INTEL的哥们对数据库优化了解不多。安装好系统，调整好基本参数后，用了不到一天的时间就完成了我们安排的3天测试工作。而且小型机厂商非常细心，仔细优化每一个测试用例。在分析测试数据时，发现某厂商的一组测试用例的结果有些异常。其他测试数据，小型机的结果与X86基本一致，部分用例甚至略差。不过从这组测试数据来看，小型机胜在X86等小型机厂商。从我们的数据完整性验证脚本中，没有发现数据被篡改。突然想起了《Oracle优化日记》这本书，于是让测试组查看了几个核心表的索引的CLUSTERFACTORY值，发现其中一张表的索引的CLUSTERFACTORY和测试的不一样其他企业的环境。事实证明，该组中的大多数测试用例都使用了索引范围扫描。为了提高性能，制造商重新排列了表中数据的顺序。这其实是《Oracle优化日记》中介绍的一个优化技巧。看来这哥们真的学会了，用得上了。后来在我们的测试用例中，记录的顺序也作为一个验证项。数据库基准测试是测试团队与参赛团队之间的较量。如果测试团队的技术能力不如参赛团队，就很难保证测试数据的准确性。现在的数据库测试包括代码自主率的测试，这也是很多企业在选择数据库型号时非常看重的。我所知道的很多基于开源代码开发的数据库产品，在一些国家测试中，代码自主率都达到了90%以上，甚至95%以上。这让我很疑惑，直到真正看到一份检测报告才明白过来。有一个基于开源代码开发的数据库产品。代码自治率测试结果为96.3%。但仔细阅读报告后发现，送测代码总数为93万行，送测模块中没有SQL引擎、优化器等。,是一些外围模块。但是，作为一般的数据库选择用户，您是看不到详细报告的。我们只能看到公布的96.3%的代码自治率。这种测试也使这些测试变得毫无意义。当然，从我个人的角度来看，代码自治率并不是一个非常有意义的指标。实际上，用户在选择数据库时更需要了解的是某种数据库产品是否好用，是否能够在某种应用场景下得到很好的支持。比如我的财务系统需要把Oracle换成国内的数据库，所以想知道用友和金蝶的产品在某个数据库上运行的怎么样。数据库厂商不会提供有价值的数据，金蝶用友官方也不会告诉你这些数据。我们国家检测部门能否组织国内的数据库和国内的封装软件厂商在这方面做一些测试并公布测试结果？如果这些测试数据能够发布，那么对于用户进行国产数据库选型，其价值远远超过现有的所有测试。如果我们要了解数据库对复杂SQL的支持能力，那么我们可以从ERP系统与Oracle的一些关键模块的性能对比中，清楚地了解到某个数据库产品对复杂SQL的支持情况。如果想了解高并发环境下的并发写入能力，一些物联网打包软件的测试结果很有参考价值。
