阿里是如何去“O”的？

大家好，我是老猫，猫头鹰的“猫”。

今天我们来聊聊数据库这个话题。

2009年，阿里提出“去IOE化”的概念，这在当时看起来是天方夜谭，但目前来看可以说是"轻舟已过万重山"。

IOE是传统IT三大件，指以IBM、Oracle、EMC为代表的小型机、集中式数据库和高端存储的技术架构。

今天我们不聊了去"IOE"，我们想聊聊阿里是如何去"O"的？

▉ "O"为什么一定要去？

我们都知道，去"IOE"的一个重要考虑是信息安全，但是抛去这个信息安全，其实随着互联网基础架构的发展，也需要传统的集中式"O"作出改变。

其实，互联网架构的演变都符合一个趋势--基本都是从最容易的、相对无状态的应用层开始做起。因为瓶颈出现以后，应用层是最容易改造的，面对更多的需求，更多的数据，更快的迭代速度。

一般情况下，应用层的解题思路就是从单体应用走向服务化拆分，再慢慢向云原生化演进，由于应用大部分是无状态的，这样整个演进的风险是相对可控的。

随着业务的发展，架构的压力很快从应用层传导到了 IaaS 层，涉及到芯片、存储、服务器等，这些最底层 IaaS 虽然是有状态的，存储着关键的数据，但都离业务比较远，跟 PaaS 相比，跟应用间的关系更加弱耦合，基本都是通过标准接口进行交互，而且云和新的存储、芯片和网络层的发展并没有太多改变标准。所以，在数字化转型过程中，这一层基本能够在不影响上层业务的同时，相对"透明无感"升级到云底座，换上自主可控的芯片和服务器，为上层提供更强大的弹性算力和更高资源利用率的虚拟化能力。

当 SaaS 层或者说应用层改变了，IaaS 层也升级了，剩下最难啃的骨头就在 PaaS 了，这一层的基础设施既与业务相关，又是有状态的，往上需要承接应用层分拆后的分布式化的数据通讯和运维管控，往下有云底座后需要适配云原生方向发展。

而 PaaS 层中最难升级就是数据库，无论是与应用的耦合度还是状态数据的重要性，都给架构升级带来了巨大挑战。

举个例子，随着互联网的发展，现代应用处理的数据量更大，也会经常面对脉冲业务的冲击，应用架构通过服务化架构和容器技术具备了更大的数据处理能力和弹性伸缩能力，从而间接要求数据库具备海量数据处理能力和弹性伸缩能力，同时业务的分布式和垂直拆分会要求数据库也是分布式的，但分布式有状态数据如何保证一致性，又如何应对大量数据库实例管理的复杂度，这在传统集中式数据库的架构上是极大的挑战。

另外，在分布式架构下 PC Server 的可靠性降低但数量变多，这"一降一多"极大的放大故障概率，而现代应用需要提供在线服务，对业务连续的要求只会变得更高，传统数据库依赖特定的高可用硬件来应对可靠性要求的方案已经难以为继。

所有这些新的问题表明，互联网时代的架构已经无法用传统的数据架构和思路来解决这些新问题了。如果还是治标不治本，通过外挂或者各种外部软件和数据库软件拼装组合的方式来应对这些复杂问题，只会让复杂度和风险变得更高。

因此，要构建现代应用架构的摩天大厦必须彻底重构数据架构的地基。

▉ 互联网浪潮 催生原生分布式数据库

数据库系统的萌芽出现于20世纪60年代。当时计算机开始广泛地应用于数据管理，对数据的共享提出了越来越高的要求。传统的文件系统已经不能满足人们的需要。能够统一管理和共享数据的数据库管理系统（DBMS）应运而生。

随着关系模型有了完善的理论支撑后，以Oracle、DB2到SQL Server为代表的数据库开始在各大企业中应用，商业数据库迎来了第一波高速发展。

但关系数据库有一个比较大的问题就是贵，只有那些比较大的企业才能用得起数据库，对于一些中小企业来说，随着业务的增长，也急需要一款能用的数据库出现，于是MySQL、PostgreSQL 等数据库以开源、免费和简化版的形态推动了数据库历史上第二波更加广泛而影响深远的发展，形成了数据库发展的第二波浪潮。

但直到 1996 年后，OLTP 领域再也没有新的主流数据库出现。

