国产数据库技术如何实现“去O”

（文：国产数据库技术专家 隋景鹏）

一、甲骨文的垄断布局是如何的深谋远虑

甲骨文与IBM的数据库作为当前世界上最流行的单机数据库技术，在过去的漫长时间里都具有其技术上的先进性，和不可替代性。

但是，万事没有绝对。甲骨文也早早意识到，任何的技术的发展都要不停的迭代，以适应市场的业务需求；而纵观历史，没有一项技术能够永恒的处于垄断地位，只有不断的创新与突破才是技术发展持之以恒的道路；并且，美国不可能永远的强大和开放，总有一天，会有各种原因的“去O（去除甲骨文的Oracle数据库垄断）”出现。

所以甲骨文这家具备长远战略目光的企业，多年以前收购了MySQL（一个开源的数据库），并且一直开源运营，不计回报，早早就谋划垄断数据库市场的战略布局。甲骨文持续推进MySQL社区，其目的肯定不是给用户一种“去O”的解决方案（稍加思索，也知道他打的什么主意，肯定不是悬壶济世之情爆发，要用自家的免费产品剃掉自家的生财之道）。

甲骨文收购MySQL其目的必然是为了巩固自家商业数据库的垄断地位，并且广泛意义上它确实达到了这个目的，从两个方面我们就能够看出来。

1、MySQL斩断了市场自主研发能力，扫清甲骨文的技术威胁

Oracle作为甲骨文的商业软件，牢牢的占据数据库市场的主要地位。MySQL作为开源产品，也已经占据了数据库市场前5的份额。MySQL没有替掉Oracle之前，已经“替掉”了全球大部分技术人的自主研发能力，使任何甲骨文的潜在对手丧失了突破、创新的竞争能力；

没有突破、创新的能力，拿什么去替换Oracle？似乎就只剩下一个MySQL可选，而国内大部分数据库厂商就是这么去做的。例如某些知名的互联网厂商、科技巨头，以及大量新兴起的创业公司，都是把MySQL拿过来，通过分库分表解决方案，就“变”成自己的数据库，无异于“掩耳盗铃”。如果一直使用MySQL，那么你就永远不可能具备真正“去O”的能力，甲骨文的垄断地位从此高枕无忧。

2、“左手”换“右手”，卡脖子的还是甲骨文的“手”

MySQL去不了Oracle，因为这不是甲骨文的目的。即便有一天，某厂商用自“拿”数据库成功替换了Oracle。也不过是把曾经卡脖子的“左手”换成了“右手”，伸手卡脖子的还是那个甲骨文，这一点从MySQL的授权模式上就可以看出来。

MySQL拥有两种授权协议：

1、GPL授权协议（开源协议）

MySQL的开源协议采用GPL授权协议，即任何对采用MySQL源代码，并且进行修改的衍生产品，其代码必须开源。那么，任何以MySQL进行衍生的产品都必须将源代码开源；你的任何技术创新、代码漏洞都将暴露给甲骨文、以及任何人。如果不开源，那么将面对甲骨文强大的法务团队，可能还会包括激进的某国政府。

但是，国内这些自“拿”数据库厂商中大部分都没有进行开源的计划，是什么让他们如此自信？

无外乎两个原因：

其一，市场占有规模小，未吸引到甲骨文的注意；

其二，未修改源码，直接使用完全的开源代码，开发、优化的仅是“分库分表”解决方案的数据分发中间件，以及外围工具；不具备数据库核心研发能力，完全依赖MySQL自身的性能；而功能上，由于分库分表本身就存在诸多数据库语法使用的限制，导致整体不支持复杂SQL，多表join，分布式事务能力等，对开发、运维，以及系统稳定性带来更大的困难。

2、商业授权协议

允许使用修改开源代码，进行商用，需要购买商业授权费用，本质上与使用Oracle反而没有太大的区别，依然是受制于人。

