头图

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/


3 月 25 日,第一届 OceanBase 开发者大会在北京举行,OceanBase 首席架构师杨志丰(花名:竹翁)带来了 《OceanBase 的单机分布式一体化》 的分享,为大家介绍了单机分布式一体化架构的概念及思考,以及对业务的价值。

以下为演讲实录:

今天我的演讲主题是《OceanBase 的单机分布式一体化》,主要来解释 OceanBase 为什么要做单机分布式一体化,我将从以下 3 个方面进行今天的分享:

首先,单机分布式一体化是什么?

其次,单机部署时如何获得与单机数据库相当的性能?

最后,分布式部署时如何实现高性能低时延?

什么是单机分布式一体化?

每个人听到“单机分布式一体化”可能都会有自己不同的理解,也会有很多疑问,事实上,单机分布式一体化不是 OceanBase 突然冒出来的概念,而是基于三方面的原因。

第一,产品迭代。 OceanBase 从 2010 年开始自研,在走出蚂蚁集团开始服务金融行业,到现在走到云上去服务更多互联网行业客户的过程中,基于客户的反馈,我们的产品不断在演变、完善。

第二,硬件趋势的不断发展。 OceanBase 在 1.0 最初设计的时候,当时我们在蚂蚁集团的内部集群,用的机器都是普通 16 核的机器,后面随着硬件技术的发展,我们的主流机器都在 96 核以上,服务器单机的性能有了极大的提升。

第三,云技术的发展。 近几年,云技术发展突飞猛进,OceanBase 刚刚创立之初,云技术刚刚兴起,而现在云基础设施触手可得。技术的发展伴随着 OceanBase 架构的发展,OceanBase 的技术经历了三个大的版本迭代。

▋ 从 0.1 到 4.0,OceanBase 的发展历程

Image

第一个版本是 0.5 版本,虽然是十几年前的版本,但其实它已经完全是分布式的架构,在当时,OceanBase 把 SQL 层和存储引擎做了分离,上面是一组 SQL 无状态服务,下面是由 ChunkServer 和 UpdateServer 组成的存储集群,对外暴露的就是表的 API。当时由于我们刚刚开始去做数据库的实现,所以我们做了一些限制——没有多点写入,所以当时实际上是不支持分布式事务的。

当 OceanBase 从 0.5 往 1.0 演进的时候,我们有一个深刻的感受:传统单机数据库采用紧耦合的设计,存储和计算放在一起,后来因为有了 NoSQL,很多人觉得是不是应该把存储层单独隔离开,OceanBase 在零点几版本的时候就遵循这样的设计思路,所以我们做了分离,但分离以后带来非常大的问题。

这个问题在于做 NoSQL 还可以,但是要做关系型数据库并没有那么简单,如果你对时延有要求的话,松耦合的方式会导致效率上有很大开销。所以 OceanBase 从 1.0 开始,我们就在重新思考这个问题—— 把存储事务 SQL 做成紧耦合的架构,即全分布式架构,将原来的三个 Server 合成一个 OBServer 的节点,同时处理存储事务 SQL,同时我们将高可用的粒度,由原来机器级别的高可用粒度,切分成若干个 Zone, 这些都得益于我们在蚂蚁集团的场景实践。

当 OceanBase 发展到 2.0 版本时,OceanBase 从蚂蚁集团走向了外部客户,在这个过程中客户反馈说:“OceanBase 只支持 MySQL,是很好,但我们这里面有很多的 legacy(遗留) 系统是不可能把它完全的改成用 MySQL 或者用开源的方式去做的”,所以 OceanBase 在 2.0 的时候引入了重要的特性,在多租户的能力之上又兼容了 Oracle,但它的整体架构和 1.0 是一样的,在 4.0 版本时,我们就进入了全新的单机分布式一体化的阶段。

▋ 单机分布式一体化的三个含义

现在,我来正式定义一下 OceanBase 单机分布式一体化到底是什么,单机分布式一体化有三个层面的含义。

Image

第一个层面,OceanBase 以一个程序的形式存在,既可以在单机的形式下部署,也可以做成多机部署。 这个并不是非常容易做到的事情,只有我们把单机分布式一体化作为一个目标,才能去实现这样的形态。

第二个层面,我们所谓的单机分布式一体化,其实有一个租户的概念。 即使你部署了一个分布式的 OceanBase 集群,但是里面的某一个租户如果在单机上,我们也认为这是一种单机的形态。

第三个层面,单机分布式可动态转换。 在两种形态之间,OceanBase 可以随意切换,可以灵活地做动态的调整,单机可以变成分布式,分布式可以变成单机,同样在租户层面和集群层面都可以做到。