这是什么原因呢？因为在使用场景上并没有形成代际跃迁的变化，也就没法对现有数据库的能力和架构产生太大的推动力。直到以中国、美国为代表的区域迎来了第一波 PC 互联网到移动互联网的高速爆发，也就是在这之后，数据库领域慢慢开始有了新的变化，而比较有意思的是，这波移动互联网的变革，中国比美国跑得更快、更彻底，也更快地推动了大量技术的发展甚至是变革。

2000 年左右，基础架构还没有反应过来，从应用层到中间件层开始解决集中式解决不了的问题，以 Cobar，MyCAT 为代表的中间件方案的分布式架构出现。一直到 2010 年左右，以 Google Spanner、 OceanBase 等为代表的原生分布式架构出现，陪伴互联网高速发展的十余年，产品逐渐打磨成熟并开始商业化。

说完了阿里去"O"的外部原因，下面我们就来聊聊阿里内部是如何研发数据库的。

▉ 坚持自研 阿里打造"硬核"数据库

"O"指的就是 Oracle 关系数据库，要想真正做到去"O"，这代表着阿里在底层数据库需要重新考虑设计或开发。之所以提出这一理念是阿里深思熟虑后的结果。当时，正值中国互联网发展的高峰，传统数据库产品越来越难以适应用户的需求，去中心化、分布式架构已经成为发展趋势。

阿里这一理念虽然符合当时IT发展趋势，但是在当时看来挑战无疑非常大。要知道早在2007年，淘宝网日均PV就达到2.5亿个，商品数超过一亿个，全网成交额就达到四百多亿元。在当时，如何解决这些海量数据成为阿里面临的重要挑战。

当时，摆在技术团队面前有两条路，一条是基于开源，这种方式门槛儿低，起步更快；另一条是完全自研，从零起研发出一套能够满足淘宝业务需求的数据库产品。相比较而言，从难易程度来说，基于开源无疑是一个简单且见效快的方式。但经过深入研讨后，团队认为，要想从根本上解决数据库的问题，还是需要打破原来的架构完全重写，于是就有了-- OceanBase。

刚开始的时候OceanBase团队举步维艰。在当时自研分布式框架的时候，团队遇到了多变的需求以及复杂的场景，但也正是这种挑战让 OceanBase 得到了快速发展和完善。"逢山开路、遇水搭桥"是对当时整个团队工作最好的形容。

正是在前期采用了自主研发，让技术团队对代码有了完全的掌控力和掌控权，这是 OceanBase 最大的底气，也是 OceanBase 厚积薄发的根基。在过去的十多年， OceanBase 不断被打磨，从互联网支付核心到全场景金融核心，再到政企民生、运营商核心场景，以及新零售和新制造的核心场景，不断突破、创新，形成了逐渐成熟的 OceanBase。

在今年11 月 16 日，OceanBase 发布了一体化数据库的首个长期支持版本 OceanBase  4.2.1 LTS，相比 3.2.4 LTS 版本，在兼容性、性能、容灾能力、易用性等方面均有大幅度提升。如今，OceanBase 产品从最初的 1.x 发展到今天的 4.x，能力得到了飞跃式的发展，但 OceanBase 团队在研发过程中一直聚焦到"关键业务负载"，并持续在高性能、高可靠、高兼容和高性价等四个维度进行持续突破和深度打磨。

如今，OceanBase 代码行数超过300万行，获得超过200项授权发明专利，主导和参与了十多项国家/行业标准。OceanBase 最为人知的是近年来在"数据库世界杯"上的表现。2020年在国际联机事务处理基准测试(TPC-C)中获得7.07亿tpmC，成为世界第一，2021年在国际联机分析处理基准测试(TPC-H)中获得1，526万QphH@30，000GB，再破世界记录，中国分布式数据库弯道超车。

同时，在尚未为人熟知的那些性能指标，OceanBase 在不断提升。比如，高压缩比的分布式数据库存储技术，可以解决了集中式数据库无法平衡"性能"和"压缩"的难题，显著降低了数据存储成本。异构数据库平滑迁移技术体系，也可以最大程度降低了现有系统的扩展、迁移改造成本，等等。这些产品的基本功，是 OceanBase 最大的核心竞争力和投入最大的方向。

▉ 一体化满足用户"既要又要还要

