关于数据库国产化的10大真相

2023年 12月 18日 59.4k 0

   对于数据库国产化这个话题,最近几年十分火爆,因此这几年诞生了数百家数据库厂商,因此这个话题似乎再怎么谈都不过时。实际上对于数据库的替代,最早是阿里提出的去IOE架构,其中O就代表以国外Oracle为代表的商业数据库,然后大家都知道了这个说词。至于阿里为什么要去IOE架构,其实有过不少揭密了,简而言之,成本是很大的因素,这里我们不去过多讨论。言归正传,我们继续回到数据库国产化这个主题上来。

   说到数据库国产化,实际上并非最近几年才开始推国产化,实际上很早就开始进行了,大伙儿都知道国内老牌数据库厂商达梦,人大金仓等已经存在很多年了;至少我在2015年之前就在某政府单位看到过达梦数据库了。只不过在以前,没有政策驱动,大家的做法都是主打一个爱国情怀,所上系统并非核心而已。

   接下来我们就来聊聊大家对于国产数据库的一些误区!

真相1 - 国产数据库能力不行,扛不住高并发

    前几年大家对国产数据库实际上是抱着很大怀疑态度的,这一点不可否认。首先互联网公司宣传通常过于夸大,其次传统老4家厂商确实也没有太多跑大型核心系统的经验,心里也没底,所以用户没信心,这在所难免。然而随着最近2年某O和某T的TPCC打榜,可以看出,首先国产数据库的性能是跟得上的,不需要怀疑;其次一些集中式数据库在比较高端的硬件条件下,跑个200w+ tpmC也是常有的事儿,比如openGauss。

    其实数据库能不能支持大型高并发系统,确实需要时间来检验,最重要是用户要给数据库厂商机会去尝试,否则就只能在边缘徘徊。另外不同的业务系统场景和特点,对数据库的要求也是不同的,因此用户选择的时候,比较慎重,我认为是可以理解的。

     好在近1~2年陆续有很多厂商数据库都上线了一些大型核心系统,比如银行新核心、省级社保系统等。

    但我们不可否认的是,国产数据库仍然与国外商业数据库有一定差距,比如优化器能力,不能单纯只看TPCC打榜。

真相2 - 数据库国产化能极大的降低成本

  说到成本,我想最近1年更为敏感,经济下行,用户自然更加care成本。将商业数据库替换成国产数据库,一定会降低成本吗?答案是否定的。

 举个简单例子,假设一个用户一套Oracle RAC系统运行上2台x86服务器+1个共享存储上。这里假定x86均为4路16core。我们来简单算算成本。

 1、首先大部分可还是没有购买license,就算购买,也并非严格按照官方要求去购买,按照官方要求是1C大概4.6w美刀,30w RMB左右。

2、存储成本   目前市面上一套中端存储也就几十万,国产的可能价格更优惠。

3、DB运维成本,硬件运维成本也较低,1年10个w就搞定了。

    如果你算算,你会发其实也没多少钱,曾经某金融客户1年在数据库方面投入都不到200w的费用,然而为了国产化,听说第一年买某集中式数据库license就花了300多万。

    很多情况下,硬件都可以复用,差异也就在license成本上而已,其次还需要考虑到应用的改造成本,实际上在某些特定场景下,成本可能还略高,比如之前我提到的一个场景,Oracle在虚拟机情况下跑的快,到某集中式国产数据库环境上之后(还是物理机)反而更慢了,需要更换SSD才能解决其IO放大问题;就算是完全兼容的情况下,也需要付出额外的一些硬件成本。

     如果我要换成分库分表之类的分布式数据库呢?实际上license成本也不会便宜多少,其次硬件成本会增加不少,运维成本也会有所提高,最后就是应用改造的代价。

     如果你要是换成某O数据库,那么你最起码需要3台高配x86+一台低配x86(部署运维管理平台等),同样,除了license成本,也面临高昂的运维成本和应用改造代价。 如果要细算,真不见得成本更低。

    说到这里,还想起几年前的一个Case,某客户DB2出问题了,影响较大,苦于大家对DB2对运维能力的担忧,客户下定决心想将其改造成Oracle,由于数据库超过100TB,因此我们报了数十万的数据迁移费,然而应用厂家报价超过达到了8位数,几乎重新开发一套应用了,虽然我们都知道应用要大幅改造,但是这确实有点狮子大开口,客户最后咬咬牙,放弃了。

     最后熟悉电信运营商的朋友,都知道中国电信这些年几乎完成了数据库国产化,全部迁移改造到了TeleDB和TelePG,成本有降低吗?曾经某客户2套双节点RAC就搞定的事儿,到Teledb之后,大概是60多台机器,引入了大量开源组件,需要不同技能域的人才能hold住运维。

    简单总结一下:国产数据库license不便宜,运维成本、改造成本并不低。

