OceanBase 原理与实现分析

用户头像
ElvinYang
关注
发布于: 2020 年 05 月 11 日

最近看了《大规模分布式存储系统:原理解析与架构实践》,主要介绍了OceanBase数据库的原理和实现,是一本难得的好书。本文介绍书中的关键内容以及自己的想法。如果你有充足的时间,建议直接读原书,没必要花时间阅读本文,如果没有的话,可以阅读本文了解OceanBase的整体架构和关键内容。另外书中的内容是基于OceanBase 0.4版本的,0.4发布于2012年,距今已经8年,一些内容上可能有点陈旧,但是不影响整本书的价值。



1. 背景



OceanBase开发背景是为了解决海量数据的读写问题。举个例子,淘宝有个收藏夹功能,每个用户可以收藏自己感兴趣的商品方便自己访问。收藏夹可以有多个商品,用户可以添加或者删除收藏夹的商品。



  • 数据库设计了商品表item和收藏信息表info

  • 商品表item有数十亿条记录,收藏信息表info有数百亿条记录

  • 每个用户可以收藏几千个商品,热门商品可能被数十万用户收藏

  • 商品的价格等信息随时变化



对于这个问题,传统的方案有两种。



一种方案是info表只保存item表的索引,每次按用户ID找到info列表后,再根据索引找到每个item详情返回给用户。这种方案的问题在于,如果info表中的记录比较多,那么关联查询item的时间会很长,尤其是分库分表后,查询item可能需要到很多台机器上查询。这种方案对读不够友好。



另一种方案是info表冗余存储item详情,查询的时候只需要查info表,不需要关联查询item表。但这种方案的问题在于,如果商品item的信息变化了,比如价格修改了,需要修改所有几十万收藏了这个商品的info信息,分库分表后,可能需要到很多台机器上更新。这种方案对写不够友好。



这个问题是OceanBase面临的主要挑战之一。



2. OceanBase架构



大部分互联网业务有个特点就是读多写少,读的次数可能是写的几倍,几十倍,甚至更多。比如游戏业务,读写比可能是5:1,热门视频读写比可能是一百万比一。针对这个特点,OceanBase设计时采用单台更新服务器保存最近一段时间的增量数据。历史数据也叫基线数据保存在基线服务器中。每次查询的时候,从基线服务器取到基线数据,从更新服务器取到增量数据,合并后返回给客户端。更新服务器上的数据会定期同步给基线服务器,这样可以保证更新服务器上的数据不会太大。整体架构如下:



  • 客户端:兼容MySQL客户端,支持JDBC,C客户端访问。

  • RootServer:管理服务器,管理集群中所有服务器,子表数据分布和副本管理。一主一备强同步。

  • UpdateServer:更新服务器,一主一备,可以配置不同的同步模式。一般是强同步模式,异步模式主要用来做异地容灾。异步模式下,有可能会造成一段时间的数据丢失,但因为跨城的延时比较大,一般是30ms ~ 100ms,如果采用强同步方式,性能可能会慢得让你怀疑人生。 另外UpdateServer和RootServer一般部署在同一台物理服务器上。因为两台服务器都是单点,这样可以提升进程间通信的开销。

  • ChunkServer:基线服务器,基线数据一般存储三副本,相当于是存储系统的数据存储节点。

  • MergeServer:接收并解析客户端SQL请求,将请求转化成物理查询计划后发给ChunkServer或者UpdateServer,合并多个服务器返回的结果,将最终结果发给客户端。MergeServer无状态,相当于是存储系统的计算节点。



2.1 客户端



客户端访问OceanBase流程:



1)请求RootServer获取MergeServer地址列表。



2)选择某台MergeServer发送SQL请求。选择的策略有随机和一致性哈希两种。



3)如果请求MergeServer失败,从MergeServer列表中重新选择一台重试,如果某台MergeServer失败超过一定次数,将这台MergeServer加入黑名单并从列表中删除。客户端还会定期从RootServer更新MergeServer列表。