随着互联网的发展，背后产生的数据越来越多，据统计，截止2022年底我国数据存储量已达724.5EB，这意味着如今数据量的"大"和40年前Oracle诞生时理解的"大"，早已不在一个量级。而且随着越来越多的企业用户的涌入，很多企业数据库不仅要大，更要小，弹性伸缩的能力成为对数据库性能的一项核心考验。

面向业务负载挑战，OceanBase 创新性的一体化产品战略应运而生--用一体化解决数据库的使用复杂度，目的是实现一个数据库解决 80% 的问题。它可以"一套系统，就能实现从单机到分布式对用户完全透明，同时业务可大可小，平滑压缩"。

为了实现一体化产品战略，OceanBase 足足花费了两年多的时间完成了技术讨论和总体架构的设计，并在2020年年中左右开始做详细设计和代码开发，再经过两年多的时间才在2022年8月份发布了第一个 OceanBase 4.0版本，代号"小鱼"。可以说，4.0版本奠定了单机分布式一体化架构的底座。

单机分布式一体化架构数据库的出现，为 OceanBase 打开了新的商业化思路。分布式数据库是大型企业的核心业务负载过重，集中式数据库性能无法满足时的产物，但小鱼的出现，让中小企业得以在业务早期就可灵活选择，并为后续业务体量爆发做准备，不必经历大规模迁移的过程。

但需要注意的是，OceanBase 一体化思路并不是指"一款产品打天下"，而是一个兼具易用性和实用性的解决方案。OceanBase 认为，在企业的绝大部分数据处理场景中，只要成本合理，这些都是必须的能力，OceanBase 希望能在这个强劲的底座上，尽可能满足 80% 的需求。但在极其专业的场景，还是需要用专门的数据引擎。就像今天的智能手机，可以很好地满足普通人对电话、聊天、游戏、听音乐和看电影的需求，但是针对一些专业用户，专业的游戏机是更好的选择，电影院是更好的选择。

其实，从 OceanBase 整个演进来看，"一体化"的设计就是 OceanBase 产品的 DNA，如上图，从外围试点到核心完全替代就是OceanBase 一体化的进程，可以说，OceanBase 都在用"一体化"的方式来解决问题。未来 OceanBase 将持续践行"一体化"的产品战略，用"一体化"的架构解决分布式数据库的使用复杂问题，用"一体化"的产品满足 80% 的客户需求，持续打造能够承载"关键业务负载"的分布式数据库。

正是由于OceanBase 在产品方面的"精雕细琢"，让 OceanBase 在IDC 发布《IDC MarketScape：中国分布式关系型数据库 2023 年厂商评估》报告中位列"领导者"类别。同时报告认为，作为一款原生分布式数据库，OceanBase在产品能力上表现突出，处于第一的地位。2022年发布的单机分布式一体化的产品更突破了集中式与分布式关系型数据库的场景隔离，用一个数据库产品伴随客户业务成长。

▉ 成千行百业客户首选

随着云计算、大数据、人工智能等新兴技术的发展，也对数据库产品提出了更高要求。云数据库成为新的市场热点，因此，在2022年，在原有企业版、社区版两个版本基础上，OceanBase 推出多基础设施的一体化数据库--云数据库OB Cloud，从而惬意用户面向不同场景可以使用不同版本的 OceanBase。

首先，我们来看下企业版，OceanBase 企业版是面向核心系统升级的理想选择，OceanBase 具有自主研发、稳定可靠、技术领先、高安全性、平滑迁移等五大特性。可以为头部金融机构提供异地多活单元化的完整分布式架构方案，也可以为中小机构提供偏向保留集中使用模式的无侵蚀的一站式方案。同时，也提供丰富的 ISV 适配和完整的培训体系，让更依赖外部厂商的中小机构，应对未来大规模使用后顾无忧。

第二，OB Cloud云数据库，OB Cloud具备五大特性：第一个是多级弹性扩缩容，弹性比普通的云上数据库的垂直水平扩展，非常灵活；第二在企业角度，可以大量客户希望降本， TCO 相比通用 RDS 降低 30% 以上，为海量数据的规模化降本提供更出色的选择。此外，OceanBase 还有领先的业务连续性、HTAP 实时分析等能力。这些特性无论是在云上还是云下，还是不同的云基础设施，OceanBase 都可以支持。

