时至今日，数据库作为基础软件仍被列为制约我国工业发展的“卡脖子”技术之一。为了攻克这个由来已久且亟需突破的难关，数据库国产化的探索已经走过了十年有余。从2008年阿里提出“去IOE”到国产数据库百花齐放、逐步应用于核心业务系统的当下，也许就如同OceanBase CTO杨传辉所言，“大多数人看到的只是结果，看不到的是一朝变现的十年积累”。

 

这些积累，让越来越多的国产数据库开始直面以Oracle为代表的国外商业数据库。虽然在单机性能、优化器、复杂查询处理等能力上相对Oracle还有一定差距，但通过分布式的技术架构，不少国产数据库在海量并发下表现出了更优于Oracle的扩展性和高可用，并以HTAP为突破口，向Oracle发出了新一轮的挑战。

 

从怀疑到相信，数据库国产化走了十年，那么从相信到完成核心替代，国产数据库还有多长的路要走？dbaplus社群联合发起人、新炬网络董事/副总经理程永新于2021 DAMS中国数据智能管理峰会上，同期对话OceanBase CTO杨传辉，和大家一起关注目前国产数据库在技术和生态上的优劣，并基于核心替代的用户需求和考量，找准优化提升的发力点。

 

新 创 访 谈

 

 

OceanBase CTO杨传辉接受dbaplus社群联合发起人、新炬网络董事/副总经理程永新采访

 

受访嘉宾：杨传辉（上图左），花名日照，OceanBase创始成员&CTO，主导了OceanBase技术架构设计，实现分布式数据库在核心金融场景零的突破。同时也主导了OceanBase TPC-C测试并打破世界纪录。著有专著《大规模分布式存储系统：原理与实践》。

 

采访者：程永新（上图右），dbaplus社群联合发起人，新炬网络董事/副总经理，拥有超过20年IT行业管理经验，计算机本科、硕士研究生及香港科大EMBA。

 

 

 

 

数据库自研的底气与考量

 

从怀疑到相信，缺乏的已不是核心技术，

而是“先吃螃蟹”的驱动力

 

程永新：10年前，OceanBase破壁而生，同时也成为了数据库国产化的倡导者。在您看来，这10年里，随着国产数据库的百花齐放，国内对国产数据库替代Oracle所持态度有了怎样的改变？

 

杨传辉：这几年我觉得企业对国产数据库替代Oracle的态度有了明显改变，企业界对开源的态度也有了很大不同。之前大家对这件事是怀疑居多，比如说Oracle具备但国产数据库不具备的功能、Oracle做得很成熟但国产数据库并不完善等等；到了今天，大家已经逐渐由怀疑转变为相信，相信国产数据库替代Oracle大概率是能成的，只是还需要时间，主要原因有二：

 

一、整个国产数据库行业已经基本具备了核心技术，包括OceanBase登顶了TPC-C，其它国产数据库也在很多场景、甚至是比较核心的场景打磨上有了很大提升，不管是在哪个行业都或多或少有了一些成功案例。

 

二、国家的推动，国家近年来陆续出台了自上而下的行业政策，在国家政策的支持下，信息技术国产化替代是大势所趋。

 

程永新：根据你们的市场调研和服务经验，目前数据库国产化的进展如何？可以真正做到核心系统替换的比例有多少？

 

杨传辉：我个人认为数据库国产化可以分成两个阶段：

 

第一阶段，国产数据库需初步具备产品技术的能力，也就是要先具备核心技术，并且在某些特定场景上具有成功案例。目前各家国产数据库在一些核心场景上已经有了不少成功案例，所以我觉得第一阶段基本算是完成了。

 

第二阶段，国产数据库能真正实现商业化，能够通用地推广到所有行业，这个阶段目前仅仅只是刚开始。

 

以对数据库要求最高的金融行业为例，金融机构里大致可分成三种类型的系统：第一类是外围系统，比如办公系统。这类系统目前替换Oracle的进展很快，相信不需要很长时间都会被替换掉；第二类是一般的核心系统；第三类是最核心的交易、支付、账务等跟钱有关的系统，以及跟社会正常运转有关的系统。目前第二类和第三类系统的替换仍处于早期阶段，比例大概在10%-20%之间的程度。

 

程永新：多数企业对替换Oracle还有哪些技术层面和非技术层面的考量？

 

杨传辉：这个问题我们可以从数据库替换的两大挑战来看：

 

第一个是稳定性的挑战，因为Oracle主要用在交易类场景，企业要换其它数据库尤其是OLTP数据库，是一个非常慎重的决策，哪怕出一点点问题，都会牵连到整个业务，所以大家有很多稳定性的担忧，需要长时间打磨、尝试灰度后再慢慢替换掉。

 