Image

虽然也会有其他方面的很多挑战,但切换的最大挑战显然是关于性能的,所以接下来我将分享 OceanBase 怎么做到在单机分布式一体化架构下面,在单机部署的时候可以做到单机数据库相当,在分布式部署的时候我们在保证可扩展性的同时,又可以做到比其他的分布式数据库更高的性能和更低的时延。

▋ 单机分布式一体化,匹配企业不同发展阶段

首先看业务的价值,对于很多企业来说他是有一个从小到大的过程,或者说在大企业内部有个小的业务,业务都是从小开始变大,有一天可能某个业务突然冒出来,但最初的时候其实并不需要那么多的资源,我们希望用户既可以享受到分布式数据库带来的优势,使用起来又不存在非常多的困难,可以一个数据库解决企业多个不同发展阶段的需求。

OceanBase 正式支持单机形态部署。如果你对读写分离有要求,你可以使用 OceanBase 主备库的能力,就像传统的 MySQL 的主备库一样,没有任何的区别;如果你觉得 MySQL 的主备库在切换的时候会产生丢数据的问题,特别是远程容灾的时候,可以从主备库动态的升级到 OceanBase 三副本模式;如果你觉得高可用、三副本的模式不能在现阶段掌握,或者对你来说不是很关键,那么 OceanBase 其实具有非常强的单机模式下 scale-up 垂直扩展的能力,所以我们并不是做分布式数据库就不管单机的性能。

Image

当企业或者业务发展到大规模场景的时候,有非常多的问题要考虑。比如,业务特别多,在蚂蚁集团内部,大家可以想象有非常多的业务、甚至有上万台的机器在使用 OceanBase,这个时候如果你只有 10 人的 DBA 团队,你怎么去管理一万个 MySQL,这是非常大的挑战,所以我们的多租户和整个分布式的架构,使得我们可以把集群的数目控制在一个合理范围之内,在每个集群内部有很多自动化运维的手段,让我们的 DBA 真的可以安稳的睡一个好觉,此时有很多非功能性的需求就提出来了。

比如,分布式数据库是很好,但是我可能在当前这个阶段并不需要。但是我想说“有了 OceanBase 的单机分布式一体化架构,大家不会有担心,你可以在你需要的时候选择你所需要的特性”。反过来说,如果我引入了分布式数据库,同时给你搭售了三副本和很多其他你不需要的能力,那不是我们所希望的,这也是我们单机数据库核心的价值。

单机部署时如何获得与单机数据库相当的性能

▋ 过度分层设计虽然简化了实现,但牺牲了性能

反过来想这个问题,如果我有一个分布式的数据库,左侧是其他的分布式数据库的典型形态,将存储节点和计算节点做一个分离,他们之间通过网络进行通讯,这样的话是可以各自做拓展的。分布式数据库当然不是仅分片那么简单,数据库很重要的是事务处理的中心节点,数据库要保证数据全局的一致性和原子性,所以很多数据库会引入这样一个全局事务管理器的模块。

Image

OceanBase 也有类似的模块,我们叫全局时间戳服务,功能都是类似的,像上边的右图一样,将三个节点装到一台单机上。

很多人说这样的“单机分布式一体化”我们也可以,但这里面是有非常多开销的,因为分布式处理所涉及的很多协议,对于单机来说都是开销,各个组件之间,如果你通过 RPC 做通讯,会产生非常多额外的开销,另外 RPC 协议是需要专门去设计的,所以在设计这种通讯协议的时候,不能像函数调用一样,可以尽量灵活的做很多快捷的处理。

此外,还有一层隐藏的含义,就是从我们从事数据库研发的视角来说,如果你以分布式作为开头,你在实际实现过程中不会去想单机是什么情况,这个是大家可以理解的。

▋ OceanBase 的单机分布式一体化

我们看一下 OceanBase 单机分布式一体化整体的架构,说起来非常简单: 每一台机器都具有自己独立的 SQL 存储事务的模块,在单机之内,SQL 存储事务之间直接通过函数调用,和单机没有任何区别;在机器和机器之间通过网络去做通讯。

Image

上图中的架构有几个特征:第一,每个节点单进程,OceanBase 没有那么多角色区分,整个 SQL 事务存储是在单个进程内共享内存的;第二,单机内工作是没有 RPC 的,并且对于单机数据库来说,为了提升垂直的扩展性,OceanBase 还支持单机内并行,在更深层次上,每个组件的设计,OceanBase 都会兼顾单机和分布式。