甲骨文从发展到壮大，用事实展现了他的强大战略蓝图，与深谋远虑，如果现在还有人抱有幻想，能用MySQL实现替换Oracle，那就是罔顾现实，痴人说梦，最终受到损害的还是用户。

多年后的今天，我们看甲骨文收购MySQL这一案例，为其布局凶狠、毒辣所折服；为了保持盈利，甲骨文有一万种方式，能让用到MySQL代码的用户继续花钱，今天的韭菜，明天依然是韭菜，而且会长得更加的茂盛。

二、用什么样的数据库才能突破传统巨头的垄断

“去O”难，难于攀登“蜀道”。难道“O”就去不掉了么？当然可以去掉，如何去，用什么去，必须从业务需求角度出发去思考。

业务需求的特性是什么？

首先，需要保证现有业务的功能与稳定性，不能替换后，产生功能、性能的衰退；

其次，还要满足未来业务量、数据量不断爆发的需求。我们不能“今天”刚替换完，“明天”就遇到业务瓶颈。在这点上， Oracle这种“单机/共享存储/读写分离”架构其实也有些力不从心，这也是国产数据库为什么大都选择分布式架构的原因。

以此为参考，我们去衡量一个什么样架构的数据库才能去O！

第一，肯定不是单机的数据库

肯定不是单机/共享存储/读写分离架构的数据库，如mySQL、PG，以及国内模仿Oracle的数据库厂商产品；

原因有二：

1）模仿Oracle的架构，但功能、稳定性上比不了Oracle，支撑不了现在；

2）同样是单机架构，在移动互联网、物联网产生的海量数据、复杂计算分析场景中，满足不了未来；

第二，也不是分库分表的“分布式”

所谓“分库分表”就是当一个数据库不足以支撑业务需求时，将业务进行定制化改造，不同的业务模块由不同的数据库支撑，将一个完整的库切分为多个“库”；或者将一张表中的数据，按一定规则，分到不同的数据库中不同的表中存储。这样，一个业务系统的数据就分布在多个库、多个表中存储，一个业务系统，由多个数据库来共同支撑。