第二个挑战在于OLTP型的数据库跟业务之间的关联度较弱，比如做一些偏AI的数字化项目，能产生多大的业务价值往往是显而易见的，因此企业采用新技术去完成的主动性会比较强。而对于替换数据库这种项目，考虑得更多的是降低成本，但众所周知Oracle的盗版比较多，在应用了盗版的情况下，企业主动更换数据库的意愿相对来说就比较低。所以行业的相关政策将会起到很关键的作用，因为大家其实都接受了数据库国产化这个趋势，只是比较缺乏“先吃螃蟹”的驱动力。

 

程永新：Oracle的优化器能力和软硬一体机方案这两大优势目前仍走在国内外数据库厂商前列，这也是很多企业无法轻易替换Oracle的重要考量。您认为目前OceanBase在这两方面有哪些优劣势？未来应该如何补齐短板？

 

杨传辉：首先关于优化器能力，OceanBase优化器的框架其实和Oracle有点类似，但我们的强项在于扩展性比较好，无论是10台机器、100台机器，还是1000台机，我们都能扩展，而Oracle并没有考虑这方面的设计。不过OceanBase优化器对复杂应用场景的适配还需要不断打磨。比如在CRM、ERP这些对优化器挑战比较高的场景，OceanBase相对于Oracle还是有差距的。

 

另外关于软硬一体机方案，其实OceanBase也有一体机的模式，但不是我们的重点，而且我们跟Oracle的逻辑不太一样。Oracle软硬件结合的方案，是融到它的内核设计里的，很多方案想做到高效其实要依赖于硬件。但OceanBase的内核是架设在普通PC服务器之上的分布式架构，对硬件基本没有太大依赖，所以理论上我们只是卖一个软件，但为了适应部分行业客户的需求我们也有一体机。

 

程永新：现在国产数据库产品种类繁多，其中基于开源做二次开发的思路也非常普遍，在这种情况下，您觉得对标Oracle难在哪里？

 

杨传辉：以前的集中式数据库可以分为开源数据库和商业数据库两种类型。开源数据库处理简单查询的能力并不弱，但Oracle这样的商业数据库除了能处理简单查询，还能处理更加复杂的甚至是一部分OLAP类的查询，所以本质上Oracle是在一个集中式架构下实现了HTAP的混合负载处理。

 

这种复杂查询的能力就是开源数据库与Oracle之间存在的最大差距。从内核的角度来看，今天的国产数据库不少都是基于开源数据库做的二次开发，这会存在一个较大的问题：如果企业后期想增加更多能力，尤其是涉及到复杂查询这种要改动内核的能力，这类数据库基本上是无能为力的。

 

所以想要对标Oracle，首先要能处理复杂的查询、能支撑内核的修改，这就需要具备自研可控的能力。另外还需要有兜底的自信，很多国产数据库厂商都问过我们OceanBase敢不敢做核心业务，我说肯定敢做，因为我们有兜底的能力。这么多年来，OceanBase在行业内做核心业务的过程中也遇到过一些问题，但基本上都能在很短时间内解决，我们给客户的承诺是没有解决不了的问题。

 

还有很重要的一点，已经发展几十年的Oracle单机性能非常出色，这是刚起步不久的国产数据库目前无法超越的，还需要花长时间并通过众多业务场景打磨来优化，在此过程中就需要用到分布式架构，原因有二：一是能在短期内弥补自身单机性能的不足，二是从长远来看能享受分布式带来的高可用、可扩展的技术红利。当你具备了原生分布式架构的能力，既能通过分布式架构把Oracle替代掉，又能把单机性能优化上来，也就是在一套系统里既能做集中式处理，又能做分布式处理，这将会是非常有前景的事情，我认为这种集中式与分布式的一体化设计才是未来。

 

分布式的疑虑与HTAP的上下求索

 

追求快速且可持续发展的企业，

最终都会走向数据库一体化架构

 

程永新：鉴于现在大家普遍都意识到分布式是大势所趋，什么都想往这个方向靠真的合适吗？您觉得对于企业选型来说，什么情况下更适合用分布式数据库？

 

杨传辉：目前市面上有很多分布式数据库，走的路线也不尽相同，我觉得大家首先应该辨认清楚什么样的分布式数据库才能真正迎合未来的发展，这就要从分布式数据库经历的三代演变说起：

 

第一代NoSQL系统，毫无疑问是无法代表未来的；第二代可扩展的SQL处理，牺牲了单机性能、成本和安全等企业级特性，注定无法支持核心场景；第三代其实就是我前面提到的集中式与分布式的一体化设计，既具备分布式的优势，又兼备单机的性能和功能。当数据量较小的时候，它的运行逻辑、使用方法、运维方式，都跟单机类似，数据量变大时又具备扩展能力，我认为这样的一体化架构才真正代表未来。

 