2.2 RootServer



RootServer主要功能包括集群管理,数据分布和副本管理。



集群管理:RootServer通过租约机制选择主UpdateServer。另外通过和MergeServer以及ChunkServer建立心跳来感知服务器的健康状态。



数据分布:存储数据时,OceanBase使用主键对数据排序后存储。基线数据按照主键划分子表,每个子表默认256MB,默认三副本,分布在多台ChunkServer中。每个子表负责的主键范围保存在RootServer中。一个子表划分例子:



副本管理:当某台ChunkServer故障时,RootServer检测后触发对这台ChunkServer上的子表增加副本的操作。如果某台ChunkServer的负载比较高,RootServer会定期执行负载均衡操作,将某些子表迁移到负载较低的机器上。



2.3 MergeServer



MergeServer主要功能包括协议解析,SQL解析,请求转发,结果合并,多表操作等。



MergeServer缓存了子表分布信息,根据请求设计的子表将请求转发给子表所在的ChunkServer。如果是写操作,还会转发给UpdateServer。如果请求跨多个子表,MergeServer将请求拆分后并发发给多台ChunkServer,合并这些ChunkServer返回的结果。如果某个ChunkServer故障,MergeServer将请求转发给该子表其他副本所在的ChunkServer。



2.4 ChunkServer



ChunkServer主要功能包括存储多个子表,提供读取服务,执行定期合并和数据分发。



OceanBase将大表划分成256MB的子表,每个子表一般由一个SSTable组成,每个SSTable由多个Block组成,每个Block 4KB ~ 64KB之间。子表不能太大也不能太小,太大的话导致子表迁移以及负载均衡成本较高,也不能太小,太小导致元数据会比较大,增加RootServer负担。查找数据时,先根据子表数据分布定位到子表,然后在SSTable中执行二分查找,找到基线数据后,ChunkServer请求UpdateServer获取增量数据,合并基线数据和增量数据的结果。



一般在凌晨的时候,OceanBase会触发UpdateServer的数据分发和合并,这时ChunkServer向UpdateServer请求某段时间的更新操作,和本地数据合并。



2.5 UpdateServer



UpdateServer更新数据流程:



1)同步操作日志到备机



2)写主机操作日志



3)更新内存



4)当内存数量超过一定值,生成快照文件,也即SSTable,存储到SSD中。



如果UpdateServer宕机,RootServer上的租约将失效,然后将备UpdateServer切换为主UpdateServer。宕机的UpdateServer重启后需要先加载快照文件,然后回放快照点之后的操作日志。注意第一步和第二部的顺序不能调换,书中8.3.6节这里的顺序写反了,书中先写本机再同步备机,如果主机在这之间宕机,数据还没有同步到备机,这时备机变成主机,之前宕机的主机重启后,回放快照,包含之前的最后一次更新,但是这时的新主机上没有这次更新,那就冲突了,书中8.4.1中的描述是对的。



注意第一步日志同步到备机,备机只要接收到日志写到内存就可以回复主机,不需要写盘后才回复,这样提高同步性能。而主机是需要写盘后才能回复客户端的。



UpdateServer的租约一般3 ~ 5秒,正常情况下RootServer定期给UpdateServer发送延长租期命令。如果RootServer需要升级,升级过程中,UpdateServer租约过期后系统就停止服务了。书中给出的方案是RootServer在退出前,会给UpdateServer发送一个超长时间的租约,承诺这段时间不进行主UpdateServer选举。但是这里有个隐患,如果这时主UpdateServer宕机了,就无法选择新的UpdateServer了,系统还是无法服务。而且因为RootServer主备强同步,即使RootServer有备机,也不能先升级备RootServer,再升级主RootServer。



因为集群中只有一台主UpdateServer,所以很容易实现事务,相当于是单机事务,而不是分布式事务,都不需要用到两阶段协议。然后通过每日数据合并和分发可以使UpdateServer的内存消耗不至于太大。



