众所周知,或因为性能、或因为功能、或仅仅因为长期以来的流行度原因,我们所接触的绝大多数应用程序都是基于oracle、mysql、sqlserver或是近几年异军突起postgresql数据库来编写代码的。而在近几年国产化浪潮下,数据库也在国产浪潮中不断发展,或自研、或借鉴、或套壳。截止7月,墨天轮中国数据库流行度排行收录的国产数据库就有282个,其中关系型数据库有173个占61.35%。
我所服务的客户最近也在做国产数据库的测试试点工作,选择了两家国产数据库(这里就不点出名字):一家是主要做集中式数据库的,本次测试的是基于k8s底座的多租户数据库架构(后简称“数据库a/a厂商”);另一家则是主推分布式数据库的,本次测试是3节点3副本架构(后简称“数据库b/b厂商”)。这里就从我的切身体验说说我对国产化数据库的一些感受、不满和愿景。
无一例外,两家数据库都派了自己的工程师来部署数据库,而二者还是有区别:
- 就a厂商来说他们的常规架构数据库的部署文档还是非常完善的,新手可以很快上手,而本次使用的容器架构还比较新的架构,还不大完善,但是从官方文档的整体结构来看已经相当完善了。
另一方面,数据库a还提供了各种开发版和docker版,可以快速部署、快速上手,帮助运维人员和开发快速熟悉数据库环境,加上较为完善、友好的官方文档,可以很好的加速数据库生态建设。
当然部署过程中还是看到了一些不尽如人意的地方,因为作为一个传统型数据库厂商,虽然上了k8s,但是目前对k8s的使用还是不完善,仅仅只能用自己熟悉的功能或组件来部署,这就限制了应用场景,毕竟客户的环境、安全、要求千奇百怪,把自己架构限定死了不是一件好事。 - 而对b厂商来说,部署就“黑盒”多了,直接自己就部署好了,从官方网站来看,文档不完善、相对老旧,且没有提供开发、测试版本下载,通过公开渠道获得数据库信息的少之又少。
无论怎么说,换了数据库总归要去适配,毕竟每种数据库有自己特有的sql规范、特性、功能。毕竟就连相同的数据库比如oracle从11g升级到19c,如果用到了wm_concat函数也是需要去处理的。
2.1 驱动
虽然两个数据库都说完全兼容oracle语法,使用jdbc连接数据库,当然a厂商可以直接用oracle协议连接数据库,而厂商b则需要使用需要换成mysql协议来连接数据库。而两家厂商都提供了各自的数据库驱动包用于替换原来连接oracle数据库的jdbc驱动。
这个适配操作说大不大,说小也不小,不经过充分测试,是不可能确保每条代码兼容性的,特别是换成mysql协议的厂商b。当然厂商a那边也出现了一些数据库存放数据正常而前端显示乱码的问题。这些坑都要去踩还要填的。
这里可以对比下oracle,还是11g升级到19c,可以通过设置数据库连接兼容版本来让应用程序使用“祖上”版本驱动来连接数据库。
2.2 数据量
我们本次选择的业务系统,使用al32utf8字符集,数据量大概4tb,中间包含非常多的报表查询、分页展示。对于厂商a来说,问题相对少一些;而厂商b的现场工程师从来问数据量开始,就表达了“没见过这么大数据量”的感叹,后面的测试也差强人意。
经过数据迁移及一周的业务测试后,本周应用厂商向客户做了阶段性反馈:
1.一般小功能来说,二者基本都能实现,但是数据库a的适配度好于数据库b。
2.对于报表和分页查询来说,数据库a无需修改就能实现90%以上的功能,剩余的绝大多数也可以通过数据库本身调整、优化(参数、数据处理等)解决,极少部分需要反馈研发解决;而数据库b则是绝大多数无法实现,且绝大多数需要反馈开发来适配。
3.两个数据库都出现过数据库连接不稳定、性能发挥不稳定的现象。
4.两个数据库在使用更高规格硬件的情况下,绝大多数的响应速度均不如oracle数据库(部分业务响应时间远超过业务要求)。当然也有在无任何业务压力情况下,数据库a的部分sql测试响应快于oracle数据库的。
- 我们这的测试试点还没有涉及分布式改造(数据库b虽然标榜分布式,但是使用3节点3副本mysql协议,我感觉本质上和mgr没啥区别,本质还是集中式)。即便是表现好很多的数据库a也需要进行大量的测试、调整、适配去解决功能、兼容性和性能方面的问题。(还是对比下oracle,找台不那么差的服务器装好数据库,再部署好应用程序,几乎就能上线了,这样的“开箱即用”还是很爽的。)
- 回到总数多达173的国产关系型数据库,如果要全部去适配,除去套壳的几乎不用改的、同宗同源的算作一个和数据库厂商适配的非常好的,业务厂商至少也要做接近3位数的适配,而且有些适配是双向的,数据库厂商也需要去调整,做个性化适配。如果还涉及集中式改分布式,就不止是代码变更了,还有业务逻辑适配变更。这中间得花掉大家多少精力。
- 个性化适配带来的是数据库代码的“个性化”,很多时候是上午出问题,下午开会改代码,晚上加班割接上线,周而复始,无穷无尽,好不容易解决的差不多了,数据库版本更新,一切回到初始(合代码的问题),欲哭无泪。
- 282家国产数据库,真正静下心做数据库的厂商有多少,有多少只是想乘风而行,我不得而知,但是肯定不少。这也造就了很多厂商在百花齐放的背景下做着自相残杀的事情,另一方面既没有好好做产品也没有好好做生意。造成it从业者对这些数据库的了解几乎没有。如同一位大佬说过的一句话:“oracle将除了代码的一切都告诉了你,而很多国产数据库除了源代码什么都没告诉你”。二者对比,对我这种数据库维护人员和业务开发人员来说,哪个更友好,不言而喻。
- 少一些数据库厂商,可以更好的集中数据库研发人才、集中相关商业资本、减少不必要的恶性竞争。
- 打磨产品的同时,去营建良好的生态,只有生态好了,让大家了解你的数据库,理解你的数据库,用你数据库的人多了,才能有更多的机会去磨砺自己的数据库,用实打实的业务来验证数据库并改进自己的数据库。
- 用更开放、全面、包容的态度去看待数据库,毕竟场景那么多,术业有专攻,复杂场景很难用一种数据库解决问题,我们还需要扩展更多数据库类型。
最后来一句,文章标题所提的“开箱即用”,包含:数据库部署后可全面兼容;数据库直接能安全稳定运行;数据库性能良好且确保稳定发挥。