真相3 - 数据库替代很容易,没有什么系统是不能替代的

  这个问题,理论上是100%均可替代,但理想很丰满,现实很骨感。数据库的替换,我认为要看业务场景和系统复杂程度,对于大部分逻辑简单的系统来讲,我认为是完全没问题的。

  比如我们曾经就在疫情期间,将某省疫情防控系统从MySQL迁移到了MogDB,通过MTK工具基本上一键完成异构迁移。因为这个系统确实很简单,整个数据库不到100个表,整个库也就几百个GB。

  对于一些非常大型的系统,比如数十TB,数百TB的核心系统,同时又是存储过程重度使用的系统,其实迁移改造还是非常费劲的,我们今年迁移某客户的系统,据MogDB部门同事反馈有上千万行存储过程代码,可想而知,难度有多大。

  最后,能完成数据迁移,不代表能很好的运行,用户还需要去关注应用的实际运行效果,比如某个业务之前在Oracle上跑1分钟,那么自然希望迁移到国产数据库之后,执行时间不要超过1分钟,至少差距不能太大吧。实际上这一点,是极其困难的,众所周知,Oracle的优化器是比较强悍的,因此国产数据库在这块都面临很大的挑战。

真相4 - 国产数据库更简单,运维更轻松?

    近几年我也接触过不少国产数据库了,当然都不精通,只是入门并有所了解而已,比如达梦,openGauss,OceanBase,TDSQL,GoldenDB等。实际上国产数据库在文档方面相对来讲要差不少,其次在可观测性方面也有不小的差距,这对于我们DBA来讲,都一定程度增加了运维难度和门槛。

    所以这几年不少国产数据库厂商,都在努力增强兼容性,除了降低应用改造成本之外,我想一定程度上也降低了大家的运维成本,至少上手学习更快了。

    但是目前不少国产数据库对Oracle、MySQL、PostgreSQL的兼容性都比较高的了,比如OceanBase这几年在Oracle兼容性方面做了大量兼容性增强,从官方文档来看明显能够感觉到。至于达梦数据库,大家几乎公认的,在Oracle兼容性方面做的比较好的,实际上最近2年,我们MogDB在兼容性方面也下了不少功夫,保守估计90%兼容性是能够达到的,对于一些简单业务系统,兼容性会更高。

真相5 - 核心系统一定要上分布式,非核心用集中式

   针对这一点,之前就已经讲过,我们不能无脑得选择分布式还是集中式,要根据自己的实际业务特点和情况来选择。一个医院HIS核心系统,可能就2个T,连接数也就1-2k,你觉得上OB或者TDSQL合适吗?当然如果客户有钱,另当别论。说实话,连Oracle、SQL Server都用不好的用户,要用好分布式数据库,我想难度是挺大的。

   目前基本上所有国产集中式数据库,RPO都可以做到0,RTO控制在30s以下。我想这几乎满足99%的业务系统了吧。

  

  

    因此,对于大部分用户来讲,大部分系统用分布式,有点大材小用,杀鸡用牛刀了。但是这一切现在都变了,都变了。因为OceanBase 4.x版本推出了单机分布式版本;也就是说,以后中小型系统,你也可以使用OceanBase单机分布式版本,随着业务的增加,以后还可以平滑扩展为分布式架构。感觉OceanBase要称霸的节奏。

    实际上,我认为这是一个必然的结果,就关系型数据库市场份额而言,集中式数据库的份额是80%,分布式数据库仅为20%。说到这里,大家应该就不难理解了。