目前为止，截止目前已可在美洲、欧洲、亚洲三大洲的30个可用区提供服务，支持亚马逊云、阿里云、腾讯云等六大公有云基础设施。正是因为在云数据的出色表现，在Gartner发布最新报告《Magic Quadrant for Cloud Database Management Systems》（全球云数据库管理系统魔力象限），OceanBase 仅推出其云数据库一年就入选"荣誉提及"，也从侧面证明了OceanBase 在全球的影响力。

第三，就是 OceanBase 社区版，社区版的目标就是为现代数据架构打造"增强版 MySQL"，正是因为有这样的开放性，已经有越来越多的企业用来去解决 MySQL 无法解决的问题。OceanBase 目前拥有非常庞大的社区，不仅仅面向 OceanBase 的社区版，而是面向所有 OceanBase 的用户，相信很多企业版的客户也在用。

与此同时，OceanBase 一直积极在参与人才的培养，OceanBase 跟大量的高校建立了合作，孵化出的"数据库大赛"里用的 MiniOB 已经支持 20 多家学校的数据库实验教学实践，触达了 5000 多名的学生。今年，在办的第三届 OceanBase 数据库大赛，已经升级为国赛，现在已经有 200 多家高校的学生参与，这次还有海外的学生报名。

三个版本面向不同应用场景，可以更好的覆盖住目前市场上大多数业务场景需求，这也让 OceanBase 在迎来了快速发展。据了解，三年前 OceanBase 只有 18 个客户，现在已经有 1000 余家客户携手同行；而且相比于三年前，大家可能只敢用在周边系统，到现在越来越多客户敢用在核心系统，如今很多客户已经选择 All in OceanBase。尤其在金融行业，资产规模达到千亿以上的银行有100多家，OceanBase 覆盖了70%；在证券、保险、基金行业的头部 Top20 资产规模企业中，OceanBase 的覆盖率也非常高，分别达到75%、65%、45%。根据赛迪顾问《2022-2023 年中国平台软件市场研究年度报告》、《中国金融业数据库市场研究报告》显示，核心系统升级中 OceanBase 在金融行业处于第一。

随着客户数的增加，OceanBase 发现出现了大量高频重复的场景以及共性需求。所以，在服务上，OceanBase 今年也做了迭代升级，推出了基于场景的服务，为此适配了更多产品。随着客户用到深水区，要的是更多高阶的咨询能力，OceanBase 在这个方向已经投入了更多人，但是远远不够，明年 OceanBase 还会在这个方向继续增强。

▉ 最后总结

从 OceanBase发展过程我们可以归纳为三个重要阶段：

• 第一阶段，OceanBase 更多是用在阿里巴巴及蚂蚁集团内部的互联网场景上，从非金融到金融核心场景，慢慢把数据量很大但 SQL 并不复杂的简单 OLTP 场景完成了分布式改造，而且严格做到了集中数据库的 ACID 特性。

• 第二阶段，在简单的 OLTP 之上增加大量传统的 OLTP，数据量比较小，但 SQL 很复杂，有存储过程，大量复杂的函数和嵌套查询，有很多大事务，长事务，海量分区甚至各种外表的关联读写。同时，传统场景在数据量没有那么大时， OLTP 和 OLAP 的边界没有太明确的区分，所以开始增加简单的 OLAP 能力，提供在线数据上的复杂查询能力。

• 第三阶段，开始承载更多通用场景、通用业务，更多中长尾的应用开始使用  OceanBase。各种场景的打磨下，OceanBase 由此进化到 4.x 版本，也是业内首个单机分布式一体化数据库产品，适用于更广阔的场景。

需要说明的是，并不是说第一个阶段适用于互联网场景，第二个阶段适用于传统场景，第三个阶段适用于通用场景，而是相互叠加的，1.x 版本的能力是基础，2.x 和 3.x 之上再构架了 4.x 版本，层层叠加，能力不断增强，适用边界不断拓宽。

人们常说"十年磨一剑"，而 OceanBase 在过去13年间一直在坚持把分布式数据库做好，同时深入参与移动互联网的浪潮，在金融、支付、电商、游戏、直播等场景中，打磨了最好的产品能力。正是这13年的实践之路，减少了 OceanBase 与国际对手的能力差距，也收获了超1000家客户的"信任"。

在接下来的日子，OceanBase 将继续坚持自研，持续创新硬核科技能力。OceanBase 期待与每一位同行者，一起努力为"关键业务负载"打磨越来越好的"一体化"数据库，从而助力企业跨越数字化转型深水区，走出国门，走向全球。

END