作者：易鲸捷信息技术有限公司 金融事业部售前总监 隋景鹏
一、甲骨文的垄断布局是如何的深谋远虑
甲骨文与IBM的数据库作为当前世界上最流行的单机数据库技术，在过去的漫长时间里都具有其技术上的先进性，和不可替代性。
但是，万事没有绝对。甲骨文也早早意识到，任何技术的发展都要不停的迭代，以适应市场的业务需求；而纵观历史，没有一项技术能够永恒的处于垄断地位，只有不断的创新与突破才是技术发展持之以恒的道路；并且，美国不可能永远强大和开放，总有一天，会有各种原因的“去O（去除甲骨文的Oracle数据库垄断）”出现。
所以甲骨文这家具备长远战略目光的企业，多年以前收购了Mysql（一个开源的数据库），并且一直开源运营，不计回报，早早就谋划垄断数据库市场的战略布局。甲骨文持续推进Mysql社区，其目的肯定不是给用户一种“去O”的解决方案（稍加思索，也知道他打的什么主意，肯定不是悬壶济世之情爆发，要用自家的免费产品剃掉自家的生财之道）。
甲骨文收购Mysql其目的必然是为了巩固自家商业数据库的垄断地位，并且广泛意义上它确实达到了这个目的，从两个方面我们就能够看出来。
一、Mysql斩断了市场自主研发能力，扫清甲骨文的技术威胁。
Oracle作为甲骨文的商业软件，牢牢的占据数据库市场的主要地位。Mysql作为开源产品，也已经占据了数据库市场前5的份额。Mysql没有替掉Oracle之前，已经“替掉”了全球大部分技术人的自主研发能力，使任何甲骨文的潜在对手丧失了突破、创新的竞争能力。
没有突破、创新的能力，拿什么去替换Oracle？似乎就只剩下一个Mysql可选，而国内大部分数据库厂商就是这么去做的。例如某些知名的互联网厂商、科技巨头，以及大量新兴起的创业公司，都是把MySQL拿过来，通过分库分表解决方案或者“代码重构”（用其他编程语言翻译一遍Mysql代码），就“变”成自己的数据库，无异于“掩耳盗铃”。如果一直使用Mysql ，那么你就永远不可能具备真正“去O”的能力，甲骨文的垄断地位从此高枕无忧。
二、“左手”换“右手”，卡脖子的还是甲骨文的“手”。
Mysql去不了Oracle，因为这不是甲骨文的目的。即便有一天，某厂商用自“拿”数据库成功替换了Oracle。也不过是把曾经卡脖子的“左手”换成了“右手”，伸手卡脖子的还是那个甲骨文，这一点从Mysql的授权模式上就可以看出来。
MySQL拥有两种授权协议：
1、GPL授权协议（开源协议）。
Mysql的开源协议采用GPL授权协议，即任何对采用MySQL源代码，并且进行修改的衍生产品，其代码必须开源。那么，任何以Mysql进行衍生的产品都必须将源代码开放、暴露给甲骨文、以及心怀不轨的任何人，而这些人可以凭借在数据库行业里更丰富的经验，更加容易的发现产品漏斗加以利用，威胁我们的信息技术安全。如果不开源，那么科技公司与用户都将面临甲骨文强大法务团队的控诉，甚至这会成为激进组织攻击、抹黑国家形象的工具。
即便如此，依然有很多自“拿”数据库厂商没有考虑开源计划，那么是什么让他们如此狂妄自信？
无外乎两个原因：
其一，觉得自己市场占有规模小，不会吸引到甲骨文的注意；
其二，未修改Mysql源码，而是开发一种 “分库分表”的数据分发中间件，以及数据库相关外围工具，然后直接采用Mysql作为底层基础库，以此解决方案绕过Mysql开源协议限制。因不进行数据库核心技术研发投入，完全依赖Mysql自身的性能，这样的产品功能上，存在诸多SQL语法使用的限制，不支持复杂计算任务、多表join、分布式事务能力等，对业务系统开发、运维，以及系统稳定性带来更大的困难。
2、商业授权协议。
允许使用修改开源代码，进行商用，需要购买商业授权费用，本质上与使用Oracle没有太大的区别，依然是受制于人。
甲骨文从发展到壮大，用事实展现了他的强大战略蓝图，与深谋远虑，如果现在还有人抱有幻想，能用Mysql实现替换Oracle，那就是罔顾现实，痴人说梦，最终受到损害的还是用户。
多年后的今天，我们看甲骨文收购Mysql这一案例，为其布局凶狠、毒辣所折服；为了保持盈利，甲骨文有一万种方式，能让用到Mysql代码的用户继续花钱（今天的韭菜，明天依然是韭菜，而且是长得更加茂盛的韭菜）。
二、用什么样的数据库才能突破传统巨头的垄断
“去O”难，难于攀登“蜀道”。难道“O”就去不掉了么？当然可以去掉，如何去，用什么去，必须从业务需求角度出发去思考。
业务需求的特性是什么？
首先，需要保证现有业务的功能与稳定性，不能替换后，产生功能、性能的严重衰退；
其次，还要满足未来业务量、数据量不断爆发的需求。我们不能“今天”刚替换完，“明天”就遇到业务瓶颈。在这点上， Oracle这种“单机/共享存储/读写分离”架构其实也有些力不从心，这也是国产数据库为什么大都选择分布式架构的原因。
以此为参考，我们去衡量一个什么样架构的数据库才能去O！
第一，肯定不是单机的数据库
肯定不是单机/共享存储/读写分离架构的数据库，如mysql、pg，以及其他模仿Oracle的数据库产品；
原因有二：
1）模仿Oracle的架构，但功能、稳定性上远比不了Oracle，支撑不了现在；
2）同样是单机架构，在移动互联网、、移动支付、5G、物联网产生的海量数据、复杂计算分析场景中，满足不了未来；
第二，也不是分库分表的“伪分布式”
所谓“分库分表”就是当一个数据库不足以支撑业务需求时，将业务进行定制化改造，不同的业务模块由不同的数据库支撑，将一个完整的库切分为多个“库”；或者将一张表中的数据，按一定规则，分到不同的数据库中不同的表中存储。这样，一个业务系统的数据就分布在多个库、多个表中存储，一个业务系统，由多个数据库来共同支撑。
很多数据库厂商就是这样，以MySQL数据库为核心基础，通过“分库分表”的解决方案打包成一个完整产品，这其中包括知名互联网企业、科技巨头，都是这样去做的。此时，我们暂且忽视他们使用Mysql的风险，仅评估他的技术方案是否可行。由于这种架构核心数据处理能力由Mysql提供，不需要突破数据库技术门槛，所以数据库厂商的研发投入低，有更多的精力进行市场宣传。但同样的，这样的厂商对数据库基础核心架构不具备控制力，过度的依赖甲骨文技术产品将会是隐藏的巨大风险。
为什么说“分库分表”的架构不能“去O”？
以Mysql为例，它是一款单机数据库，天生的仅处理本地数据，不支持分布式事务。所以，即便是以Mysql为核心的“分布式”数据库，就连Mysql自己的功能也在这种架构中被阉割了很多；最明显的就是大量的sql语法不支持，各种子查询，多表join关联操作方式都被严格限制，甚至是像“视图”这种数据库的基本功能也不能够完全支持；并且一些厂商研发能力有限，还需要应用系统每次写数据时指定MySQL服务节点。那么这样一款数据库，怎么可能在普遍性业务、或者关键性核心中替换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技术的关键，而原生分布式HTAP数据库是实现“去O”的唯一可行路径。其主要原因有以下：
1，功能不减，满足现状；可扩展性，支撑未来。
由于原生分布式数据库从设计上就以分布式架构为初衷，从功能上，不受单机数据库改造的技术限制，能够更方便的实现Oracle等数据库功能的兼容。
从性能角度看，分布式数据库处理分布式事务的性能损耗是必然的，在小数据量场景中难以超越、甚至达到Oracle的水平是一个不争的事实。
但，只要不断的研发投入、优化，原生分布式数据库与Oracle之间的差距其实是微弱的，毫秒之间，是用户难以感知的；并且通过分布式并行计算、负载均衡，以及分布式扩展性等技术的实现，保证在高并发操作时，其差距依然在可控范围内，在小数据量场景也能满足用户的性能需求。
同时，原生的分布式数据库，以技术创新为手段，以满足未来业务需求为目标，在互联网、移动支付、5G业务场景，在Oracle也不能支撑的海量且复杂的大数据场景进行突破，甚至能够超越Oracle，给用户带来惊艳的感受。
2，真正做到自主研发、自主创新，不受技术卡脖子。
不与任何海外巨头产生知识产权交叉，每一行代码都是研发团队自己的知识沉淀，具有完全的掌控能力，以及优化能力，是真正自由的数据库产品；即便采用开源技术为基础，也可以选择BSD和APACHE这种更灵活，可控性更强的开源协议技术，绝不能采用GPL完全不可控高风险协议的Mysql技术。能够在未来，不断的随着市场需求变化，自由的进行迭代升级，让用户的业务不受到技术授权限制。
数年来，国产数据库在飞速发展，很重要的原因是得益于国家对基础软件技术创新的大力支持。同时，国内基础技术的研发企业，受到互联网“快利”思潮的吸引和冲击，存在严重的浮躁情绪；大量厂商投身到“拿来主义”，并且止步于“拿来”，这中间不乏互联网、科技行业等龙头企业。
作为原生分布式数据库技术自主研发厂商，反而夹缝中求生存，时刻都要面对着巨大的挑战：如何在各大、小厂商以“快利”为目的，通过 “拿来”技术，并且已经初步形成的“劣币驱逐良币”恶性市场环境中突出重围；如何坚定不移的，对自主技术创新与突破保持不断的研发投入。
我们想要突破海外巨头的垄断地位，恐怕是这个世纪最具挑战性的任务之一，既要面对国外巨头的技术封锁，还要应对国内市场环境的挤压。11年前甲骨文就已经为今天的结果布局，这11年间里，他还为我们设下了哪些困局，而我们将如何破局？
继续依赖甲骨文的产品、技术，无异与狼共舞、与虎谋皮。原生分布式数据库厂商是否能够突破甲骨文设好的重重困局，而实现基础技术的自主创新，最大的影响因素是中国这个市场环境，是否真的发自内心的想要突破海外垄断，并为之进行长期付出做好准备！
自主创新的路是艰巨的，但我们要相信这条路的必要性和技术人实现这一目标的决心。最后，作为一名数据库技术爱好者，希望我们的数据库厂商在深耕基础技术中沉淀自己，不要让浮躁的市场环境影响自主研发的步伐与信心，打造出更好、更先进的数据库产品，同时也希望越来越多的数据库爱好者、产业链生态伙伴和使用者都能积极参与到对我们自主技术的维护与尝试中。