真相6 - 分布式高可用才能6个9,集中式数据库达不到

   我认为这个是谬论。如果你去看分布式数据库厂商官网,你会发现大家不约而同都宣称数据库能实现6个9的高可用,相对来说某T分布式的宣传比较切合实际:

   某T分布式是这样说的:

      摘取自腾讯云官网:

    数据库实例可用性可达到99.95%;数据的可靠性可达到99.99999%。

  如果你看某个G官网你会发现是这样宣传的:

     99.9999%高可靠,业务不中断

   某云是这样描述某G的:

    数据可靠:数据持久性高达99.9999999999%,保证数据安全可靠,保护业务免受故障影响

    至于某O分布式,不用说了,一直宣传都高可用都是6个9.

    这里我们不去讨论大家是否宣传过度,我想表达的是,实际上衡量一个系统的高可用能力,不能只看数据库本身,你还需要看看应用、网络、服务硬件层。比如你3个Server的x86,大家认为数据既然三副本了,通常x86本地磁盘都不会再做RAID,而会使用RAID0,这个时候系统能不能达到6个9的高可用,可能很大概率取决于硬盘坏不坏了....

    这里再给大家举一个真实的例子:2010年我去某省会城市做数据库巡检时,发现某房管局核心系统运行在vmware虚拟化环境中,且使用的是Oracle 9.2.0.1 单机,从当时的巡检数据来看,该实例稳定运行超过3年,从未出现过重启等重大问题,简直堪称奇迹,我当时是非常震惊的。所以这个你能说这个架构很牛B吗,看实际情况确确实实高可用超过了6个9;因为一年之内都没出任何问题呀。或许有人要说我是在偷换概念,高可用讲的是理论值,但是我想理论应该是为实践服务才对。

    另外这里我需要补充一句,数据库服务器不重启不宕机,不代表可用,毕竟应用很差劲,是很容易引发一些数据库本身的故障的,导致数据库实例堵塞、甚至夯死的的情况比比皆,因此我们不能停留在理想层面。

    最后请记住,再牛X的数据库,再牛X的硬件,都扛不住巨烂的应用,应用代码质量跟不上,要保证高可用是很难很难的。除了应用代码本身,应用人员也容易搞事儿,还记得10多年,在某移动现场时,发现某大厂应用人员,一个统计SQL(可能是为了下班之前出结果并汇报),开了20个并行,直接把4节点BOSS系统干废了。。。

真相7 - 分布式多副本 不需要容灾和备份

   曾经见过某大厂销售去推广数据库,说我们的数据库是3副本,最大支持5副本,支持三地5中心,不需要进行备份。说实话,听到这话,我是有点震惊的。

   任何数据库软件,都有有概率面临软件本身的故障,一旦软件本身遇到未知Bug,那么可能会导致整个集群都不可用或者损坏,那么如果没有备份,没有容灾环境,你说结果会怎么样?

   

    备份容灾是一定需要的,我们团队每个月都要做数次数据库异常恢复,见过了太多血淋淋的教训。

