前面两篇文章的阅读量似乎都不错，不少网友给我私信留言，建议我写一下数据库选型方面的。

　　老实说之前还真没有专门去写过类似的文章，虽然过去几年，我们帮助很多客户都做过数据库选型咨询的工作，我自己也给一些客户做过数据库选型的PPT宣讲，但是公开文章似乎还真没写过。

　　这里我就来展开分享一下我个人的一些观点吧，希望对大家正在进行或者即将进行的数据库国产化/改造带来一些帮助或启发。

　　首先我这里申明一点，我这里重点是探讨数据库国产化，如果你所在的企业无这方面的需求，个人觉得使用开源MySQL、PostgreSQL就好了，基本上能够解决95%的场景了。

　　为什么数据库国产化选择这么难，导致大家都有选择综合症了；主要原因还是数据库厂商太多了，如果大家去看摩天轮的排名统计，10种数据库场景类型，合计285种数据库；老实说80%的数据库，我个人都没听过。

　　如果说一个企业要将数据库进行国产化替代，那么去把主流数据库都测一遍？这个工作量是巨大的，又或者去请各个数据库厂家来讲一讲？那势必也是各说各的好。我曾经就在某大型客户现场听到客户领导说，某分布式厂商的售前去给他们交流，一顿狂吹，反正就是一个字：牛！遥遥领先！xxx第一！用户心里自然是打鼓的，完全不放心，然后跟找我探讨了很久。

　　那么啰嗦了半天，我们到底应该怎么选？

　　数据库选型我们应该关注哪几个点？

　　我认为我们重点关注这几个点：

　　1、数据库技术路线

　　2、数据库架构

　　3、数据库兼容性与改造成本

　　3、数据库生态及上下游

　　4、厂商支撑能力及规模

　　5、企业自身开发能力

　　6、自身IT运维水平

　　接下来我就从这6个维度稍微展开一下，分享自己的观点。

　　数据库技术路线

　　目前国产数据库虽然很多，近300种，但是除了少数业务场景比如图、向量、时序之外，其他几乎均为关系型。由于目前关系型数据库也开始具备非关系型数据库的一些能力，大家看看Oracle 23 Ai版本就知道了，因此我们想我们探讨关系型就足够了(毕竟现在数据库国产化选型主要聚焦是在关系型数据库上）。

　　针对目前国内的上百家关系型数据库厂商，我们可以大致分为如下几类：

　　1、100% 纯自研

　　2、基于MySQL的二次开发增强（分布式也好，集中式也罢）

　　3、基于PostgreSQL的二次开发增强

　　4、以前购买了国外xxx等厂商代码授权做二次开发

　　5、另外还有一些直接套壳的数据库公司

　　实际上就上面几种情况来看，非要说哪种更好？老实说，不太好讲；但是从我们的建议来看，毕竟国产化是为了zz，那么优先考虑PG生态系列，或许会更好一点。之所以这么讲，其实无非就是一个观点：站在巨人的肩膀上。当然很多很多国产纯自研的厂商我个人也非常的佩服，但是无可厚非的是：沉淀时间还是短了一点。

　　之前有网友说说MySQL也是属于Oracle公司，也属于老美，而PostgreSQL不是，且开源协议完全不同；因此MySQL可能面临断供，而PG不会？本着好奇的心，我查了一下pg14官方公布的代码贡献者的分布，发现我们和老大哥的比例加起来也就14%左右，几乎只有漂亮guo的一半（当然这里是只是统计的人数，如果要看代码量的话，其实china是非常少的。。。）。

　　那么这个观点是否成立呢？可能就仁者见仁智者见智了，我只能说到这里。

　　不过不得不承认，这几年国内的PG社区活跃了不少，同时PG系列（或者同源）的数据库也要多很多，其中最为出名的就是openGauss系列了，作为目前国内根技术最大的数据库社区之一。

　　数据库架构

　　现在国产数据库架构归纳一下无非就如下几种。

　　1、主备（主从）架构 - 比如DM、kingbase、MogDB、Gbase 8s等

　　2、仿Oracle RAC共享存储架构（也可使用分布式存储) -如dmdcs、kingbase rac、yashanDB -Rac 等

　　3、基于MySQL的分库分表架构（比如GoldenDB、TDSQL、HotDB等）

　　4、存算分离分布式架构（TiDB、PolarDB、GaussDB等）

　　5、原生分布式架构（Oceanbase等）

　　对于分布式数据库的架构分类，实际上我认为是比较乱的，我这里就随意了；毕竟各个厂家对自己的宣传都是不太一样的，还有动不动就是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人？甚至更多？

　　我想很多数据库公司总人数都不到100人的占80%吧。

　　实际上之前某某数据库快速扩张，收割了很多客户。客户就给我反馈过，数据库原厂根本支持不了，本地一个人都没有，而且据了解，其他省项目多，本地招聘的原厂售后工程师，基本上都是安装部署，故障处理大都不会，因为很多都是刚毕业甚至毕业不久的人，总之，售后支持能力确实良莠不齐。

　　其次如果大家去看所谓的AK list会发现，有些公司，老实说我以前都没听过；突然跳出来给用户卖数据库，吹嘘自己有10多年的数据库经验，能让人信服吗。当然，也有可能是我们太孤陋寡闻了。

　　企业自身研发能力

　　为什么要讲企业自身的研发能力呢？实际上我认为，目前几乎没有哪家厂商能够做到应用代码0 修改，就能够从Oracle迁移到国产数据库。之前听说某某数据库号称99%兼容oracle；在项目poc国产中，用户的数千存储过程真的几乎0改造，就能完全移植过去。But 不幸的是，很多真的是为了兼容而兼容，不少存储过程根本跑不动；那么这部分代码就不得不进行重构。

　　因此如果企业自身的研发能力不足的话，那么指望数据库厂商来修改，我想这个难度是很大的，除非项目金额大，数据库厂商愿意不计投入。

　　根据我们这几年的国产化经验来看，如果用户自身研发能力可以跟上，那么其实就兼容性来讲，90%和95%的不兼容比例，差距并不大的。

　　另外如果你选择了分布式数据库，那么就务必要熟悉分布式数据库的一些开发规范，假设自身开发能力很弱甚至完全依靠第三方应用厂商，那么这个时候通常就会比较被动了。

　　企业自身IT运维水平

　　最后来说说用户自身的运维能力。实际上从我这些年接触的数百家用户来讲，相对来说；我认为银行、运营商、证券、保险的能力相对较强，其他行业则相对要弱得多。即使IT能力较强的用户，很多大都是依赖第三方运维，自身的IT运维能力是欠缺的。

　　由于国产数据库相比国外商业数据库的成熟时间来讲短了不少，因此在稳定性、文档、成熟度方面都有一些差距；因此用户就需要去建立自己的国产数据库运维规范，而且这个也是一个不断积累和完善的国产；毕竟很多第三方专业服务公司在这方面积累都不够，更不要说甲方用户了。

　　对于很多没有专业数据库运维团队的用户来讲，那么选择数据库可能就更应该去关注生态了，起码数据库生态繁荣，学习的人多；真要是哪天出了问题，找人也好找一点吧。