《大规模分布式存储系统》第8章OceanBase架构初探【8.4】

javazx

8.4　架构剖析
/ d1 p9 U# _2 C+ `5 Z8 h! S- Q, a) l3 V8.4.1　一致性选择
Eric Brewer教授的CAP理论指出，在满足分区可容忍性的前提下，一致性和可
6 G  R& ]) ?# S, o用性不可兼得。
虽然目前大量的互联网项目选择了弱一致性，但我们认为这是底层存储系统，
; T( G9 E& z8 d比如MySQL数据库，在大数据量和高并发需求压力之下的无奈选择。弱一致性给应
3 p0 H/ v6 ?+ @$ S用带来了很多麻烦，比如数据不一致时需要人工订正数据。如果存储系统既能够满
' A! m, z1 u! ~1 W* N( a足大数据量和高并发的需求，又能够提供强一致性，且硬件成本相差不大，用户将
毫不犹豫地选择它。强一致性将大大简化数据库的管理，应用程序也会因此而简
化。因此，OceanBase选择支持强一致性和跨行跨表事务。
/ x. w4 C* a4 F' C, BOceanBase UpdateServer为主备高可用架构，修改操作流程如下：
1）将修改操作的操作日志（redo日志）发送到备机；
# z/ h8 Y/ W9 \2）将修改操作的操作日志写入主机硬盘；
3）将操作日志应用到主机的内存表中；
4）返回客户端写入成功。
- m0 \8 f5 ~- O/ L) h" C  \OceanBase要求将操作日志同步到主备的情况下才能够返回客户端写入成功，即
4 z, ^; z5 ~) ^8 q使主机出现故障，备机自动切换为主机，也能够保证新的主机拥有以前所有的修改
: i  y- g0 L$ Q5 f$ B1 Z操作，严格保证数据不丢失。另外，为了提高可用性，OceanBase还增加了一种机
1 o* U7 \5 s8 o+ w, @! B& m制，如果主机往备机同步操作日志失败，比如备机故障或者主备之间网络故障，主
机可以将备机从同步列表中剔除，本地更新成功后就返回客户端写入成功。主机将
备机剔除前需要通知RootServer，后续如果主机故障，RootServer能够避免将不同步
; X/ o9 t5 `( ~6 ^8 D的备机切换为主机。
- s! V) t# X5 YOceanBase的高可用机制保证主机、备机以及主备之间网络三者之中的任何一个
) z) Q% i2 \, [: X5 ~: S6 ~% d出现故障都不会对用户产生影响，然而，如果三者之中的两个同时出现故障，系统
可用性将受到影响，但仍然保证数据不丢失。如果应用对可用性要求特别高，可以
增加备机数量，从而容忍多台机器同时出现故障的情况。
OceanBase主备同步也允许配置为异步模式，支持最终一致性。这种模式一般用
来支持异地容灾。例如，用户请求通过杭州主站的机房提供服务，主站的
  J9 }: c9 [4 X& _. EUpdateServer内部有一个同步线程不停地将用户更新操作发送到青岛机房。如果杭州
机房整体出现不可恢复的故障，比如地震，还能够通过青岛机房恢复数据并继续提
供服务。
7 H; `0 d. k4 A* N. \6 l+ k) ]另外，OceanBase所有写事务最终都落到UpdateServer，而UpdateServer逻辑上是
# _; P/ X# c/ [- J4 V6 z一个单点，支持跨行跨表事务，实现上借鉴了传统关系数据库的做法。
* _2 V6 j5 {7 q" W) r3 @8.4.2　数据结构
/ `$ o3 o! J( o+ rOceanBase数据分为基线数据和增量数据两个部分，基线数据分布在多台
ChunkServer上，增量数据全部存放在一台UpdateServer上。如图8-5所示，系统中有5
个子表，每个子表有3个副本，所有的子表分布到4台ChunkServer上。RootServer中维
/ V3 s- Z9 O' Z, W护了每个子表所在的ChunkServer的位置信息，UpdateServer存储了这5个子表的增量
+ P2 o8 t3 P0 @' x: O( Y更新。
: U2 r" i2 X2 M% v. {) j图　8-5　OceanBase数据结构
- \1 \0 |$ n( X( J6 ^$ O' |不考虑数据复制，基线数据的数据结构如下：
●每个表格按照主键组成一颗分布式B+树，主键由若干列组成；
●每个叶子节点包含表格一个前开后闭的主键范围（rk1，rk2]内的数据；
●每个叶子节点称为一个子表（tablet），包含一个或者多个SSTable；
●每个SSTable内部按主键范围有序划分为多个块（block）并内建块索引（block
: {2 v% j8 A+ u, rindex）；
# I: D% q9 j1 b) z●每个块的大小通常在4～64KB之间并内建块内的行索引；
6 Y8 n% }0 G3 O( h0 Z5 {' M' F●数据压缩以块为单位，压缩算法由用户指定并可随时变更；
: {6 s# G) Y4 ]' z# D' o●叶子节点可能合并或者分裂；
●所有叶子节点基本上是均匀的，随机地分布在多台ChunkServer机器上；
●通常情况下每个叶子节点有2～3个副本；
●叶子节点是负载平衡和任务调度的基本单元；
●支持布隆过滤器的过滤。
* Q7 P* l4 \& n+ t增量数据的数据结构如下：
●增量数据按照时间从旧到新划分为多个版本；
" ~1 s# E& d/ O  y- O! j3 P/ S/ A9 h●最新版本的数据为一颗内存中的B+树，称为活跃MemTable；
●用户的修改操作写入活跃MemTable，到达一定大小后，原有的活跃MemTable
将被冻结，并开启新的活跃MemTable接受修改操作；
●冻结的MemTable将以SSTable的形式转储到SSD中持久化；
2 G: l/ L* H0 }3 ]) U●每个SSTable内部按主键范围有序划分为多个块并内建块索引，每个块的大小
通常为4～8KB并内建块内行索引，一般不压缩；
  X  ~# _; C8 s& y% C" H9 z' W1 d" ?! U●UpdateServer支持主备，增量数据通常为2个副本，每个副本支持RAID1存储。
8.4.3　可靠性与可用性
分布式系统需要处理各种故障，例如，软件故障、服务器故障、网络故障、数
+ b0 k; t% w4 F: C据中心故障、地震、火灾等。与其他分布式存储系统一样，OceanBase通过冗余的方
7 g1 A7 e' M9 ?& s/ I1 `) o1 P4 C式保障了高可靠性和高可用性。方法如下所示：
6 e4 w$ S" _' s% T& a1 U. M  g●OceanBase在ChunkServer中保存了基线数据的多个副本。单集群部署时一般会
: N; x) j( s! l. K9 g. p( b配置3个副本；主备集群部署时一般会配置每个集群2个副本，总共4个副本。
●OceanBase在UpdateServer中保存了增量数据的多个副本。UpdateServer主备模
式下主备两台机器各保存一个副本，另外，每台机器都通过软件的方式实现了
$ g5 V1 d- ]5 G4 \RAID1，将数据自动复制到多块磁盘，进一步增强了可靠性。
0 @' K, N/ f. U' s" t●ChunkServer的多个副本可以同时提供服务。Bigtable以及HBase这样的系统服务
0 K$ O, t! _4 u2 c! y节点不冗余，如果服务器出现故障，需要等待其他节点恢复成功才能提供服务，而
OceanBase多个ChunkServer的子表副本数据完全一致，可以同时提供服务。
7 T3 g  k4 n& |/ {●UpdateServer主备之间为热备，同一时刻只有一台机器为主UpdateServer提供写
服务。如果主UpdateServer发生故障，OceanBase能够在几秒中之内（一般为3～5
+ \5 @; ?" Q, e+ l秒）检测到并将服务切换到备机，备机几乎没有预热时间。
" N+ c+ B( Z: N5 N$ x+ S& l●OceanBase存储多个副本并没有带来太多的成本。当前的主流服务器的磁盘容
8 d( D- p% _, O+ q( ]3 B量通常是富余的，例如，300GB×12或600GB×12的服务器有3TB或6TB左右的磁盘总
; M3 B; E8 u$ n5 G1 C容量，但存储系统单机通常只能服务少得多的数据量。
8.4.4　读写事务
$ d+ W' |7 W& X( ?. [: {( m* v7 F- n& S8 c在OceanBase系统中，用户的读写请求，即读写事务，都发给MergeServer。
MergeServer解析这些读写事务的内容，例如词法和语法分析、schema检查等。对于
只读事务，由MergeServer发给相应的ChunkServer分别执行后再合并每个ChunkServer
0 O7 a+ U9 ~9 r3 V的执行结果；对于读写事务，由MergeServer进行预处理后，发送给UpdateServer执
) h) ^& T# N4 D( ]; v" v行。
8 H: w% }9 S4 R只读事务执行流程如下：
1）MergeServer解析SQL语句，词法分析、语法分析、预处理（schema合法性检
5 Y3 K, Q, u4 I% t- i% s$ T% D) z查、权限检查、数据类型检查等），最后生成逻辑执行计划和物理执行计划。
; K9 A3 T) W! v) r5 |! b3 |$ g1 n2）如果SQL请求只涉及单张表格，MergeServer将请求拆分后同时发给多台
ChunkServer并发执行，每台ChunkServer将读取的部分结果返回MergeServer，由
* j* d# w6 z( A4 c4 @2 X& _/ BMergeServer来执行结果合并。
6 @2 L$ y  v) X/ P" B$ b( a3）如果SQL请求涉及多张表格，MergeServer还需要执行联表、嵌套查询等操
作。
# ]3 }; t1 I' Y3 n$ C7 K4）MergeServer将最终结果返回给客户端。
  [) a# Y& V/ P5 X读写事务执行流程如下：
