时至今日，数据库作为根底软件仍被列为制约我国工业倒退的“卡脖子”技术之一。为了攻克这个由来已久且亟需冲破的难关，数据库国产化的摸索曾经走过了十年无余。从 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 的打榜要求，并开始为此做相干储备”。这种十年磨一剑的韧性和毅力，可能就是一款国产通用数据库实现外围代替的最大底气吧。
起源：dbaplus 社群
点击进入取得更多技术信息~~