众所周知，或因为性能、或因为功能、或仅仅因为长期以来的流行度原因，我们所接触的绝大多数应用程序都是基于Oracle、MySQL、SQLServer或是近几年异军突起PostgreSQL数据库来编写代码的。而在近几年国产化浪潮下，数据库也在国产浪潮中不断发展，或自研、或借鉴、或套壳。截止7月，墨天轮中国数据库流行度排行收录的国产数据库就有282个，其中关系型数据库有173个占61.35%。

我所服务的客户最近也在做国产数据库的测试试点工作，选择了两家国产数据库（这里就不点出名字）：一家是主要做集中式数据库的，本次测试的是基于K8s底座的多租户数据库架构（后简称“数据库A/A厂商”）；另一家则是主推分布式数据库的，本次测试是三节点三副本架构（后简称“数据库B/B厂商”）。这里就从我的切身体验说说我对国产化数据库的一些感受、不满和愿景。

1.部署

无一例外，两家数据库都派了自己的工程师来部署数据库，而二者还是有区别：

• 就A厂商来说他们的常规架构数据库的部署文档还是非常完善的，新手可以很快上手，而本次使用的容器架构还比较新的架构，还不大完善，但是从官方文档的整体结构来看已经相当完善了。另一方面，数据库A还提供了各种开发版和docker版，可以快速部署、快速上手，帮助运维人员和开发快速熟悉数据库环境，加上较为完善、友好的官方文档，可以很好的加速数据库生态建设。当然部署过程中还是看到了一些不尽如人意的地方，因为作为一个传统型数据库厂商，虽然上了K8s，但是目前对K8s的使用还是不完善，仅仅只能用自己熟悉的功能或组件来部署，这就限制了应用场景，毕竟客户的环境、安全、要求千奇百怪，把自己架构限定死了不是一件好事。

• 而对B厂商来说，部署就“黑盒”多了，直接自己就部署好了，从官方网站来看，文档不完善、相对老旧，且没有提供开发、测试版本下载，通过公开渠道获得数据库信息的少之又少。

2.适配

无论怎么说，换了数据库总归要去适配，毕竟每种数据库有自己特有的SQL规范、特性、功能。毕竟就连相同的数据库比如Oracle从11g升级到19c，如果用到了wm_count函数也是需要去处理的。

2.1 驱动

虽然两个数据库都说完全兼容Oracle语法，使用JDBC连接数据库，当然A厂商可以直接用Oracle协议连接数据库，而厂商B则需要使用需要换成MySQL协议来连接数据库。而两家厂商都提供了各自的数据库驱动包用于替换原来连接Oracle数据库的JDBC驱动。

这个适配操作说大不大，说小也不小，不经过充分测试，是不可能确保每条代码兼容性的，特别是换成MySQL协议的厂商B。当然厂商A那边也出现了一些数据库存放数据正常而前端显示乱码的问题。这些坑都要去踩还要填的。

这里可以对比下Oracle，还是11g升级到19c，可以通过设置数据库连接兼容版本来让应用程序使用“祖上”版本驱动来连接数据库。

2.2 数据量

我们本次选择的业务系统，使用AL32UTF8字符集，数据量大概4TB，中间包含非常多的报表查询、分页展示。对于厂商A来说，问题相对少一些；而厂商B的现场工程师从来问数据量开始，就表达了“没见过这么大数据量”的感叹，后面的测试也差强人意。

3. 业务反馈

经过数据迁移及一周的业务测试后，本周应用厂商向客户做了阶段性反馈：

1. 一般小功能来说，二者基本都能实现，但是数据库A的适配度好于数据库B。

2. 对于报表和分页查询来说，数据库A无需修改就能实现90%以上的功能，剩余的绝大多数也可以通过数据库本身调整、优化（参数、数据处理等）解决，极少部分需要反馈研发解决；而数据库B则是绝大多数无法实现，且绝大多数需要反馈开发来适配。

3. 两个数据库都出现过数据库连接不稳定、性能发挥不稳定的现象。

4. 两个数据库在使用更高规格硬件的情况下，绝大多数的响应速度均不如Oracle数据库（部分业务响应时间远超过业务要求）。当然也有在无任何业务压力情况下，数据库A的部分SQL测试响应快于Oracle数据库的。

4. 我的总结

• 我们这的测试试点还没有涉及分布式改造（数据库B虽然标榜分布式，但是使用三节点三副本MySQL协议，我感觉本质上和MGR没啥区别，本质还是集中式）。即便是表现好很多的数据库A也需要进行大量的测试、调整、适配去解决功能、兼容性和性能方面的问题。（还是对比下Oracle，找台不那么差的服务器装好数据库，再部署好应用程序，几乎就能上线了，这样的“开箱即用”还是很爽的。）

• 回到总数多达173的国产关系型数据库，如果要全部去适配，除去套壳的几乎不用改的、同宗同源的算作一个和数据库厂商适配的非常好的，业务厂商至少也要做接近3位数的适配，而且有些适配是双向的，数据库厂商也需要去调整，做个性化适配。如果还涉及集中式改分布式，就不止是代码变更了，还有业务逻辑适配变更。这中间得花掉大家多少精力。

• 个性化适配带来的是数据库代码的“个性化”，很多时候是上午出问题，下午开会改代码，晚上加班割接上线，周而复始，无穷无尽，好不容易解决的差不多了，数据库版本更新，一切回到初始（合代码的问题），欲哭无泪。

• 282家国产数据库，真正静下心做数据库的厂商有多少，有多少只是想乘风而行，我不得而知，但是肯定不少。这也造就了很多厂商在百花齐放的背景下做着自相残杀的事情，另一方面既没有好好做产品也没有好好做生意。造成IT从业者对这些数据库的了解几乎没有。如同一位大佬说过的一句话：“Oracle将除了代码的一切都告诉了你，而很多国产数据库除了源代码什么都没告诉你”。二者对比，对我这种数据库维护人员和业务开发人员来说，哪个更友好，不言而喻。

5. 我的愿景

• 少一些数据库厂商，可以更好的集中数据库研发人才、集中相关商业资本、减少不必要的恶性竞争。
  

• 打磨产品的同时，去营建良好的生态，只有生态好了，让大家了解你的数据库，理解你的数据库，用你数据库的人多了，才能有更多的机会去磨砺自己的数据库，用实打实的业务来验证数据库并改进自己的数据库。

• 用更开放、全面、包容的态度去看待数据库，毕竟场景那么多，术业有专攻，复杂场景很难用一种数据库解决问题，我们还需要扩展更多数据库类型。

最后来一句，文章标题所提的“开箱即用”，包含：数据库部署后可全面兼容；数据库直接能安全稳定运行；数据库性能良好且确保稳定