那么回到选型的话题，对于考虑选用可扩展性数据库方案的企业来说，他们多数都有数字化转型、推动业务更快速发展等需求，这类企业做数据库选型时，其实不必纠结到底该选集中式还是分布式，而是应该选一体化。相反，如果企业只需要持续做好传统业务，不会有分布式的需求，也就没有必要强制去换一个分布式系统。所以我的观点是，想追求快速发展的企业，最终都会走上一体化的架构。

 

程永新：您觉得相对于传统数据库，分布式数据库的运维成本和管理成本到底是升了还是降了？

 

杨传辉：如果企业本身数据量较小，却硬要做分布式的方案，那成本肯定会变高，但如果是做一体化的架构，成本其实没有太大变化。

 

而对于数据量特别大、管理很复杂的企业来说，会有两种选择，一种是用原生分布式，另外一种是用分库分表。两种选择对比来看，原生分布式的运维复杂度会远远低于分库分表。以蚂蚁集团为例，我们在双11做弹性，需要在云上加减很多服务器，实现快速扩缩容，整个过程要做几十万次的变更操作。以前我们用分库分表的方案，基本是没办法做成自动化的，后来用了原生分布式，几乎所有操作全自动化，最终能做到几千台服务器的分布式集群只要一个点击就可完成。

 

程永新：这么看来，运维成本确实下降了很多。

 

杨传辉：是的，不过还是需要有一个循序渐进的过程，企业刚开始不熟悉分布式的时候，可能会觉得运维和管理成本比集中式要高，因为分布式的门槛比集中式高很多，前期要学习很多分布式的新东西。

 

程永新：分布式带来的优势无疑是巨大的，比方说可以做到两地三中心、三地五中心这样的异地多活解决方案，能否在你们实际案例中列举一个比较好的例子？

 

杨传辉：OceanBase应用于金融、电信运营商这些行业的核心场景里，都是用RPO=0的无损容灾技术，其中最大的部署是蚂蚁集团，目前是三地五中心的部署。刚开始蚂蚁集团是部署在杭州的，自从2015年发生了光纤被挖断的事件后，蚂蚁集团意识到同城的风险，认为要变成一个三地五中心的架构才能彻底解决高可用的问题。

 

我们以银行为例，以前IBM推广的一个架构也叫两地三中心，对同城的进行热备，对异地的进行冷备，但是以前DB2推广的基于大机的两地三中心，其同城的热备和异地的冷备其实都是不一致的，所以以前的银行系统里如果主库宕掉了，备库是不敢拉起来的，这样就会丢数据。某大型银行的大机就曾经出现过故障，最终结果是银行服务停掉，然后等，因为不知道丢了多少数据，没人敢下决策。

 

程永新：真正的双活或多活，确实是分布式数据库最大的优势，因为像Oracle和DB2这种传统数据库，其实很难做到主节点宕掉之后，备节点可以实时接管业务，这个压力是非常大的。

 

杨传辉：是的，所以OceanBase在工商银行里做的对公理财业务用的就是两地三中心RPO=0的部署，当主库宕了之后备库可以随时拉起来。

 

程永新：从TPC-C和TPC-H榜单确立的领先地位，不难看出OceanBase在OLTP和OLAP上都达到了一定高度，也表现出OceanBase在两者融合的HTAP上发力的决心。HTAP真的可以做到鱼与熊掌皆可兼得吗？

 

杨传辉：HTAP是指在一套系统里既做好OLTP，又做好OLAP，从理论上来讲，其实很难把两种东西都做到极致。以OceanBase的HTAP为例，我们引入了分布式架构，具备了扩展性、高可用等能力，但目前在复杂查询的能力上相比Oracle还有一定差距，很多时候这并不是理论上的差距，而是工程实现上的差距。所以我认为，我们现在还不到去抠最后一点理论差距的时候，而是需要把更多时间和精力放在自身工程细节的打磨上。

 

最终，如果你的HTAP能在OLTP上做得跟Oracle旗鼓相当，在OLAP上也能做到与纯粹的OLAP系统达到90%以上的接近，能把工程细节做到这种程度的话，其实已经对绝大部分场景非常友好了。对于用户而言，面对一些复杂OLAP，他在那一点点的极致与复杂性上会怎么选择？我认为大多数用户主要还是看重便捷，只有少数用户比如说需要全公司跑个数仓，才会真的要追求那么一点点的极致。

 

程永新：您觉得OceanBase的HTAP与其它国产数据库的HTAP相比有哪些差异？

 

杨传辉：OceanBase的HTAP其实有点像是具有扩展性的Oracle。OceanBase的HTAP是一个能做核心OLTP的HTAP，这是目前大多数HTAP还做不到的。因为它们一开始并没有采用一体化架构，而是用了分离架构，只能处理外围场景的分布式需求。

 