UpdateServer的数据结构是一个内存B+树,结构如下:



树中每个叶子节点对应一行数据,key为主键,value为每行按照时间的顺序操作链表。



比如:对主键为1的商品有3个修改操作,分别是:将商品购买人数修改为100,删除该商品,将商品名称修改为“女鞋”,那么,该商品的行操作链中将保存三个Cell,分别为:<update,购买人数,100>、<delete,*>以及<update,商品名,“女鞋”>。



注意这里保存的是操作列表,而不是最终值,这样做有什么好处呢?好处就是在进行事务回滚操作时,只需要把这个操作记录删除就行了。



OceanBase相当于GFS + MemSQL,ChunkServer相当于GFS,UpdateServer相当于MemSQL。



3 关键设计



下面介绍OceanBase关键点的设计方案。



3.1 定期合并和数据分发



定期合并和数据分发都是将UpdateServer中的增量数据分发到ChunkServer的手段,两者有相同的地方,也有不同的地方。相同的地方在于:



1)UpdateServer先冻结当前活跃的内存表,变成冻结的内存表,并开启新的活跃内存表用于保存后续的更新操作。



2)UpdateServer通知RootServer数据版本发生了变化,RootServer通过心跳通知ChunkServer。



3)ChunkServer从UpdateServer获取冻结的更新数据保存到本地。



不同的地方在于:数据分发只是将数据保存到内存,而定期合并会将本地SSTable的基线数据与增量更新数据执行多路归并,生成新的基线数据保存在新的SSTable中。定期合并是一个比较耗性能的操作,为了避免影响正常服务,定期合并会进行限速,而且RootServer通知所有ChunServer数据版本变化时,每个ChunkServer会等待随机一段时间后再开始定期合并,防止所有ChunkServer同时请求UpdateServer。



3.2 顺序写磁盘



不管是机械硬盘还是SSD,随机写磁盘都是一个耗时间的操作。对于机械硬盘,寻道时间比较长。对于SSD存在写入放大效应。所以OceanBase摒弃随机写,采用批量顺序写,提高写盘时的性能。对于随机读,SSD可以轻松应对。



3.3 子表复制与负载均衡



RootServer有一个线程专门执行子表复制和负载均衡任务。



子表复制是指当某个ChunkServer宕机后,为了防止数据丢失,需要增加副本数小于阈值的子表数量。增加副本时,RootServer选择这个子表副本所在的ChunkServer作为源,选择另一台负载较低的ChunkServer作为目的服务器,生成一个子表复制任务,加到任务队列中。



负载均衡是指当某台ChunkServer上的子表个数超过了阈值,把这台ChunkServer上的子表迁移到负载较低的ChunkServer上。



子表复制和负载均衡操作时,RootServer还会限制每个ChunkServer同时执行的任务数量,防止任务太多压垮ChunkServer。



3.4 子表自动分裂与合并



随着数据的增加和减少,每个子表的大小可能会差距非常大,有的几GB,有的几MB。为了维护每个子表的大小差距不至于太大,OceanBase会自动对子表的进行分裂与合并操作。



分裂操作由ChunkServer在定期合并时执行。如果当前子表大于256MB,找到当前子表的中间点作为分裂点,将子表分裂成大小差不多的两个子表。虽然每个子表的副本有多个,但只要所有子表都采用同样的分裂规则,就可以保证分裂后的子表是相同的。



合并操作流程如下:



1)合并准备:RootServer选择若干个主键范围连续的小子表



2)子表迁移:将待合并的若干个小子表迁移到相同的ChunkServer



3)子表合并:往ChunkServer发送子表合并命令,生成合并后的子表范围



因为每个子表有多个副本,只要某一个副本合并成功就行,失败的子表通过垃圾回收机制删除。副本数小于阈值的子表将会在子表复制过程中恢复副本数量。



3.5 SSTable文件结构



SSTable的文件结构如下:



