周五我们聊了一些关于数据库benchmark测试的事情。现在客户选择数据库产品，唯一权威的就是一些国家检测机构的检测结果。企业自行进行选型试验难度很大。一方面是成本太高，另一方面是自身能力不足，很容易被别人忽悠。周五的文章里，搞数据库的朋友留言，说说对测试的一些看法。比如代码自主性测试，有朋友说可以找数据库厂商现场编译测试。不知道有多少厂商可以轻松的把整个数据库的编译环境部署到测试现场，这对测试机构来说是一个巨大的挑战。即使可以做到，也还是有一些作弊手段可以利用的。之前在做类似测试的时候，有些厂商把容易扫描的代码做成一个lib库，甚至把这些objs打到linux系统的lib库中，连同编译好的依赖库一起通过YUM安装，并且然后直接链接到应用系统，这样我们的扫码工具就扫不到这些码问题了。其实对于绝大多数用户来说，他们关心的并不是数据库代码是否自主，而是数据库本身的功能是否满足他们的需求。对于一些国有企业或国有控股企业来说，对代码自治率的焦虑主要是害怕自己选择的数据库产品不被国家认定为信创产品。过去，新创数据库使用一个清单来识别国货，但这个清单的覆盖面太小，因此也广受诟病。另外，其实客户最关心的是国产数据库是否方便使用，数据库可靠性如何，高可用切换是否简单可靠，数据库性能如何，操作难度如何并维护数据库，数据库周边生态工具是否完备。数据库是否方便使用，其实是用户在选择数据库时最关心的问题。这是我们数据库厂商最不关心设计者的问题。但是，对于一些运维能力相对不足的中小客户，在选择数据库时易用性可能会被放在首位。无独有偶，最近和两位金融用户讨论国内数据库的选择时，他们都在三四个数据库中做出了选择。经过测试和试用，他们一致选择了TDSQL。当时觉得有些意外，问清原因后，才知道其中的奥秘。其实TDSQL并不是数据库，而是数据库云平台。其Bianque平台可以轻松维护大型数据库云平台，并像普通云平台提供的RDS一样快速交付各种数据库。TDSQL不是数据库。TDSQL平台可以提供单机MYSQL实例、单机PG实例、分布式数据库。客户最终选择TDSQL的原因是，他们的MYSQL单实例完全足够他们迁移一些小系统，而扁鹊平台的能力为他们节省了大量的建设投资。在国内数据库卷入如此激烈的情况下，提升数据库产品的核心能力很难，但提供一个类似于“扁鹊”的平台却不难。数据库一旦上线运行，难免会出现各种问题，导致实例宕机。用户也认识到，单实例数据库肯定不是100%可靠的，但如果数据库实例宕机后可以自动迁移或重启，对于核心生产系统来说，可以秒级自动切换主备，而对于普通的业务系统来说，可以做到分钟级的故障恢复，所以数据库实例的宕机不会对核心业务造成大的影响，这是可以接受的。最重要的是，数据库供应商必须能够提供完整的解决方案，可以轻松部署和放心使用。类似OracleGDS的能力对于用户的关键应用来说是非常必要的。至于数据库的性能，这是用户在选择数据库时最困惑的。企业需要什么样的业绩。TPCC当然不是用户数据库性能的临界点。很多应用系统在从Oracle迁移到国产数据库时，并不是因为国产数据库缺乏并发处理能力而出现性能问题，而是因为国产数据库的表连接算法和执行计划的性能差异。性能差异大。我遇到过一个客户的数据库从Oracle迁移到国产数据库后，核心业务模块的整体性能下降了20到30倍。经过分析，发现问题最多的是索引设计的问题。原来的索引设计在Oracle上还不错，但是在国产数据库上就不行了。国内数据库和Oracle在表连接方面也有一些技术上的差异，很多SQL在国内数据库上不能使用Oracle的执行计划。这种情况下，只能通过重写SQL来解决问题。目前国内数据库换机存在大量存量换机问题，所以国产数据库产品需要做好这方面的对比测试。如果数据库产品确实无法使用更好的执行计划来执行某些SQL，则应该提出优化建议，让用户能够快速找到解决方案。对于数据库来说，除了数据库的核心能力，生态工具的完备性也很关键，比如数据库异构复制工具、数据库迁移工具、数据库备份工具等。数据库系统往往不是孤立的，异构数据库之间需要双向数据复制。因此，国产数据库需要能够与国内一些主流数据库、开源数据库、大数据平台进行双向数据复制。即使在现阶段，国产数据库与Oracle之间的双向数据复制工具也必须存在一段时间。数据库迁移工具主要支持将应用程序和数据从Oracle迁移到国内数据库。不仅可以迁移表结构，还支持大数据量的批量迁移和增量复制。另外，还需要能够迁移Oracle的PL/SQL存储过程，这样就可以轻松迁移整个数据库应用。备份是另一个大问题。虽然所有数据库厂商都提供备份工具，但是备份工具是否兼容主流的磁带库、备份管理工具、备份一体机、CDM也很关键。这涉及到多个厂商之间的生态协作，这比数据库厂商自己做的要复杂和困难，尤其是涉及到一些国外的数据库备份工具。另外，数据库的运维接口和工具也很关键。目前国内大部分数据库能够提供的运维接口非常有限，而数据库厂商能够为客户提供的运维知识更是凤毛麟角。国内的数据库对于用户来说是一个非常不稳定的黑匣子，什么时候出问题是说不准的。更何况，我们的数据库供应商很难定位一些用户端问题的原因。这样的数据库产品让用户担心使用它们。提升数据库的核心能力需要长期的积累，甚至不能完全依赖数据库研发团队的技术能力。很多数据库性能提升都是在实际应用中遇到才想办法解决的。研发人员在设计数据库产品时很难想象这样特殊的应用场景。因此，这些核心能力的积累需要时间，难以一蹴而就。但是，我今天提到的一些能力是在数据库的核心能力之外的。只要我们的数据库厂商想改进，他们完全有能力改进。
