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

? ? ? 对于数据库国产化这个话题，最近几年十分火爆，因此这几年诞生了数百家数据库厂商，因此这个话题似乎再怎么谈都不过时。实际上对于数据库的替代，最早是阿里提出的去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全球的业务提供了很好的后端支撑。

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

? ? 罗马也不是一天建成的！

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