发布于:2024-05-17 14:01:54 来源:产品展示 点击量:14次
前面两篇文章的阅读量似乎都不错,不少网友给我私信留言,建议我写一下数据库选型方面的。
老实说之前还真没有专门去写过类似的文章,虽然过去几年,我们帮助很多客户都做过数据库选型咨询的工作,我自己也给一些客户做过数据库选型的PPT宣讲,但是公开文章似乎还真没写过。
这里我就来展开分享一下我个人的一些观点吧,希望对大家正在进行或者即将进行的数据库国产化/改造带来一些帮助或启发。
首先我这里申明一点,我这里重点是探讨数据库国产化,如果你所在的企业无这方面的需求,自己觉得使用开源MySQL、PostgreSQL就好了,基本上可以解决95%的场景了。
为什么数据库国产化选择这么难,导致大家都有选择综合症了;根本原因还是数据库厂商太多了,如果大家去看摩天轮的排名统计,10种数据库场景类型,合计285种数据库;老实说80%的数据库,我个人都没听过。
如果说一个企业要将数据库进行国产化替代,那么去把主流数据库都测一遍?这个工作量是巨大的,又或者去请各个数据库厂家来讲一讲?那势必也是各说各的好。我曾经就在某大型客户现场听到客户领导说,某分布式厂商的售前去给他们交流,一顿狂吹,反正就是一个字:牛!遥遥领先!xxx第一!用户心里自然是打鼓的,完全不放心,然后跟找我探讨了很久。
目前国产数据库虽然很多,近300种,但是除了少数业务场景比如图、向量、时序之外,其他几乎均为关系型。由于目前关系型数据库也开始具备非关系型数据库的一些能力,大家都看看Oracle 23 Ai版本就知道了,因此我们想我们探讨关系型就足够了(毕竟现在数据库国产化选型主要聚焦是在关系型数据库上)。针对目前国内的上百家关系型数据库厂商,我们大家可以大致分为如下几类:
实际上就上面几种情况去看,非要说哪种更好?老实说,不太好讲;但是从我们的建议来看,毕竟国产化是为了zz,那么第一先考虑PG生态系列,或许会更好一点。之所以这么讲,其实无非就是一个观点:站在巨人的肩膀上。当然很多很多国产纯自研的厂商我个人也非常的佩服,但是无可厚非的是:沉淀时间还是短了一点。
之前有网友说说MySQL也是属于Oracle公司,也属于老美,而PostgreSQL不是,且开源协议完全不同;因此MySQL可能面临断供,而PG不会?本着好奇的心,我查了一下pg14官方公布的代码贡献者的分布,发现我们和老大哥的比例加起来也就14%左右,几乎只有漂亮guo的一半(当然这里是只是统计的人数,如果要看代码量的话,其实china是非常少的。。。)。
不过不得不承认,这几年国内的PG社区活跃了不少,同时PG系列(或者同源)的数据库也要多很多,其中最为出名的就是openGauss系列了,作为目前国内根技术最大的数据库社区之一。
现在国产数据库架构归纳一下无非就如下几种。1、主备(主从)架构 - 比如DM、kingbase、MogDB、Gbase 8s等
对于分布式数据库的架构分类,实际上我认为是比较乱的,我这里就随意了;毕竟各个厂家对自己的宣传都是不太一样的,还有动不动就是Ai Native的。
对于数据库架构的选型,我认为现在大部分用户都比较理性了,不像3年前,大家几乎都是一股脑的听各个厂家宣传,形成了一个固定的认知:核心库选分布式、非核心集中式!实际上我认为这个认知是完全错误的。
前段时间写了一篇文章,提到绝大部分系统实际上都不需要上分布式,不单单是从数据量方面出发,还要从运维管理成本、用户自身开发运维水平等多重维度。另外就是这些年随着硬件能力的加快速度进行发展,实际上非常大程度上削弱了分布式架构的优势。
事实上我们还有很多企业级用户,基本上没有数据量超过10T的单库,大都是几百GB~2TB之间,这些客户居然连一套RAC集群都没有!是的,你没有看错,他们都是单机!而且跑的很稳,也就是最为核心的库部署了DataGuard,其他库容灾都没有。如果说,我们大家都认为人家架构不合理,有问题吧,可是人家跑了10多年了,没出过什么大事儿。我甚至见过某某客户之前的Oracle系统全部在Vmware虚拟机,跑的也是很稳。
对于分布式,无论是分库分表方案还是原生分布式,实际上用户首先要从自己真实的情况出发,先看看自己开发团队,运维团队能力能否跟得上,其次才是考虑分布式架构带来的极致高可用。
实际上要说极致高可用,现在几乎所有分布式数据库最快也要接近10s左右,Oracle RAC相对稳健一点,最快能在3-5s左右(RTO)。而其他国产数据库大多需要10-30s不等。
疫情过后的这2年,整个大环境都不太好,很多客户自己都没什么钱了,因此在数据库国产化替代方面,表现得必须更加抠抠索索才行。这么这样一个时间段数据库兼容性,对于用户来讲,就显得很重要。就目前我之前调研的一些行业来看,目前比如政府、运营商、金融、保险、证券、轨道交通、能源等行业主要是Oracle、MySQL为主,其中Oracle占比可能会非常高;另外医疗、制造业、高校、零售SQL Server的比重也较高。
那么此时国产数据库对于Oracle、MySQL的兼容性来讲,就是重中之重了,在前几年可能还没那么突出。
今天我去拜访过不少用户,用户几乎都如出一辙的提到一点:希望MogDB在兼容性方面比较高,最理想的情况是应用代码完全不改,先完成zz任务再说。应用完全不改,也就是意味着兼容性要做到100%,尽管这个不太现实。
从我个人接触和了解的情况去看,目前达梦、Kingbase、Oceanbase、TDSQL、GoldenDB等都在做这方面的加强,尤其是OB,明显感觉到这2年迭代比较迅速。当然在Oracle、MySQL、PostgreSQL的兼容性方面,MogDB目前也做得很不错了,大部分系统兼容性能做到95%了。
数据库生态我认为是数据库选型最重要的一环,为什么这样讲?虽然国产数据库厂商有些做的早几年,有些晚几年,老实说我认为总体差距不会太大。这样一个时间段,用户应该去关注的是你所选择的这数据库的生态如何,比如是开源还是闭源;数据库社区建设如何等等。我想不用我多讲,大家必须知道,走开源路线的数据库生态一定要好得多,实际上也确实如此。大家都看看国产的OB、TiDB、openGauss就知道了,同时能再对比一下其他厂商。
说到这里,我想一定会有人抬杠;人家Oracle也不开源,为啥全球市场占有率这么高呢?我认为不可比较,Oracle占据了天时地利;从另外一个角度讲,我认为Oracle提供了非常详细的文档和各种你几乎能想象到的跟踪trace手段,让你窥探Oracle的运行机制。我想这几乎等于开放了源代码。
另外我们大家都知道企业的数据库系统往往不是孤立的,需要对接很多上下游的系统,对接很多应用厂商、硬件厂商、备份厂商等等。
如果一个数据库产品适配的上下生态产品越多,那么也代表着该产品成熟度可能越高,至少对于用户来讲,其花费的成本将会更低。比如若用户使用了某国产DSG的备份软件,那么数据库进行数据库替换,最好是数据库软件已经适配过dsg,否则还需要用户去单独采购一套其他备份产品,成本方面肯定会增加。
我相信任何一个数据库厂商在进行软件售卖时,通常都会带1年的软件质保期,那么最近一段时间内,数据库厂商可能会给用户更好的提供一些数据库支撑服务;在维保期厂商或许还能很用心的服务。但是一旦过了质保期,那么很多数据库厂商的不一定就能支撑的过来了,因为这非常考验数据库厂商的售后支持能力。比如,目前国产数据库厂商,哪家厂商售后数据库支撑团队能有100人?200人?甚至更多?
实际上之前某某数据库快速扩张,收割了很多客户。客户就给我反馈过,数据库原厂根本支持不了,本地一个人都没有,而且据了解,其他省项目多,本地招聘的原厂售后工程师,大多数都是安装部署,故障处理大都不会,因为很多都是刚毕业甚至毕业不久的人,总之,售后支持能力确实良莠不齐。
其次如果大家去看所谓的AK list会发现,有些公司,老实说我以前都没听过;突然跳出来给用户卖数据库,吹嘘自己有10多年的数据库经验,能让人信服吗。当然,也有一定的可能是我们太孤陋寡闻了。
为什么要讲企业自身的研发能力呢?实际上我认为,目前基本上没有哪家厂商能做到应用代码0 修改,就能够从Oracle迁移到国产数据库。之前听说某某数据库号称99%兼容oracle;在项目poc国产中,用户的数千存储过程线改造,就能完全移植过去。But 不幸的是,很多真的是为了兼容而兼容,不少存储过程根本跑不动;那么这部分代码就必须进行重构。因此若企业自身的研发能力不够的话,那么指望数据库厂商来修改,我想这个难度是很大的,除非项目金额大,数据库厂商愿意不计投入。
根据我们这几年的国产化经验来看,若用户自身研发能力可以跟上,那么其实就兼容性来讲,90%和95%的不兼容比例,差距并不大的。
另外如果你选择了分布式数据库,那么就务必要熟悉分布式数据库的一些开发规范,假设自身开发能力很弱甚至完全依靠第三方应用厂商,那么这样一个时间段通常就会比较被动了。
最后来说说用户自身的运维能力。实际上从我这些年接触的数百家用户来讲,相对来说;我认为银行、运营商、证券、保险的能力相对来说比较强,别的行业则相对要弱得多。即使IT能力较强的用户,很多大都是依赖第三方运维,自身的IT运维能力是欠缺的。由于国产数据库相比国外商业数据库的成熟时间来讲短了不少,因此在稳定性、文档、成熟度方面都有一些差距;因此用户就需要去建立自己的国产数据库运维规范,而且这个也是一个不间断地积累和完善的国产;毕竟很多第三方专业服务企业在这方面积累都不够,更不要说甲方用户了。
对于很多没有专业数据库运维团队的用户来讲,那么选择数据库可能就更应该去关注生态了,起码数据库生态繁荣,学习的人多;真要是哪天出了问题,找人也好找一点吧。