在这样的设计里面,我们每一个功能的设计都要考虑在单机内怎么样做最好,分布式时怎么做最好,所以我们的设计都会有这样两个维度。

首先看单机的两个含义,第一,每个 Zone 里面一个OBServer,所以即使一个 Zone 里面有很多个资源的单元,即 Unit,如果你的租户是单个 Unit,就等于这里所讲的单机。

为了提升单机内垂直的扩展性,OceanBase 在 SQL 引擎、事务引擎、存储引擎都会做到极致的优化:第一,单机内可以并行;第二,在事务引擎里,我们在做事务的高并发处理的时会做组提交的技术。同样在存储引擎里面,我们的存储引擎属于准内存的存储引擎,写入的时候只需要放到内存里就可以了,并不需要像传统的 B+ 树一样,把它写到数据块里。单机内同样在 IO 层面支持很多并行。

你会看到早期的 MySQL 给他一个 96 核的集群,想把 CPU 跑满,是不可能的,这就是垂直扩展性的表现。

▋ OceanBase 4.0 VS MySQL 8.0

Image

上图是 OceanBase 4.0 和 MySQL 8.0 的性能对比,在六种场景下,OceanBase 4.0 和 MySQL 8.0 的性能都是相当的。

Image

上图是我们垂直扩展性的试验,同样在 Sysbench 的六种负载场景下, 从 4 核到 64 核的机器,大家都可以看到 OceanBase 具有非常好的垂直扩展性,多给一倍的核数,OceanBase 的性能就提升一倍。

分布式部署时如何实现高性能低时延

对于 OLTP 业务来说,大家用分布式数据库很担心时延的指标,那么单个操作的时延指标是不是能像单机数据库一样呢?这是 OceanBase 着力在优化的点。基本原因就是:无论你在怎么样的数据中心,做一次 RPC 就需要 0.5 毫秒,这个时间不可忽略。

▋ 分布式性能需要高性能低时延

下图是在某个特定的负载下面,随着分布式事务比例的增加,单机数据库和两种分布式数据库的性能表现,绿色是单机数据库。

Image

随着某种分布式事务的增加,对于比如 TPC-C 来说,即跨 warehouse 交易的增加,和单机数据没有什么差别。如果有两种数据库, OceanBase 的设计目标是变成下面 DB1 的性能曲线,随着分布式事务增加,肯定有开销,但当我还没有分布式事务的时候,DB2 的性能就比 MySQL 差非常多,这不是我们想设计的分布式数据库。

此时有两种方式可以做到,第一就是降低分布式事务和分布式查询的这个比例,正如 CTO 杨传辉所说: “实际上对于很多在线型的交易,全局性的事务,他的比例往往并没有大家想的那么多。在典型的 TPC-C 场景下,TPC-C 里跨 warehouse 的交易查询只有10%” (可移步阅读《OceanBase CTO杨传辉:万字解读,打造开发者友好的分布式数据库》)。做在线交易的时候,DBA 同学很清楚自己的业务,并不是所有的东西都要付出分布式的开销,为了能够达到这样的效果,我们做了很多的工作,其中最主要的就是 4.0 里面自适应的日志流。

OceanBase 做了很多自适应的策略,去自动化的根据表的设计去做自动的负载均衡,自动的做数据排布减少分布式事务和分布式查询的比例,如果这些自动化的措施都达不到这个目标,用户同样可以用我们提供的分区表和表组的功能自己去控制、降低分布式事务。

如果以上的要求都做不到怎么办呢?我们就必须硬碰硬地降低分布式事务和分布式查询整个的开销,这块 OceanBase 有很多独特的设计。

▋ OceanBase 分布式为何能高效经济?

回到单机分布式一体化架构,在这个架构下面我们看看分布式场景下它是怎么工作的。

Image

对于上面这种分层的设计来说,如果 SQL 层、存储层、事务层是分层的设计,无论自己怎么操作,这个 SQL 和本地的事务之间是没有感知的,所有的东西都是全局的,本地的交易数据还是远程的交易数据对于 SQL 层都没有差别。OceanBase 不是这样,我们显式的就区分了这两者的区别,所以 OceanBase 的 SQL 层可以直接访问到另外一台机器的存储层。如果需要访问另外一台机器存储层的时候我做 RPC,如果我访问的存储是在本地,就不需要做 RPC。

整体设计的时候有几个不同的粒度,本质上设计时我们做得更加精细化,精细化是说单机分布式并不是简单的概念,而是多个粒度的单机,在我们看起来有四个基本的粒度:

第一,租户。 是分布式的租户还是单机的租户。

第二,会话。 OceanBase 会通过 Proxy 路由协议使得在很多其他数据库里面分布式的做一件事情,在 OceanBase 会变成单机的事情。最典型的就是我们会根据这条 SQL 的特征,把它路由到存储所在的节点上,这样即使整体上看起来好像是分布式,但是对于那条 SQL 的执行,它就变成本地执行。

第三,事务。 在事务层面上,OceanBase 如果在单个事务内只操作一个日志流内的分区,分布式事务提交的协议和单机的协议也是有区别的。

第四,SQL。 如果是一个单机的 SQL 执行和需要远程访问 SQL 的执行,我们有两种独立的执行路径。在此基础之上,为了使分布式的执行更加高效,我们整个 SQL 引擎在 OLTP 上面做串行执行的时候会有自适应的策略。

我们的设计从来都是一个整体,对于 LSM-Tree 来说,合并是非常消耗资源的后台任务,但是如果在分布式的部署场景下,我们发明了一种聪明的方法: 使得每台机器的合并和它的服务可以错开,我们称之为“轮转合并”,就是如果一个副本在提供服务就先不合并,我让 follower 副本去做合并,这样使得后台的 LSM-Tree 合并对于前台的操作在这台机器上没有影响。

▋ 单机分布式自适应的执行引擎如何提升分布式查询性能

如果我没有办法优化业务来减少分布式 SQL,对于分布式 SQL 这部分我怎么去执行?OceanBase 整体的 SQL 自适应执行引擎,分为串行执行和并行执行。

Image

并行执行可以在单机内并行,这一点相对于一些开源的单机数据库是有优势的,早期的 MySQL 版本单机内并行是没法做到的,又可以利用多机,如果一台机器 CPU 还不够,我可以把整个集群的 CPU 用起来去做并行执行。串行执行我们就显式地去区分了,它到底是一个大数据量的访问,还是一个小数据量的访问。

如果是一个小数据量的访问,我们会把数据拉到本机来执行;如果是一个大数据量访问,我们会把整个 SQL 的执行计划下压到那台机器上去做数据过滤,整个过程是优化器自适应去选择的。

▋ 兼顾单机和分布式的事务处理协议以提升事务性能

最后,事务是非常难做分布式优化的,OceanBase 在事务引擎方面有非常多的创新的专利。在这里我介绍两个点,下图是分布式事务执行提交的流程,事务从整体上来看分成 “事务开启”和“事务提交” 两个关键操作。

Image

第一,在“事务开启”的阶段,左侧是其他的分布式数据库典型的两阶段提交的过程。在开启事务的时候,为了实现多版本的隔离,读和写互相不影响,在 MVCC 的场景下,它需要获得一个全局的快照——即当前哪些事务在操作,哪些事务已经提交了快照,对于很多分布式数据库来说,这个快照的操作是非常大的开销。

而 OceanBase 在这个阶段做了优化,我们在很多场景下,OceanBase不需要访问全局的时间戳服务。我们创新地实现了一些对于 GTS 服务的优化,使得这部分的开销是可扩展的。证明就是 TPC-C 测试,TPC-C 有 1500 个节点,1500 台机器每秒处理 2000 多万次事务(是事务并不是 SQL),但只有一个 GTS 服务节点,看起来好像这个 GTS 不容易扩展的,实际上我们优化后变得很容易扩展。

第二,在“事务提交”的阶段, 对于提交的协议来说,大家可以看到左侧两阶段的提交协议,传统的两阶段提交协议需要写四个阶段的日志,在参与者上要写事务的日志,在协调者上也需要记录日志,使得两阶段提交在容灾的场景上是安全的。

OceanBase 在两阶段提交上做了一个非常创新的设计,OceanBase 的参与者是三副本、高可用的,所以并不担心协调者的节点数据丢失,所以我们在参与者上不记日志,这样就节省了两条日志。第二,我们会在第一个阶段就给应用返回成功,这是我们非常独特的一个优化,使得整体的 roundtrip 少了一次。所以整体来说,即使在分布式事务场景下面,OceanBase 的分布事务比其他的分布式数据库有很大的优势。

Image

最后附上 OceanBase 与市场上几款常见的分布式数据库在 Sysbench 500 线程下的性能对比,这也就是全分布式场景下 “OceanBase 的低时延是什么” 的最好呈现,我的分享就到这里,谢谢大家!


欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/


OceanBase技术站
22 声望122 粉丝

海量记录,笔笔算数