真相8 - 分布式性能一定比集中式性能强

     如果比性能不能只看厂商官网宣传的数据,这实际上没有任何意义,同时tpcc打榜的数据也仅供参考。没有哪家to B客户一套核心数据库环境会堆个几千台服务器。通常一个省级客户,比如某省社保,涉及到数千万人,也就10多台x86搞定(跑某O分布式),实际上以前也就是一套4节点Oracle RAC而已;前前后后系统稳定下来,花了几个月时间,很多一部分全靠应用调整和SQL优化。如果此时去比改造前后性能,无任何意义。

    我想,应该比的是:应用程序在改造前后的运行效率,或许更有价值。

    如果大家去看分布式数据库厂商官方文档中的优化部分内容,你就会发现,要用好分布式数据库,其实对应用开发的门槛要求是较高的,如果不遵守开发规范,像Oracle一样去使用分布式,那么可能效果不会太好。这方面网上也有不少文章,其中老白之前就写过不少内容,大家可以参考。

    同样很多场景下,单机数据库效率比集群要高很多,大家脑补一下Oracle单机和RAC集群就知道了,一个道理。同理,大家去看看分布式数据库为什么要复制表,广播表,同步表等就知道了。是的,就是为了解决跨节点查询等性能问题。

  因此,脱离实际业务场景的比较,都是不可缺的。

真相9 - 分布式压缩很厉害,能节约很多空间

    最近看到一些尝试宣传,迁移到分布式后节约了多少多少倍存储空间,实现了降本增效。首先压缩主要用于AP场景,TP场景并不是太适合。

    就拿Oracle来讲,其11g版本开始使用的zlib算法;比如openGauss就支持多种,推荐使用是zstd,某O分布式也支持多种压缩算法。实际上各家数据库默认使用什么算法,都是基于数据压缩率和性能方面的综合平衡考虑,如果压缩率高,那么通常性能就略差,毕竟你解压时间会更长,这都是相对的。比如Oracle官方之前就宣传高级压缩可以达到4~5倍;如果你使用Oracle Exadata HCC,白皮书据称可实现6~15倍的压缩比。也就是说你1.5G的表,压缩只有100M左右,然而大多数情况下,你去测试发现根本达不到,这还需要看数据类型。

    刚刚提到数据压缩都是在性能与空间上做平衡,如果你去看Oracle官方文档,也会告诉你,跟进压缩级别的不同,会有额外3~5%的CPU开销。我想告诉大家的是:跟对象的访问频率有关,通常会比这个额外3~5%的消耗高出很多。我清楚的记得,10多年前,有客户因为数据安全问题,最后要做数据加密;因为使用了Oracle 11g,因此选择了TDE。最后我发现实施完毕之后,应用性能影响很大,大概是官方宣称的4-5倍。因为大家之前都低估了应用负载,实际上应该选择极少部分核心表或者核心表的某些字段,观察一段时间之后,再逐步调整,达到一个性能平衡点。

真相10 - 数据库被卡脖子

   我认为数据库并没被卡脖子,即使你之前用的是Oracle、DB2、SQL Server等国外商业数据库,就算想大毛一样被漂亮国断供了,那么。。。你的数据库仍然在运行,并不会被停止或者有什么后门之类的。大不了我们不买原厂服务不就行了,过去买过license的客户,仍然可以继续使用,我们数据库保持版本不变,不升级不就完了吗?合理合法。

   其次这些年开源软件这么🔥,不用Oracle,DB2,你还不能用MySQL、PostgreSQL吗?如果说你担心 MySQL会甲骨文公司的影响,那么你用PG大概率是没问题的。只要自己开发搞定定,运维玩得转。如果真的搞不定开源数据库运维,可试试 zCloud,目前支持10多种主流数据库,还是可以极大得降低企业数据库运维压力和门槛的。

    想想19年HW被漂亮国断供了,想下单给甲骨文,但是甲骨文都不敢接招。没有原厂的兜底服务支持,最后我们挺身而出,为HW某BG全球的业务提供了很好的后端支撑。

    说到最后,我觉得对于新系统,大家都可以选择国产数据库,无论是分布式还是集中式,根据业务特点和实际情况选择即可,对于存量系统(应用不再变化),可替可不替(政策驱动除外)。国产数据库还有很多问题,但是大家需要要给数据库厂商一些时间去成长,去追赶,给机会去历练,只在场外坐冷板凳,不上场是永远得不到分的,也检验不了能力。

    罗马也不是一天建成的!

    无论怎么讲,这些年国产数据库的发展进步还是很大的,我们与漂亮国的差距总会逐步缩小。

   

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论