而OceanBase既能应用于外围场景，也能应用于核心场景，可以说OceanBase是目前唯一一款能够应用于核心场景的原生分布式数据库，在交易、支付、账务这些核心业务上我们都有真实的案例，而且基本上没有做太大的改造。

 

开源的真材实料与真心实意

 

核心代码开源，重投入社区运营，

生态建设立下大决心

 

程永新：OceanBase开源不久就受到了很大关注，目前用户接受程度和反馈如何？

 

杨传辉：一个产品能不能成为一个顶尖的开源项目，我觉得最核心在于它本身是不是一个顶尖的好产品，而不是它开源了。

 

OceanBase经过十几年的发展，无论是在TPC-C上打榜、在蚂蚁集团的应用，还是在很多关键行业的落地都积累了比较高的知名度。正因为有这样的基础，OceanBase在开源第一天，社区就吸引了将近3000个关注，经过5个多月的持续更新改进，目前OceanBase社区共吸引了全球21000多位用户，200多位开发者，产生了500 Commit代码提交，超过50家企业深度实践。

 

对于这次开源，我们抱着非常大的决心，是真的把核心代码开源出来了，所以OceanBase在MySQL兼容这块是全部开源的，并没有遮遮掩掩。但作为一家商业公司，我们也考虑到开源一定要和商业融合在一起，才能持续做下去。当想清楚了这两点之后，我们一年之内就投入了几十人，连技术布道师都参与到社区运营当中，这种规模可以说是重投入了。

 

程永新：简单总结就是，OceanBase的开源版本和企业版本，其实是一套内核，内核中for MySQL的一整条线全部开源了，只是企业版本里for Oracle的那条线没有开源对吧？

 

杨传辉：是的，因为for Oracle那条线会涉及到Oracle的兼容性，以及Oracle的功能，所以是不开源的。

 

程永新：会不会担心别人拿你们的核心代码改造出另一个OceanBase？

 

杨传辉：我们不怕。因为数据库的研发需要经过长时间积累而成，而且既然做了开源这个选择，就意味着这个开源社区不会被OceanBase一家公司完全掌控。但因为我们在其中是投入最多的，而且我不认为还会有其它公司能够像我们一样重投入去维护，所以我们还是很有底气的。

 

程永新：您认为OceanBase要成为一款通用的可完成核心替代的数据库，还有多长的路要走？将重点在哪些方面发力？

 

杨传辉：我对国产化核心替代抱有非常乐观的态度。这几年，我们都看到数据库这个行业的变化特别快，如果回到5年前，核心替代是大家想都不敢想的事，那么未来5年等我们再回过头看现在，可能就会发现没什么是替代不了的。

 

在我看来，我们目前只在极少数的核心场景中相比Oracle业务需求还有一些差距，比如说在数据量大且查询复杂的运营商CRM系统。所以我们还需要在复杂SQL上继续完善和突破，除此之外其实在稳定性、扩展性、高并发等能力上都已经具备了。

 

另外，目前国产数据库都缺少的是案例，有了越来越多的案例就会有越来越多的DBA和开发者进入这个生态，慢慢的整个生态就可以做起来。

 

程永新：现在越来越多国产软件加入到开源的生态里，您觉得有什么利弊吗？或者说对国产数据库行业的推动作用大吗？

 

杨传辉：国产数据库其实有两类，一类是自研，一类是基于开源做二次开发。比如一款基于MySQL做二次开发的数据库，尽管会进行国产化的改动，但不管它开不开源，本质还是MySQL大生态的一部分，这样就会面临一个问题：当MySQL原生版本更新、功能改变之后，这款基于MySQL旧版本改造的数据库，有可能就无法与新版本匹配，导致很多使用上的困难。所以，这类数据库要解决的是怎么让用户进入它特有的生态，而不是依旧停留在MySQL的生态里。

 

OceanBase则属于自研类国产数据库，我们从0到1打造了一个独立于MySQL和PostgreSQL以外的第三个生态，所以和二次开发类数据库的性质是不太一样的。但是当大家都以不同形式加入到整个开源生态里，竞争也好协同也好，都会对国产数据库行业产生很大的推动作用。

 

专访后记

 

在本次专访过程中，让人印象深刻的，是杨传辉提到OceanBase在短时间内多次刷榜并登顶TPC-C和TPC-H的从容，他说，“OceanBase虽然从2019年才开始打榜，但其实我们在做这款数据库的第一天，就看过TPC-C的打榜要求，并开始为此做相关储备”。这种十年磨一剑的韧性和毅力，可能就是一款国产通用数据库实现核心替代的最大底气吧。