数据库产品用什么抓住用户

发布时间：2025-11-04 23:35:22 来源：创站工坊 作者：人工智能

​周五聊了下数据库基准测试的数据什抓一些事情，现在客户选择数据库产品，库产唯一比较有权威的品用就是一些国测机构的测试结果。企业自行搞选型测试是住用十分困难的，一方面成本太高，数据什抓一方面自己的库产能力不足，很容易被人忽悠瘸了。品用

周五的住用文章有搞数据库的朋友留言，谈了对测试的数据什抓一些看法。比如代码自主率测试，库产有朋友说可以要求数据库厂商现场编译，品用现场测试。住用我不知道有多少厂商可以很方便的数据什抓把整个数据库的编译环境都部署到测试现场去，这对测试机构是库产个巨大的挑战。哪怕真的品用可以这样做，还是有些作弊手段可以使用的。我以前搞类似测试的香港云服务器时候，就有厂家把容易扫描出问题的代码做成lib库，或者甚至把这些obj打到linux系统的lib库中，跟随着编译依赖库一起通过YUM先安装好，然后直接链接到应用系统里，这样我们的扫描工具就扫描不出这些代码的问题了。

实际上对于绝大多数用户来说，关心的并不是数据库代码是否自主，而是数据库本身的功能是否满足自己的需求。对于一些国企央企或者国有控股企业来说，对于代码自主率的焦虑主要是怕自己选择的数据库产品最后无法被国家认可为信创产品。信创数据库的认定国产以前是采用清单的，不过这个清单覆盖面太小，因此也被广为诟病。

除此之外，实际上客户最为关心的源码下载问题就是国产数据库用起来是否便捷、数据库可靠性如何，高可用切换是否简单可靠、数据库的性能如何、数据库的运维难度如何、数据库的周边生态工具是否完备。

数据库用起来是否便捷实际上是用户在做数据库选型的时候最为关注的问题这个是设计师并不是我们的数据库厂商最为关注的问题，不过对于一些运维能力相对不足的中小型客户来说，在数据库选型的时候可能会把使用便捷性放在第一位。很巧的是，最近在和两个金融用户讨论国产数据库选型的时候，他们都在三四个数据库中做选择，经过测试试用后不约而同的服务器托管选择了TDSQL。当时我觉得有些意外，后来询问原因后才明白了其中的奥妙。实际上TDSQL并不是一个数据库，而是一个数据库云平台，其扁鹊平台可以很方便的维护一个大型的数据库云平台，像普通的云平台提供的RDS一样快速交付各种数据库。TDSQL不是一个数据库，TDSQL平台可以提供单机MYSQL实例、单机PG实例、分布式数据库等。客户选择TDSQL的最终原因是他们的MYSQL单实例对他们迁移一些小系统来说完全够用了，而扁鹊平台的能力让他们节约了大量的建设投入。在国产数据库内卷如此激烈的时候，数据库产品在核心能力上提升很难，但是提供一个类似“扁鹊”的平台，我想并不困难。

数据库一旦上线运行后，就难免会出现各种问题，导致实例宕机。用户也认可单实例数据库肯定是不能100%可靠的，但是如果数据库实例宕机后能够做自动迁移或者自动重启，对于核心生产系统来说，可以秒钟级主备自动切换，对于普通业务系统来说，可以分钟级故障恢复，那么数据库实例宕机并不会对核心业务产生重大影响，这些都是可以接受的。最主要的是数据库厂商要能够提供一个完整的解决方案，既可以方便的部署，也可以放心的使用。类似于Oracle GDS的能力，对于用户的关键应用来说是十分必要的。

至于数据库的性能，这是用户在做数据库选型时最为迷茫的，什么样的性能才是企业所需要的。TPCC肯定不是用户数据库性能的关键点。很多应用系统从Oracle迁移到国产数据库的时候，并不是因为国产数据库并发处理能力不足而出现了性能问题，而是因为国产数据库在表连接算法方面的的性能差异，执行计划方面的差异导致了较大的性能差异。我遇到过一个客户的数据库从Oracle迁移到某国产数据库后，核心业务模块普遍性能下降了二三十倍。经过分析发现，最多的问题是因为索引设计导致的，原有的索引设计在Oracle上效率还不错，但是到了国产数据库上就不行了。还有一些是国产数据库的表连接方面与Oracle存在技术差异，很多SQL在国产数据库上无法使用Oracle上的执行计划。遇到这种情况，我们就只能通过改写SQL来解决问题了。目前的国产数据库替代存在大量的存量替代问题，因此国产数据库产品需要做好这方面的对比测试，如果数据库产品确实无法采用较好的执行计划来执行某些SQL，则应该发布优化建议，让用户能够快速找到解决方案。

对于数据库来说，除了数据库核心的能力之外，生态工具的完备性也十分关键，比如数据库异构复制工具、数据库迁移工具、数据库备份工具等。数据库系统往往不是孤立的，异构数据库之间需要进行双向的数据复制，因此国产数据库需要能够和一些主流的国产数据库、开源数据库、大数据平台之间进行双向数据复制。甚至在目前阶段，国产数据库与Oracle之间的数据双向复制工具还是必须存在一段时间的。数据库迁移工具主要是支持将应用与数据从Oracle迁移到国产数据库，不仅仅能够迁移表结构，还要能够支持大数据量的批处理迁移与增量复制。另外还需要能够迁移Oracle 的PL/SQL存储过程，让整个数据库应用能够很便捷的迁移过来。备份是另外一个大问题，虽然所有的数据库厂商都提供了备份工具，但是备份工具与主流的磁带库，备份管理工具，备份一体机，CDM等能否兼容也是十分关键的。这涉及到多厂商之间的生态协作，比起数据库厂商自己就能干的事情来说更为复杂，难度也更高，特别是涉及一些国外数据库备份工具的情况。

除此之外，数据库的运维接口与运维工具也十分关键。目前大多数国产数据库能够提供的运维接口十分有限，数据库厂商能够提供给客户的运维知识更是凤毛麟角。国产数据库对于用户来说就是一个十分不稳定的黑匣子，说不准什么时候就出问题了。更有甚者，有些用户现场的问题，我们的数据库厂商都很难定位问题的原因，这样的数据库产品让用户用得提心吊胆的。

提升数据库核心的能力，这需要很长的时间的积累，甚至无法完全依靠数据库研发团队的技术能力。很多数据库性能的提升是在实际应用中遇到了问题，才去想办法解决的。研发人员在设计数据库产品的时候很难想得到这样特殊的应用场景。因此这些核心能力的积累是需要时间的，很难一蹴而就。不过我今天提到的一些能力都是在数据库核心能力之外的，只要我们的数据库厂商想去完善，也是完全有能力做到的。​

相关文章