1）与只读事务相同，MergeServer首先解析SQL请求，得到物理执行计划。
- G7 c5 G# Z% P2）MergeServer请求ChunkServer获取需要读取的基线数据，并将物理执行计划和
& }% u& {5 s- B, b+ c  s7 F5 Q基线数据一起传给UpdateServer。
, B2 g2 [* R! s2 E, b3）UpdateServer根据物理执行计划执行读写事务，执行过程中需要使用
MergeServer传入的基线数据。
4）UpdateServer返回MergeServer操作成功或者失败，MergeServer接着会把操作
( y/ v; I9 g. `( |3 S3 B结果返回客户端。
例如，假设某SQL语句为："update t1 set c1=c1+1 where rowkey=1"，即将表格t1
3 R2 _1 i6 I9 L; W2 K中主键为1的c1列加1，这一行数据存储在ChunkServer中，c1列的值原来为2012。那
么，MergeServer执行SQL时首先从ChunkServer读取主键为1的数据行的c1列，接着将
读取结果（c1=2012）以及SQL语句的物理执行计划一起发送给UpdateServer。
7 |1 j' o1 m) S0 f5 QUpdateServer根据物理执行计划将c1加1，即将c1变为2013并记录到内存表
（MemTable）中。当然，更新内存表之前需要记录操作日志。
8.4.5　单点性能
3 i: i* o; H, b5 Z5 J0 |OceanBase架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。
当然，这个架构也有一个明显的缺陷：UpdateServer单点，这个问题限制了
4 t2 v% ]$ G6 E: H, H/ x3 j, HOceanBase集群的整体读写性能。
下面从内存容量、网络、磁盘等几个方面分析UpdateServer的读写性能。其实大
5 D9 ]' z8 o) i  A1 N部分数据库每天的修改次数相当有限，只有少数修改比较频繁的数据库才有每天几
; U& o9 i; C  f+ I# m! b亿次的修改次数。另外，数据库平均每次修改涉及的数据量很少，很多时候只有几
9 X1 [4 _( W& }" J' g) |6 }十个字节到几百个字节。假设数据库每天更新1亿次，平均每次需要消耗100字节，
每天插入1000万次，平均每次需要消耗1000字节，那么，一天的修改量为：1亿
×100+1000万×1000=20GB，如果内存数据结构膨胀2倍，占用内存只有40GB。而当
; A1 S. \/ Y* p+ H前主流的服务器都可以配置96GB内存，一些高档的服务器甚至可以配置192GB、
384GB乃至更多内存。
从上面的分析可以看出，UpdateServer的内存容量一般不会成为瓶颈。然而，服
务器的内存毕竟有限，实际应用中仍然可能出现修改量超出内存的情况。例如，淘
8 x" n! N5 c0 k0 o2 ^0 T2 G8 I宝双11网购节数据库修改量暴涨，某些特殊应用每天的修改次数特别多或者每次修
1 U+ O/ B1 I4 i6 _改的数据量特别大，DBA数据订正时一次性写入大量数据。为此，UpdateServer设计
; S" l, L; F: v; K. \( u7 z) A实现了几种方式解决内存容量问题，UpdateServer的内存表达到一定大小时，可自动
或者手工冻结并转储到SSD中，另外，OceanBase支持通过定期合并或者数据分发的
& h5 I9 y  B2 F方式将UpdateServer的数据分散到集群中所有的ChunkServer机器中，这样不仅避免了
UpdateServer单机数据容量问题，还能够使得读取操作往往只需要访问UpdateServer
, h% I0 Q4 [: |- o* q0 y内存中的数据，避免访问SSD磁盘，提高了读取性能。
1 D6 i+ N, p# Q0 m* _: J' Z从网络角度看，假设每秒的读取次数为20万次，每次需要从UpdateServer中获取
100字节，那么，读取操作占用的UpdateServer出口带宽为：20万×100=20MB，远远
4 T' C6 N6 ]8 a" s5 f# a没有达到千兆网卡带宽上限。另外，UpdateServer还可以配置多块千兆网卡或者万兆
# Y0 u4 V6 o: q* Z* }网卡，例如，OceanBase线上集群一般给UpdateServer配置4块千兆网卡。当然，如果
软件层面没有做好，硬件特性将得不到充分发挥。针对UpdateServer全内存、收发的
' z* t$ q+ i$ U: o5 ]  O网络包一般比较小的特点，开发团队对UpdateServer的网络框架做了专门的优化，大
) f  Y& O* c. n* Q5 D  T5 Z; T+ B大提高了每秒收发网络包的个数，使得网络不会成为瓶颈。
( T5 V& O' K5 ^( r4 z9 u从磁盘的角度看，数据库事务需要首先将操作日志写入磁盘。如果每次写入都
需要将数据刷入磁盘，而一块SAS磁盘每秒支持的IOPS很难超过300，磁盘将很快成
( T) |' e' f- y! M+ y4 A1 _9 @: B0 t为瓶颈。为了解决这个问题，UpdateServer在硬件上会配置一块带有缓存模块的RAID
0 E7 t9 z& G2 u- {1 K( v2 c% z# }/ |卡，UpdateServer写操作日志只需要写入到RAID卡的缓存模块即可，延时可以控制在
0 j: y7 K0 w# U9 t. {* l1毫秒之内。RAID卡带电池，如果UpdateServer发生故障，比如机器突然停电，RAID
7 U5 N  \4 s- d" i, {8 h卡能够确保将缓存中的数据刷入磁盘，不会出现丢数据的情况。另外，UpdateServer
还实现了写事务的成组提交机制，将多个用户写操作凑成一批一次性提交，进一步
减少磁盘IO次数。
8.4.6　SSD支持
* J  m/ R5 R  D4 s7 V磁盘随机IO是存储系统性能的决定因素，传统的SAS盘能够提供的IOPS不超过
300。关系数据库一般采用高速缓存（Buffer Cache） [1] 的方式缓解这个问题，读取操
7 _* r+ a9 |$ T作将磁盘中的页面缓存到高速缓存中，并通过LRU或者类似的方式淘汰不经常访问
的页面；同样，写入操作也是将数据写入到高速缓存中，由高速缓存按照一定的策
略将内存中页面的内容刷入磁盘。这种方式面临一些问题，例如，Cache冷启动问
' p: z! ]6 |/ s. _$ n' z' c" G题，即数据库刚启动时性能很差，需要将读取流量逐步切入。另外，这种方式不适
6 N( h4 N2 \5 W/ d7 w4 _' j合写入特别多的场景。
5 k" g2 z$ d" ?4 D0 h! j最近几年，SSD磁盘取得了很大的进展，它不仅提供了非常好的随机读取性能，
功耗也非常低，大有取代传统机械磁盘之势。一块普通的SSD磁盘可以提供35000
4 z. n' a. |7 F9 ]' GIOPS甚至更高，并提供300MB/s或以上的读出带宽。然而，SSD盘的随机写性能并不
理想。这是因为，尽管SSD的读和写以页（page，例如4KB，8KB等）为单位，但
; j: ]& d  J3 lSSD写入前需要首先擦除已有内容，而擦除以块（block）为单位，一个块由若干个
& X0 B; b# ?% s连续的页组成，大小通常在512KB～2MB。假如写入的页有内容，即使只写入一个
字节，SSD也需要擦除整个512KB～2MB大小的块，然后再写入整个页的内容，这就
* e1 T9 w' y# D1 c9 {9 u是SSD的写入放大效应。虽然SSD硬件厂商都针对这个问题做了一些优化，但整体上
看，随机写入不能发挥SSD的优势。
OceanBase设计之初就认为SSD为大势所趋，整个系统设计时完全摒弃了随机
  h6 l& T& A- ]# b  S- s$ t写，除了操作日志总是顺序追加写入到普通SAS盘上，剩下的写请求都是对响应时间
要求不是很高的批量顺序写，SSD盘可以轻松应对，而大量查询请求的随机读，则发
3 R7 E3 l! l0 b; o% O8 b挥了SSD良好的随机读的特性。摒弃随机写，采用批量的顺序写，也使得固态盘的使
$ @' j, E9 F. {" O用寿命不再成为问题，主流SSD盘使用MLC SSD芯片，而MLC号称可以擦写1万次
& c( \  C2 f2 E8 f（SLC可以擦写10万次，但因成本高而较少使用），即使按最保守的2500次擦写次数
计算，而且每天全部擦写一遍，其使用寿命为2500/365=6.8年。
: r# j. b$ P5 }( T# S% |# B[1]这个机制在Oracle数据库中称为Buffer Cache，在MySQL数据库中称为Buffer Pool，
用于缓存磁盘中的页面。
5 A  R0 b0 e/ X0 L" R4 f5 o; P8.4.7　数据正确性
' j" K1 D3 l' h3 M7 i数据丢失或者数据错误对于存储系统来说是一种灾难。前面8.4.1节中已经提
到，OceanBase设计为强一致性系统，设计方案上保证不丢数据。然而，TCP协议传
; s" G$ y' E" I2 o1 `0 H输、磁盘读写都可能出现数据错误，程序Bug则更为常见。为了防止各种因素导致的
( e# q6 V0 o' Z数据损毁，OceanBase采取了以下数据校验措施：
' ~) Y% Z. M2 f3 O●数据存储校验。每个存储记录（通常是几KB到几十KB）同时保存64位CRC校
/ N$ u8 }& n  ~* `/ T% O验码，数据被访问时，重新计算和比对校验码。
●数据传输校验。每个传输记录同时传输64位CRC校验码，数据被接收后，重新
, v* e" d$ K4 I, _5 Y计算和比对校验码。
: T9 p+ N7 j7 s●数据镜像校验。UpdateServer在机群内有主UpdateServer和备UpdateServer，集
群间有主集群和备集群，这些UpdateServer的内存表（MemTable）必须保持一致。为
此，UpdateServer为MemTable生成一个校验码，MemTable每次更新时，校验码同步
更新并记录在对应的操作日志中。备UpdateServer收到操作日志并重放到MemTable
  ]! j% J0 M. }4 e+ J7 L时，也同步更新MemTable校验码并与接收到的校验码对照。UpdateServer重新启动后
重放日志恢复MemTable时也同步更新MemTable校验码并与保存在每条操作日志中的
校验码对照。
●数据副本校验。定期合并时，新的子表由各个ChunkServer独立地融合旧的子表
) R8 c5 l* m, j; [中的SSTable与冻结的MemTable而生成，如果发生任何异常或者错误（比如程序
bug），同一子表的多个副本可能不一致，则这种不一致可能随着定期合并而逐步累
: t$ O  [/ j/ H$ x. Z积或扩散且很难被发现，即使被察觉，也可能因为需要追溯较长时间而难以定位到
4 H6 f) }! p- y% ~, q- B源头。为了防止这种情况出现，ChunkServer在定期合并生成新的子表时，也同时为
每个子表生成一个校验码，并随新子表汇报给RootServer，以便RootServer核对同一
/ S$ N1 F6 d# z9 I" H) |子表不同副本的校验码。
8.4.8　分层结构
OceanBase对外提供的是与关系数据库一样的SQL操作接口，而内部却实现成一
: m; K4 @" a+ S3 j) }1 D! Z个线性可扩展的分布式系统。系统从逻辑实现上可以分为两个层次：分布式存储引
5 g- c' P0 F9 Q' H0 U1 ?9 C擎层以及数据库功能层。
OceanBase一期只实现了分布式存储引擎，这个存储引擎支持如下特性：
5 V4 ^5 a5 X; u; A4 {6 B' ~●支持分布式数据结构，基线数据逻辑上构成一颗分布式B+树，增量数据为内
存中的B+树；
0 S; a6 _4 i' `& X1 z" N& Q●支持目前OceanBase的所有分布式特性，包括数据分布、负载均衡、主备同
步、容错、自动增加/减少服务器等；
- c5 k! V& Y$ h: A* V8 F4 g●支持根据主键更新、插入、删除、随机读取一条记录，另外，支持根据主键范
3 B1 a2 h9 o; N  |围顺序查找一段范围的记录。
1 s8 Q; K4 ^' r  g1 G' m1 Z( u二期的OceanBase版本在分布式存储引擎之上增加了SQL支持：
●支持SQL语言以及MySQL协议，MySQL客户端可以直接访问；
  l3 z6 n( y; {8 P●支持读写事务；
" U; H- r2 [9 b) w●支持多版本并发控制；
# F; {+ w  @) B; m- ^●支持读事务并发执行。
4 g! v- V* R+ \9 f! Y& d从另外一个角度看，OceanBase融合了分布式存储系统和关系数据库这两种技
3 g* h" M, [1 I4 x术。通过分布式存储技术将基线数据分布到多台ChunkServer，实现数据复制、负载
均衡、服务器故障检测与自动容错，等等；UpdateServer相当于一个高性能的内存数
据库，底层采用关系数据库技术实现。我们后来发现，有一个号称“世界上最快的内
4 Z8 p; C: t6 M* N存数据库”MemSQL采用了和OceanBase UpdateServer类似的设计，在拥有64个CPU核
. J( I  @& ~6 \5 O心的服务器上实现了每秒150万次单行写事务。OceanBase相当于
GFS+MemSQL,ChunkServer的实现类似GFS,UpdateServer的实现类似MemSQL，目标是
成为可扩展的、支持每秒百万级单行事务操作的分布式数据库。
* J- G/ X, x6 _6 C后续将分为两章，分别讲述OceanBase分布式存储引擎层以及数据库功能层的实
现细节。
5 F, i# @* _. g, i& m