很多国产数据库厂商就是这样，以MySQL数据库为核心基础，通过“分库分表”的解决方案打包成一个完整产品，大量的互联网企业、科技巨头，都是这样去做的(此时，我们暂且忽视他们使用Mysql的风险，仅评估他的技术方案是否可行）。

由于这种架构核心数据处理能力由MySQL提供，不需要突破数据库技术门槛，所以数据库厂商的研发投入低，有更多的精力进行市场宣传。但同样的，这样的厂商对数据库基础核心架构不具备控制力，过度的依赖甲骨文技术产品将会是隐藏的巨大风险。

为什么说“分库分表”的架构不能“去O”？

以MySQL为例，它是一款单机数据库，天生的仅处理本地数据，不支持分布式事务。所以，即便是以MySQL为核心的“分布式”数据库，就连MySQL自己的功能也在这种架构中被阉割了很多；最明显的就是大量的sql语法不支持，各种子查询，多表join关联操作方式都被严格限制，甚至是像“视图”这种数据库的基本功能也不能够完全支持。那么这样一款数据库，怎么可能在普遍性业务、或者关键性核心中替换Oracle！

倘若，必须用这种数据库产品替换Oracle，那么，需要对业务应用层进行大量的改造，要把分布式事务都在应用层处理，落到数据库里面时，保证都是单机的事务。这在真实的业务场景是很难实现的，并不是说应用开发商懒惰，不愿去尝试新的应用架构。数据库的事务能力决定了数据的准确性，一致性，是用了数十年的专业研发才成熟的数据库技术，已然成为数据库技术的一种标准。如今要让这部分最难的分布式事务由应用层来做，不是不做，是真的难以做到；功能实现对于能力强大的应用开发商而言并不难，难的是各种容错机制，稳定性和准确性的保障，以及技术标准的统一，这里面的哪一项，不是数据库技术用了十几年、甚至几十年才积累到现在的成果。

那么，为什么即便是“分库分表”的诸多限制，也要用MySQL？为什么不能从底层，完全自研一款数据库，原生支持分布式事务，以及其他分布式功能呢？互联网与科技巨头们，一年挣多少钱，拿出来一部分自研数据库不行么？

事实是，还真不行。

IT技术三大核心基础为是芯片、操作系统、数据库；操作系统的制约瓶颈在于生态，需要大范围的应用去支持你（不然你开发一个系统，应用厂商开发的软件却不去支持这个系统，不能玩游戏、不能办公，那么谁还要用）。

芯片、和数据库的限制，完全就是技术门槛的限制，无论花多少钱，你也不一定做的出来；中国数据库发展了20年，还是落后20年...(但老一批厂商勇往无前，孤注一掷的精神让我们敬佩）。所以，大量不具备核心研发能力的数据库厂商，又不愿放弃这部分市场，于是就有了大量的自“拿”数据库，并且大有一种“劣币驱逐良币”的恶性生态发展趋势。试问，这么些大厂都在拿现成的东西包装一下，凭借成熟的渠道关系、大厂的宣传效应，就可以有大把的资金收入，那些辛苦自研的创业公司何以生存，国家的技术瓶颈何时可突破？难道脖子卡的久了，就卡习惯了，把“卡脖子”当围脖了么，恐怕当寒潮来临，冷暖只有用户自知。

又有人问了，MySQL都开源了，就不能学习一下么？其实这中间的道理很简单，你能看见的并不一定是你的，也不一定是你能理解的，这就是 “技术瓶颈”的所在。李白的诗大家都能读，有多少读者能成为了李白那样的诗人，又有多少人具备修改原作的能力。

信息时代，我们不能一味的追逐模仿，更不能一味的“拿来主义”，必须打破传统思维，通过技术创新手段，用新的技术架构披荆斩棘，承受痛苦才能突破限制，走别人未走的路，才能有机会真的追赶、甚至超越。

去O，用MySQL不行，分库分表的MySQL更不行。

第三，去O的唯一出路：原生HTAP融合型分布式数据库

HTAP是新型的融合型数据库技术，是与OLTP（在线交易处理）和OLAP（在线分析处理）技术对应的，能够同时支持OLTP和OLAP能力，支持在线交易与分析混合负载的数据库技术。

甲骨文数据库的发展有相当长的历史，以前企业所有的业务都放在Oracle里完成，也不分OLTP和OLAP；随着互联网的发展，为了满足高并发、大数据量的需求，Oracle采用读写分离的架构支撑高并发的交易业务，通过共享存储架构支撑数仓等大数据量的存储、分析业务。所以，严格意义上讲，Oracle就是在一定数据量（TB）以内的HTAP融合型数据库。

随着互联网、移动支付、5G技术的发展，面对海量且复杂的大数据业务场景，Oracle也开始表现不佳。为了争抢数据库市场，在不同的业务领域里，出现不同的Oracle替代方案。例如，在分析型领域，出现的MPP、Hadoop大数据等分布式架构；在交易领域里，通过瘦核心、读写分离等解决方案减轻核心系统压力；在海量存储等更细分的领域还有大量的Nosql数据库。但在所有的替换方案中，还没有一款数据库能在全业务场景中替换Oracle，能够替换Oracle的必然也得是一款在全业务场景中都能表现不错的HTAP数据库。

近年来，HTAP技术在数据库领域中被广泛提起，实现的方式也是五花八门，主要思路就是通过多种计算引擎技术混合在一起，实现TP和AP的同时支持，基本还是用分库分表的MySQL做事务处理，然后用开源的Spark SQL进行并行计算分析，形成了这种概念上的HTAP，而非技术上的HTAP能力。

原生分布式数据库，是与分库分表这种解决方案相区分的一种技术。是通过完全自主研发，不以任何开源技术为基础，从设计之初就是为了解决海量且复杂计算分析设计的分布式架构，去除了集群内部独立个体概念，完全扁平化设计，任何节点的角色功能都是一致的，对应用完全透明，所有节点统一在一起作为一个完整的数据库。

易鲸捷数据库是目前唯一一款通过原生分布式架构设计在技术上实现HTAP融合能力，通过一个计算引擎，同时支撑TP和AP能力的数据库。这完全有赖于易鲸捷研发团队在世界顶级数据库核心研发领域超过30年的技术沉淀与积累，最终凝聚成易鲸捷今日的技术成果。

原生分布式数据库技术是实现HTAP技术的关键，而原生分布式HTAP数据库是实现“去O”的唯一可行路径。其主要原因有以下：

1，功能不减，满足现状；可扩展性，支撑未来

分布式数据库处理分布式事务的性能损耗是必然的，在小数据量场景中难以超越、甚至达到Oracle的性能是一个不争的事实。

但，易鲸捷数据库与Oracle之间的差距是微弱的，毫秒之间，是用户难以感知的；易鲸捷通过分布式并行计算、负载均衡，以及分布式扩展性等技术的实现，保证在高并发操作时，其差距依然在可控范围内，在小数据量场景也能满足用户的性能需求。

同时，易鲸捷数据库通过原生的分布式技术，以技术创新为手段，以满足未来业务需求为目标，在互联网、移动支付、5G业务场景，在Oracle也不能支撑的海量且复杂的大数据场景进行突破，甚至能够超越Oracle，给用户带来惊艳的感受。

2，真正做到自主研发、自主创新，不受技术卡脖子

不与任何海外巨头产生知识产权交叉，每一行代码都是研发团队自己的知识沉淀，具有完全的掌控能力，以及优化能力，是真正自由的数据库产品。能够在未来，不断的随着市场需求变化，自由的进行迭代升级，让用户的业务系统不在受到限制。

作为原生分布式数据库技术自主研发厂商，时刻都要面对着巨大的挑战：如何在各大、小厂商以“快利”为目的，通过 “拿来”技术，逐渐筑成的“劣币驱逐良币”恶性市场环境中突出重围；如何坚定不移的，对自主技术创新与突破保持不断的研发投入。

数年来，易鲸捷在深耕数据库技术瓶颈的突破中沉淀自己，不让浮躁的市场环境影响自主研发的步伐，对中国数据库市场整体向好、向强报以坚定的信心，易鲸捷一定会为了中国数据库技术实现自主创新贡献自己的全部力量。

---

更多文章请关注

免费下载资料

关注本公众号，在对话框：

回复“工业软件”，下载《工业软件：研究框架》PDF原文；

回复“图谱”，下载《中国长城网信产业生态图谱》全文PDF；

回复“数字经济”，下载《中国数字经济发展白皮书（2020年）》；回复“电子政务”，下载《国家电子政务标准体系建设指南》；回复“管理模板”，下载《华为项目管理10大模板Excel版(可直接套用)》；回复“0612”，下载《湛江市公安大数据智能化建设项目招标文件电子版》；回复“昆明新基建”，下载《下载昆明新基建项目投资清单》；回复“大数据”，下载《埃森哲大数据分析方法及工具应用；回复“政务云”，下载完整版《重庆市政务云招标书》；回复“定级指南”，下载《信息安全技术 网络安全等级保护定级指南》;回复"政策“，下载《新基建政策白皮书》；回复"新基建“，下载《新基建产品手册》。

温馨提示

如果你喜欢本文，请分享到朋友圈，想要获得更多相关资料，请关注“信创工程咨询”。我们的推送时间是18：00或24：00，一定不要忘了给“信创工程咨询”设星标哦！获取投稿或入群方式， 请在公众号对话框回复“投稿”或“入群”获取！

相关阅读

---