1)第一列下部框图是整个SSTable的结构。每行数据按照主键排序后存放在多个Block中,Block之间也是按照顺序排列。接着存放的是Block Index,把每个Block最后一行的主键作为Block Index。接着是布隆过滤器和表Schema。最后是Trailer和Trailer Offset。Trailer是保存的是各个区域的偏移信息,比如每个Block在哪个位置,Block Index在哪个位置,有了这些位置信息可以快速读取到某个Block的数据,而不需要把整个文件加载到内存。Trailer Offset保存到是Trailer本身的偏移位置。



2)第二列下部框图是Block Index的结构。上部框图是Block结构,先是两个Header信息,接着是每行数据,最后是Row Index,也就是每行的偏移信息,可以快速定位到行。



从SSTable查找数据时,首先读取Trailer Offset信息,根据这个读取Trailer信息,从Trailer中获取到Block Index位置,把Block Index读到内存,通过二分查找找到这个主键属于哪个Block。接着读取Block到内存,再用二分查找找到对应行。



从上面流程看到,整个ChunkServer是一个三级索引结构:子表索引,块索引以及行索引。通过这些索引可以快速读取到行数据。为了进一步加速读取,ChunkServer使用了缓存功能,包含三种:块缓存,行缓存以及块索引缓存。块缓存和行缓存存储访问频繁的数据块和数据行。块索引缓存一般常驻内存,因为块索引一般不会太大。



3.6 UpdateServer瓶颈



UpdateServer的一些性能数据:



千兆网卡每秒收发包超过50万个,万兆网卡每秒收发包超过100万个;



16核机器上B+树每秒单行修改操作查过150万次。



经过网络,内存结构,IO读取,多线程操作等多种优化,UpdateServer的性能已经很卓越了,但是随着应用的场景越来越多,还是有可能成为瓶颈。一种可能的扩展方式是采用数据分片的方式,把所有数据按Hash分片,这样同一个用户的数据会分到同一个UpdateServer。但是这样带来的问题是如果要修改多个用户的数据,就会带来分布式事务的挑战,可以通过两阶段提交或者最终一致性方式实现。



3.7 事务和MVCC



OceanBase支持多线程并发修改,写操作拆分为两个阶段:



1)预提交(多线程执行):事务执行线程首先锁住待更新数据行,接着,将事务中针对数据行的操作追加到该行的未提交行操作链表中,最后,往提交任务队列中加入一个提交任务。



2)提交(单线程执行):提交线程不断地扫描并取出提交任务队列中的提交任务,将这些任务的操作日志追加到日志缓冲区中。如果日志缓冲区到达一定大小,将日志缓冲区中的数据同步到备机,同时写入主机的磁盘日志文件。操作日志写成功后,将未提交行操作链表中的cell操作追加到已提交行操作链表的末尾,释放锁并回复客户端写操作成功。



为什么要拆分成两阶段?多个线程同时提交会有什么问题?我能想到的一种解释是提交阶段的写日志缓冲,同步备机和写磁盘这三个操作是没办法多线程执行的,所以把提交阶段设置为单线程执行,而预提交多线程执行,既保证了正确性又兼顾了性能。



另外每个写事务会根据提交时的系统时间生成一个事务版本,读事务只会读取在它之前提交的写事务的修改操作。其中写事务需要加锁,版本号是在提交时生成,而读事务不需要加锁,版本号在预提交时生成。对于读写事务,需要加锁,版本号在提交时生成。举个例子:

对主键为1的商品有2个写事务:



  • 事务T1(提交版本号为2)将商品购买人数修改为100,事务T2(提交版本号为4)将商品购买人数修改为50。

  • 事务T2预提交时,T1已经提交,该商品的已提交行操作链包含一个cell:<update,购买人数,100>,未提交操作链包含一个cell:<update,购买人数,50>。事务T2成功提交后,该商品的已提交行操作链将包含两个cell:<update,购买人数,100>以及<update,购买人数,50>,未提交行操作链为空。



