蚂蚁金服资深总监韩鸿源：企业级数据库平台的持续与创新

2019 年 11 月 19 日，蚂蚁金服在北京举办“巅峰洞见·聚焦金融新技术”发布会，介绍 2019 双 11 支付宝背后的技术，并重磅发布全新 OceanBase 2.2 版本和 SOFAStack 双模微服务平台。

蚂蚁金服研究员韩鸿源在发布会分享了《企业级数据库平台的持续与创新》，以下为演讲实录：

在今天企业级的市场里，数据库是根本的基础支持能力之一，传统数据库技术正在面临各种各样全新的挑战，面对这些挑战的时候大家都在寻找一些新的解决方案。这些新的解决方案从什么地方来呢？当我想要替换非常成熟的被大家广泛使用的平台的时候，怎样让客户放心的去替换？在企业级数据库基础平台上，后续可能会是什么样的发展方向？这也是我今天想和大家探讨的内容。

关系数据库已经发展很多年，今天所有企业里面的业务系统，支撑核心的业务系统大部分都跑在关系数据库上面。原来传统企业里的业务系统接入终端数量很有限，不管是自己内部业务系统，还是对客户前端柜台做业务系统，终端数量都非常有限。基本上，系统的扩展能力可以通过数据库服务器的垂直扩展都可以满足要求。

随着移动互联网发展，今天的业务系统不管是银行、政府等，已经广泛暴露在大部分移动接入的客户面前。当这种情况出现时发现很大的变化，传统的系统垂直扩展是不可能解决这个问题。那么如何解决呢？这就衍生出很多不同的解决办法。除了传统的关系数据库持久化处理数据方式之外，演化出非常多的新的数据方式，所谓多态数据持久化等方式不断冒出来。

当所有这些东西来了之后，大家发现回到真正的业务逻辑上去看，关系数据库有它很突出的长处，它可以以一个数学上完善的方式帮助客户有效的构建业务系统，这些能力当你去放松对关系的严格要求之后，很多东西很难满足。包括客户已经有的业务系统，怎么样持续运营下去？怎么样保证客户已经有的这些严谨业务逻辑持续运营下去？所以带来很多新的挑战。

传统的企业客户不只是商业企业，泛指企事业单位和党政军范围，一般指具有一定规模且有重要性的实体。那么，对企业级系统和平台的要求也包括很多：1）高安全；2）高性能；3）高可靠性；4）高可用性；5）高开发效率，低维护成本；6）高可扩展性。这些对企业来讲都是很核心的东西。

上图底下是一个横轴线，从 2013 年-2019 年排在最前面几个数据库的活跃程度非常稳定。今天去看前三个最活跃的数据库依然还是关系数据库，关系数据库还是今天整个企业数据管理平台的主流，不但是主流，而且支持所有主要的业务系统。

主流关系数据库相对稳定，这些数据库受到很多的开源的冲击。对于绝大部分企业来讲不是做开发和软件的，需要是平台具备的这些能力，你要高可靠、高可用，能够帮助用户持续发展。只要这个产品足够可靠好用的情况下，客户可以自己把运维接起来的情况下，是没有必要看源代码的。今天我们谈企业级的时候，可能看的更多的是怎么样支持客户有效运营自己的业务。

上图是数据库的发展历史。最早有层次数据库、网状数据库等，当关系数据库出现之后，由于它们突出的特点，基本上主要的业务系统都迁移到关系数据库开发模式中去。从我个人来看，我经历大概 20 多年的历史，关系数据库是所有数据库里被判死刑次数最多的一个技术，到今天为止不但没有死，而且还在不停的焕发新活力。

RDBMS 真正的价值如何体现？我觉得，首先数据库里面强调的 ACID 帮助应用开发，简化了应用开发复杂性；第二点，SQL 这个写法很关键，接近于自然语义的写法，最大优点做业务开发的人写出来的代码可以让做业务人看得懂，带来的好处是大家沟通很方便，写出来的代码可读性可维护性非常强，所以摆脱这些技术是很困难的。但是关系数据库不是一成不变的东西，从集中式到分布式是一个大的发展方向，很多时候这些东西为了突破原来的限制和技术瓶颈。

互联网与互联网公司带来的变化是，用户访问量变化，以及很多新技术的探索和创新。最早互联网公司里有相当多互联网公司做的业务跟传统企业业务有非常大的差异。当你做这些业务的时候，有些业务是有标准答案，有些业务没有标准答案。当你在网上做搜索的时候，你搜之前肯定不知道搜索结果是什么？当你转一笔帐的时候，你转之前一定知道转帐结果是什么。这两件事对于数据库平台的支撑能力有完全不一样的要求。互联网公司面临压力大了之后，需要系统有非常强的可维护性的要求，很多东西是自动的维护和自动高可用的管理，这一块是一个很大技术变化的出发点。比如说高可用，传统企业的高可用基本靠半人工、半机器方式去做，基本不会完全相信机器，自己把高可用做的很完善。