对于读事务:



  • T3:事务版本号为1,T1和T2均未提交,该行数据为空。

  • T4:事务版本号为3,T1已提交,T2未提交,读取到<update,购买人数,100>。尽管T2在T4执行过程中将购买人数修改为50,T4第二次读取时会过滤掉T2的修改操作,因而两次读取将得到相同的结果。

  • T5:事务版本号为5,T1和T2均已提交,读取到<update,购买人数,100>以及<update,购买人数,50>,购买人数最终值为50。



OceanBase锁定粒度为行锁,默认隔离级别是读取已提交(read committed)。read commited会遇到不可重复读和幻读问题,使用MVCC功能,可以解决不可重复读问题。读操作读取某个版本的数据快照,不需要加锁。



  • 只写事务:事务预提交时加锁,事务提交时释放锁。如果修改多行数据,使用两阶段锁2PL。

  • 读写事务:读操作读取某个版本快照,写操作加锁方式和只写事务相同。



OceanBase处理死锁的方式为事务执行时超过一段时间无法获取锁,回滚事务。



3.8 淘宝收藏夹实现



回到文章开头的问题,如何实现收藏夹?



根据前面的OceanBase的特性,可以采取这样的方案:info表中冗余存储item的信息,用户查询收藏夹时,MergeServer先发请求给ChunkServer请求基线数据,然后ChunkServer再发请求给UpdateServer,获取用户info记录和各个item的增量信息,因为UpdateServer的数据都在内存,即使这个用户收藏了几千个item,获取增量信息也会很快。合并基线和增量信息后,返回给MergeServer,再返回给客户端。



在每日定期合并时,info和item表的增量信息需要合并进ChunkServer的info表中,生成新的基线数据,这样可以减少查询时在UpdateServer上处理的数据量。



4 后续迭代



《大规模分布式存储系统:原理解析与架构实践》书中介绍的OceanBase是0.4版本,发布于2012年,后面几年OceanBase又经过了一系列的迭代改进。



1.0版本



2016年发布1.0版本,主要的变化有两点:



引入Paxos实现真正的高可用和强一致性。



改进架构,将UpdateServer、ChunkServer、MergeServer和RootServer合并为一个ObServer。这样可以减少运维和部署成本。 而ObProxy主要是反向代理的作用,对用户的SQL进行解析,将请求发给对应的ObServer。新的架构如下:



实现多租户功能SQL-VM,隔离不同用户之间资源,包括CPU,内存和IO。



2.0版本



2018年发布2.0版本,和1.0相比架构没有太大变化,主要对扩展性,高可用,一致性,低成本和易用性做了提升,提供了全局一致性快照功能。



看完整本书,个人最大的感受就是如果可能的话,一切都应该自动化,减少人工参与。包括但不限于自动合并分裂子表,自动负载均衡,自动切换主备等。而且系统设计阶段就应该考虑自动化的方式,否则等系统上线运营后再引入自动化可能成本就会比较大。



参考



  1. OceanBase 1.0 分布式技术架构

  2. 大规模分布式存储系统:原理解析与架构实践



发布于: 2020 年 05 月 11 日 阅读数: 1013
用户头像

ElvinYang

关注

每个人的一生都是一次远行 2020.05.11 加入

喜欢天文历史滑雪潜水的程序员,个人博客地址https://yang.observer

评论 (4 条评论)

发布
用户头像
最好提供一个头图,文章转载到InfoQ官网了,有头图展示效果更好。
2020 年 05 月 12 日 14:17
回复
用户头像
OceanBase还是挺赞的~
2020 年 05 月 11 日 22:25
回复
用户头像
@yuan_shenyi:“大部分互联网业务有个特点就是写多读少” 笔误
2020 年 05 月 11 日 21:29
回复
感谢指出错误,已修改
2020 年 05 月 23 日 14:49
回复
没有更多了
OceanBase原理与实现分析