举例来讲，非常多的金融机构都做了容灾系统，容灾系统切换这种决策没有人敢让机器做自主决策。当你的规模非常大的时候，这种管理很难去做到，触发怎么样实现自动高可用，真正让系统具备完整的判断能力。

当互联网发展到金融这个领域时，刚才我说的问题就很麻烦，很多用户有很多的并发请求，做查询不知道准确结果，做金融一定要知道准确结果，做错任何一点用户直接都会找你算帐。这个里面需要很完备的基础设施的支持，才能帮你支撑这么好的金融业务。

下面，我们希望跟大家探讨一下，后续企业里的数据库技术会有什么样的发展趋势？

首先，分布式已经是不可避免的潮流，这个里面有几方面的原因。单一的大服务器加存储的方式扩展能力有限，无法支持企业的持续向前发展。在今天的云环境里面，大家可以看一下市场上不管是哪一家主流的云供应商，现在已经没有任何一家云供应商会让你把服务器连到高端、高性能的存储上去支持数据库来运行。如果你想在云环境里运行数据库，必然要选择其他的实现方式。所以你看在测试的时候，包括系统架构设计方面，实际上是跟云的大趋势是一致的。今天，硬件发生了很多大的变化。像大家质疑我们的 TPC-C 测试结果一样，9 年以前跟现在的硬件有很大差异。

如果我今天给你 200 台服务器，装一个数据库上去，你根本装不上去，更不要说运行结果出来，这不是那么简单的一件事，能有效地把这些新的硬件用起来对软件是一个非常大的考验。如果大家看还在使用中的绝大部分主流关系数据库，它们有一个很大的特点，它们都设计在 30 年以前。30 年以前设计数据库的时候有两个假设，所有硬件内存都是很小的，所有的存储访问速度都是非常慢的，所有的数据库基本今天用的主要数据库都是从那个年代发展起来的，这两个限制条件给它加了很多枷锁。

如果大家尝试过可能会发现，我有一个 oracle 数据库今天装 256 个内存，明天扩 512G，性能能提升多少？能提升一倍吗？事实上能提升 1%就不错。什么原因？它的软件架构设计决定它不能有效使用新的硬件能力，当今天不停的有新硬件技术出现的时候，需要新的方式把硬件能力用起来，带给用户更好的系统，带给用户更好的回报和更简单的管理。

从云发展趋势来讲，其实数据库是最适合于云化的服务。怎么样能够以云化的方式有效的支撑客户去使用数据库也是一个很大的挑战。

最后，管理的规模也很大，系统也很复杂，怎么样把更多的人工智能带来的优点体现在系统里面去，帮助系统自动去运行，更好的自动去调优。这件事情今天说起来容易，最大挑战是要有足够大、足够广泛的使用环境和使用场景，才能帮你积累到数据，才能算出你想要的模型来。

那么，新的企业级数据库需要具备什么能力呢？

首先，数据库最好对硬件不要有特定的依赖，这样会阻止往云方向去发展和做优化。其次，今天所有的企业面临一个发展方向，都是怎么样从传统企业架构转到云原生架构，数据库怎么样支持用户转换前和转换后的平滑过渡。然后，在今天的企业环境里面，很多负载的变化是突发的。你需要能够在保障数据的情况下，在不同的运行环境实现灵活迁移。最后一点，数据库是非常适合云计算提供的服务，怎么样能够去真正把底层硬件能力发挥出来，比如在设计之初就要考虑多租户的环境，怎么样在多租户环境有效使用资源，支撑所有混合负载的能力。这些加在一起实际上是构建下一代数据库平台一些必须考虑的因素。

OceanBase 对新技术的探索

回到 OceanBase，我们在这些方面做了很多探索。

首先是高可用性。在今天来讲六级的高可用性已经是非常高的可用性，绝大部分机构实现不了这个级别，但是我们今天能实现远远超过这个级别，能够在 30 秒内实现自动恢复。这些靠的是在技术上怎么样把新技术有效用起来，比如说 Paxos。在传统数据库里不会有人去用它，在新的分布式场景下来讲，利用这些新的技术其实它还能帮你实现全自动的高可用。Paxos 这种自动投票的机制带来的优点是系统在不需要在外部干预情况下，把失效的东西替换掉之后持续去运行，在今天大规模运行环境里面是不可或缺的一个东西。

刚才讲到，今天的互联网带来的压力对于业务系统压力变大非常多，靠一个数据库一个系统支撑所有业务，一定不可能。在我们系统运行环境里，经过这么多的实际环境输入之后，今天可以给用户一个很灵活的选择，可以让用户去选择数据库的部署粒度，你可以选择分库分表，也可以选择单库。把选择权给到用户，用户可以根据自己的需要从不同的方式之间做过渡的融合，都可以帮助用户持续往前发展。

为什么要走向分布式数据库？传统都是最左边集中部署方式，它的优点是 ACID 不用担心，缺点是想扩的时候扩不上去。为了解决扩展的问题，大家才来做分库分表。分库分表绝大多数情况用中间件的方式来实现。这打破了数据库的边界，又同时引入了很多新问题。最大的问题是对应用不透明，如果你原来是一个复杂的业务应用，想适应分库分表的时候，对应用的改造工作量非常大。

为了解决这个问题，我们做了原生的分布式数据库。最简单的描述，你可以把一个分布式部署和运行的数据库完全当成一个集中的数据库来用，对你来讲不会有任何的差异。就像阳老师讲的，TPC-C 测的是一个系统的业务处理能力，对外表现来讲 TPC-C 所有的检查标准时，它跟单一的数据库对外表现是一样的。这在今天的分布式数据库里是最难实现的一点，怎么样能够把一个分布式的东西，表现给用户用的时候是当作集中式来用，能力有提升，但是使用上不增加复杂性。

我们去看传统数据库的时候，往往强调是 ACID 属性。如果只为了满足 ACID，可以很简单的做到。因为数据库可以停。为了保证 ACID，我们可以在有异常情况出现的时候，把整个系统停掉之后保证 ACID 不会出问题，但是用户用不了系统。在今天，保证系统高可用的同时，高可用反过来可以帮助 ACID。

原来传统系统里使用两阶段提交时，最大问题不是两阶段带来的系统消耗，是两阶段跨系统做交易的时候，一旦有一个参与者出现不可用，整个系统没有办法持续运行，状态不可知的时候，没有办法保证系统一致性。刚才讲的自动 30s 之内的 RTO 的恢复会发生很大的作用。当整个系统所有的交易参与者可以在很短的时间内恢复出来的时候，它是不会把业务挂起，可以确保业务持续运行下去，消灭了传统分布式系统里非常大的一个弱项。

今天整个市场上讲，关系数据库是一个全球范围内早已经划分完势力范围的市场。为什么今天还有新产品出现，是因为很多因素加进来之后，促成了很多新的变化。蚂蚁内部有非常多的使用 OceanBase 的业务，这些业务经历过去七、八年的发展，在这个过程中 OceanBase 增强自身的能力，消除很多问题，在一个大规模的复杂环境里面经历这么多年磨炼之后，从 2017 年我们走出来服务于外部用户。

希望以后有更多的用户给我们机会去尝试 OceanBase，我们也希望这个产品帮助大家解决很多现实中面临的问题，也欢迎更多的企业和组织加入进来。

关于 TPC-C，我想说，首先，TPC-C 是目前国际上唯一具有公信力的数据库功能与性能结合的公开检测标准。因为所有市场上主流的玩家，原来都在这个标准上发布过测试结果，即便这个测试模型源于 20 年前，但是所有结果都有意义。而且 TPC-C 的模型定义如果大家深入研究的话，里面有很多科学的东西。

第二点，TPC-C 测试大家往往看到很多误导性的信息，我在家里跑一个结果，单机 TPC-C 可以跑 150 万，200 万，300 万，这件事情没有意义，TPC-C 测试里面除了跑的性能指标之外，它有前提条件。TPC-C 测试过程中的 ACID 的检查，对于分布式数据库是一个非常大的挑战，今天绝大部分的分布式数据库面临这个问题采取的是回避的做法，不是直接解决问题的做法。测出来的结果很多不是有效的结果。我们之所以参与 TPC-C 审计，是为了证明我们的分布式系统是可以像单机数据库一样一分钟处理 6000 万笔新的订单。

第三点也就是在 TPC 认证过的 TPC-C 结果里面 OceanBase 取得的 6 千万 tpmC 排名第一。

第四点，测试是基于公有云通用机型实现的，使用的是和生产系统一致的基础环境。今天最大的变化是传统企业数据库往云环境搬的时候，最大的变化是没有能够匹配原来环境的那么强大的服务器可用。没有那么大的服务器和存储，怎么样解决这个问题？我们给大家去做了这个证明，你可以用软件的能力实现同样的性能指标。

最后，我不认为 TPC-C 是证明数据库完备性的充分条件，但是它是一个必要条件。当你要接的是这些大型机构核心业务系统时，如果你的数据库没有这种能力，肯定不可能帮助客户简单的把应用迁移过来。

今天，有些时候大家往往关注数据库的一个点，但是整个对于企业来讲走分布式转型这条路的时候，不可能只在数据库一个点上面走。我想说的是，企业整个的分布式转型是需要从上到下，结合中间件和开发过程管理和系统保障管理所有体系加在一起，才能够确保有效的走向分布式转型，真正能够支撑你的业务持续往前发展。

OceanBase 是完全自主研发的分布式关系数据库，我们掌握所有的源代码和系统的设计。在设计系统的时候没有预设限制性条件，没有对特定软件的依赖，没有对特定硬件的依赖，没有对特定系统架构的依赖，这个时候我可以非常广泛的去适配所有新出来的硬件系统和新的运行环境，可以帮助我们去探索更多的系统组合使用的空间。我觉得我们最大的优点是不存在对外部特定软硬件系统及系统架构的锁定性依赖。谢谢大家！

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/Pt87CfADpiH-Elph0iK2DQ