|
7.2 Microsoft SQL Azure
9 E E2 V" k! IMicrosoft SQL Azure是微软的云关系型数据库,后端存储又称为云SQL4 X7 c' u/ \; j& R+ Q; M
Server(Cloud SQL Server)。它构建在SQL Server之上,通过分布式技术提升传统关
4 Y) S2 a/ i' p: H- w6 S: t系型数据库的可扩展性和容错能力。) ~+ l$ @5 t+ I, H) x. I1 Z
7.2.1 数据模型
& ~ q6 a# s9 B A# { N1.逻辑模型" g. d3 C5 [7 A
云SQL Server将数据划分为多个分区,通过限制事务只能在一个分区执行来规避- I M2 _; J1 C+ i2 U- |
分布式事务。另外,它通过主备复制(Primary-Copy)协议将数据复制到多个副本,5 v% R j/ m0 q6 L. ?% b
保证高可用性。
# ]- H9 j8 A T5 y8 I云SQL Server中一个逻辑数据库称为一个表格组(table group),它既可以是有
. a% K2 j' I# x9 e8 m" d3 i& p5 J$ J主键的,也可以是无主键的,本节只讨论有主键的表格组。如果一个表格组是有主
% x, h$ a, u* X5 S$ a键的,要求表格组中所有的表格都有一个相同的列,称为划分主键(partitioning: X9 w3 }! E% q* [2 W3 o" l
key)。图中的表格组包含两个表格,顾客表(Customers)和订单表(Orders),划5 v1 M( T4 q- D; a
分主键为顾客ID(Customers表中的Id列)。如图7-2所示。' h# ?4 M5 S3 P
图 7-2 云SQL Server数据模型! C: \" `) r" U! s0 A a1 p N
划分主键不需要是表格组中每个表格的唯一主键。图7-2中,顾客ID是顾客表的, M4 i6 o) J( P) h$ X7 ?# O* Z
唯一主键,但不是订单表的唯一主键。同样,划分主键也不需要是每个表格的聚集
* Z* I4 d. @0 y索引,订单表的聚集索引为组合主键<顾客ID,订单ID>(<Id,Oid>)。2 Q+ ~0 { z+ U$ v; d* d
表格组中所有划分主键相同的行集合称为行组(row group)。顾客表的第一行
" L( u8 M* {6 @+ G/ b以及订单表的前两行的划分主键均为34,构成一个行组。云SQL Server只支持同一个7 t6 K8 R7 P! o; ]/ R5 a0 ^
行组内的事务,这就意味着,同一个行组的数据逻辑上会分布到一台服务器。" I' q. f: M3 G" ~0 ]
如果表格组是有主键的,云SQL Server支持自动地水平拆分表格组并分散到整个0 z; v6 T+ \: L$ H8 T0 `, `
集群。同一个行组总是被一台物理的SQL Server服务,从而避免了分布式事务。这样
7 l/ \) F+ J% O7 d% I的好处是避免了分布式事务的两个问题:阻塞及性能,当然,也限制了用户的使用8 d- Q1 z# L; d- C3 B
模式。
* _8 r+ O ^9 P3 E. r4 b3 N5 N5 ^只读事务可以跨多个行组,但事务隔离级别最多支持读取已提交(read-- o/ s4 _4 P% i( @" m
committed)。
. ?1 c4 z: m$ {2.物理模型
- z6 B/ R% E. F7 C7 j* m: H ?% v在物理层面,每个有主键的表格组根据划分主键列有序地分成多个数据分区, F+ |) K( s5 i
(partition)。这些分区之间互相不重叠,并且覆盖了所有的划分主键值。这就确保1 {- G% W& f. k1 U) _5 P
了每个行组属于一个唯一的分区。
. L0 G4 F/ S8 n0 z! p6 v9 p# }8 h: s8 J分区是云SQL Server复制、迁移、负载均衡的基本单位。每个分区包含多个副本
$ g2 a) `$ o, {+ ](默认为3),每个副本存储在一台物理的SQL Server上。由于每个行组属于一个分
3 r' o9 o2 N' ?9 g [区,这也就意味着每个行组的数据量不能超过分区允许的最大值,也就是单台SQL; N d! @8 \- o/ i
Server的容量上限。9 h6 v( n* R; L' h) A
一般来说,同一个交换机或者同一个机架的机器同时出现故障的概率较大,因% E1 r; t; a& e/ g2 y& n
而它们属于同一个故障域(failure domain)。云SQL Server保证每个分区的多个副本: W3 o) f% u/ H/ Z5 l
分布到不同的故障域。每个分区有一个副本为主副本(Primary),其他副本为备副
+ f# \7 L1 n2 e9 L" v本(Secondary)。主副本处理所有的查询,更新事务并以操作日志的形式将事务同 M) h; V- l9 \
步到备副本,备副本接收主副本发送的事务日志并应用到本地数据库。目前,备副8 c- l+ J4 y3 v( Z2 }
本不支持读操作,当然,这是很容易实现的,只是可能读取到过期的数据。
& h! {: R; S" o+ j' j7 M如图7-3所示,有四个逻辑分区PA、PB、PC、PD,每个分区有一个主副本和两$ [& [* c; J/ n% h
个备副本。例如,PA有一个主副本PA P 以及两个备副本PA S1 和PA S2 。每台物理SQL
% m$ z9 `7 E _% UServer数据库混合存放了主副本和备副本。如果某台机器发生故障,它上面的分区能
8 _( W7 |0 M# X4 i* ~% j+ [6 z, N够很快分散到其他活着的机器上。
" U( `6 o) B1 y' U0 Q, H图 7-3 云SQL Server物理模型* m" ?! f$ D+ ^) ?
分区划分是动态的,如果某个分区超过了允许的最大分区大小或者负载太高,' s% _1 W0 @4 y& N
这个分区将分裂为两个分区。假设分区A的主副本在机器X,它的备副本在机器Y和
6 {" \% _: S% @" wZ。如果分区A分裂为A1和A2,每个副本都需要相应地分裂为两段。为了更好地进行
4 Z% m1 s' ?0 u o负载均衡,每个副本分裂前后的角色可能不尽相同。例如,A1的主副本仍然在机器" G. \! T1 E/ S1 U1 Z
X,备副本在机器Y和机器Z;而A2的主副本可能在机器Y,备副本在机器X和机器2 t* r w8 i! N) }9 m; M
Z。
2 S% E) \6 L. X% ^7.2.2 架构
5 G: c( j# \3 w& U: q. P云SQL Server分为四个主要部分:SQL Server实例、全局分区管理、协议网关、0 i3 o, o" z3 W2 [6 i- a8 ]
分布式基础部件,如图7-4所示。
4 Y- Z; ?: d7 I* E图 7-4 云SQL Server的分层架构, y6 _9 N/ s: }# V2 Q
下面分别介绍这几个部分:' N% S4 B t4 A: K1 v
●每个SQL Server实例是一个运行着SQL Server的物理进程。每个物理数据库包
4 }" |! i! F" _( N含多个子数据库,它们之间互相隔离。子数据库是一个分区,包含用户的数据以及; C9 _' z5 h4 T6 r! P0 \
schema信息。8 n# q0 J3 k% d& U
●全局分区管理器(Global Partition Mana- ger)维护分区映射表信息,包括每个
7 l: M6 e, J1 w7 @2 Y% s0 I分区的主键范围,每个副本所在的服务器,以及每个副本的状态,包括副本当前是6 T3 j* q X$ T" u
主还是备,前一次是主还是备,正在变成主,正在被拷贝或者正在被追赶。当服务
2 L( C. Q3 f' b! e, y器发生故障时,分布式基础部件检测并确保服务器故障后通知全局分区管理器。全
7 _& @3 e+ S9 u* s- m* k" f局分区管理器接着执行重新配置操作。另外,全局分区管理器监控集群中的SQL: C# F z! x5 ? M8 ]! O
Server工作机,执行负载均衡,副本拷贝等管理操作。& R7 F& n6 {& f& Z; n
●协议网关(Protocol Gateway)负责将用户的数据库连接请求转发到相应的主分
+ `9 q) V2 b3 N" _* S区上。协议网关通过全局分区管理器获取分区所在的SQL Server实例,后续的读写事
# F/ p X) M7 {9 D G0 E; ?务操作都在网关与SQL Server实例之间进行。
4 Q) I( C! |7 e●分布式基础部件(Distributed Fabric)用于维护机器上下线状态,检测服务器
8 u- ? F# g7 E9 {0 f1 a故障并为集群中的各种角色执行选举主节点操作。它在每台服务器上都运行了一个
2 v. t3 f% \9 f; |' E9 M/ `1 C3 j守护进程。
7 ?% u" @+ P( y2 n7 @% v; B7.2.3 复制与一致性
# ^5 M: q2 A0 m$ |" {6 H- E云SQL Server采用"Quorum Commit"的复制协议,用户数据存储三个副本,至少, m: V; Q4 G# F! X, F, Z" s* n* Z
写成功两个副本才可以返回客户端成功。如图7-5所示,事务T的主副本分区生成操3 ?& R4 i9 g* j
作日志并发送到备副本。如果事务T回滚,主副本会发送一个ABORT消息给备副. V7 d+ v1 p }1 B& d7 A6 u2 \
本,备副本将删除接收到的T事务包含的修改操作。如果事务T提交,主副本会发送
# Z4 D, Y9 b; F5 f7 lCOMMIT消息给备副本,并带上事务提交顺序号(Commit Sequence Number,CSN),$ H: Y1 w5 R! K% s% y9 @: E/ f- b
每个备副本会把事务T的修改操作应用到本地数据库并发送ACK消息回复主副本。如
2 q4 t+ y! f+ X: T7 U7 [果主副本接收到一半以上的成功ACK(包含主副本自身),它将在本地提交事务并( Z, Q& L4 @) y& M
成功返回客户端。
- L4 |8 S0 ]0 u/ B1 L/ {图 7-5 云SQL Server主备同步
( K0 G9 D- i5 Z# A! y# K+ ~& U某些备副本可能出现故障,恢复后将往主副本发送本地已经提交的最后一个事$ Q6 t8 Q- z6 @: r8 `$ q/ v5 V
务的提交顺序号。如果两者相差不多,主副本将直接发送操作日志给备副本;如果) D- G0 Y- T4 \: D0 _' [! D+ O4 J# C
两者相差太多,主副本将首先把数据库快照传给备副本,再把快照点之后的操作日
# B0 C+ m& O4 O4 S志传给备副本。
& o) ?1 p x% m( j$ {% v: I主副本与备副本之间传送逻辑操作日志,而不是对磁盘物理页的redo&undo日
0 Q3 Z6 l. @8 Y' o7 O& c. N. l8 F' D志。数据库索引及schema相关操作(如创建,删除表格)也通过操作日志发送。实
- ~4 }6 t& r) ?" Q0 X7 E% C2 A践过程中发现了一些硬件问题,比如某些网卡会表现出错误的行为,因此对主备之& W3 d+ v- B$ |; ^! q
间的所有消息都会做校验(checksum)。同样,某些磁盘会出现“位翻转”错误,因$ n) m! x- u6 A h# L3 o
此,对写入到磁盘的数据也做校验。) M+ Z& R* ^: N( n& i
7.2.4 容错; a* A0 Z) U: S2 p8 A# ?9 m8 ^& w
如果数据节点发生了故障,需要启动宕机恢复过程。每个SQL Server实例最多服
9 _) t/ v/ u' N8 S) [5 X务650个逻辑分区,这些分区可能是主副本,也可能是备副本。全局分区管理器统一- p/ p' N: X. |* H3 r7 W+ w2 M* x
调度,每次选择一个分区执行重新配置(Reconfiguration)。如果出现故障的分区是
8 x5 C6 V7 w& b" x9 ~, w备副本,全局分区管理器首先选择一台负载较轻的服务器,接着从相应的主副本分+ N& i i) I/ J! Z
区拷贝数据来增加副本;如果出现故障的分区是主副本,首先需要从其他副本中选
/ k, q6 z6 s7 ~4 ^, e择一个最新的备副本作为新的主副本,接着选择一台负载较轻的机器增加备副本。
' j6 U2 m- h! f; @2 h. M6 u由于云SQL Server采用"Quorum Commit"复制协议,如果每个分区有三个副本,至少5 K4 J2 s9 a, l5 z
保证两个副本写入成功,主副本出现故障后选择最新的备副本可以保证不丢数据。, Q! H0 s- G X
全局分区管理器控制重新配置任务的优先级,否则,用户的服务会受到影响。
6 l" q2 p2 N/ A ^; T, q/ \$ y. z比如某个数据分片的主副本出现故障,需要尽快从其他副本中选择备副本切换为主* e8 M9 e2 S& h& t; O" n% u. U# O
副本;某个数据分片只有一个副本,需要优先复制。另外,某些服务器可能下线很
}# R2 y; s7 K5 e短一段时间后重新上线,为了避免过多无用的数据拷贝,这里还需要配置一些策
' ^! O& v- o' Y8 f# P略:比如只有两个副本的状态持续较长一段时间(SQL Azure默认配置为两小时)才' U9 j; e; T. G5 z2 I( c
开始复制第三个副本。- F( `0 _/ f4 F9 l! x5 C
全局分区管理器也采用"Quorum Commit"实现高可用性。它包含七个副本,同一. ?9 F, x. g+ u3 q9 P
时刻只有一个副本为主,分区相关的元数据操作至少需要在四个副本上成功。如果
9 p( F; K# f! ~- o( E' m全局分区管理器主副本出现故障,分布式基础部件将负责从其他副本中选择一个最
& [( C J+ U$ j- g% W新的副本作为新的主副本。
: V+ u( ^- o8 ]5 X# Q. c8 ]8 |7.2.5 负载均衡$ n& y% T5 V6 \% B% B L8 r
负载均衡相关的操作包含三种:副本迁移以及主备副本切换。新的服务器节点3 u9 |! W# ~ e+ `% P$ _" `
加入时,系统内的分区会逐步地迁移到新节点,这里需要注意的是,为了避免过多
" `- k1 ?! Y# O0 P7 e4 A的分区同时迁入新节点,全局分区管理器需要控制迁移的频率,否则系统整体性能
v- B: b. s- b1 u1 L9 |/ Q可能会下降。另外,如果主副本所在服务器负载过高,可以选择负载较低的备副本
4 G( q4 y. Y" z替换为主副本提供读写服务。这个过程称为主备副本切换,不涉及数据拷贝。+ m( S3 D' K' J, l+ e/ e/ w
影响服务器节点负载的因素包括:读写次数,磁盘/内存/CPU/IO使用量等。全局
0 L2 s& Q+ Y! ~# Y1 v0 A7 ?- r分区管理器会根据这些因素计算每个分区及每个SQL Server实例的负载。" Q9 q2 [( y3 [2 F+ Y1 d/ O: T
7.2.6 多租户
2 r* y3 `$ z/ i0 O% d' y- H, o4 j云存储系统中多个用户的操作相互干扰,因此需要限制每个SQL Azure逻辑实例
( `$ A( f4 N3 \使用的系统资源:
: h# z3 [, x) m% a9 S3 O1)操作系统资源限制,比如CPU、内存、写入速度,等等。如果超过限制,将0 m; [( X9 X/ H9 i y0 J3 g
在10秒内拒绝相应的用户请求;
( @* u. x, ]/ v# D5 ~% j6 ~5 M2)SQL Azure逻辑数据库容量限制。每个逻辑数据库都预先设置了最大的容
% p, @" I$ T# M/ r" R' j! m量,超过限制时拒绝更新请求,但允许删除操作;0 l5 o* L8 h- X5 u% x6 [
3)SQL Server物理数据库数据大小限制。超过该限制时返回客户端系统错误,
' n' ^# H! a5 s% E7 _此时需要人工介入。
- E: s7 q1 m9 C1 T4 G) i0 J! @7.2.7 讨论
4 E6 v) p7 u( U+ K* zMicrosoft SQL Azure将传统的关系型数据库SQL Server搬到云环境中,比较符合
1 ^" i- R, ]7 ~4 b用户过去的使用习惯。当然,云SQL Server与单机SQL Server还是有一些区别:
/ @' a, X3 a5 E- C2 O2 e' Z6 }●不支持的操作:Microsoft Azure作为一个针对企业级应用的平台,尽管尝试支
2 M& d: B3 R1 b8 v2 v% X持尽量多的SQL特性,仍然有一些特性无法支持。比如USE操作:SQL Server可以通* ]; q) P5 N& c' f% `! ?5 ] b
过USE切换数据库,不过在SQL Azure不支持,这是因为不同的逻辑数据库可能位于
! @& b c* [. u& G( I; o- z9 K不同的物理机器。( t3 R% v% L: k/ E) P4 J! `% j9 M8 h
●观念转变:对于开发人员,需要用分布式系统的思维开发程序,比如一个连接1 \: ], @8 ]+ M7 x, f4 H
除了成功、失败还有第三种不确定状态:云端没有返回操作结果,操作是否成功我) l7 H2 f2 F, v
们无从得知;对于DBA,数据库的日常维护,比如升级、数据备份等工作都移交给4 O, r0 n' [7 I# n% C
了微软,可能会有更多的精力关注业务系统架构。0 t, p- q3 {. |$ @
相比Azure Table Storage,SQL Azure在扩展性上有一些劣势,例如,单个SQL
; K) _# n; f% Q; G. H) c* f; I6 HAzure实例大小限制。Azure Table Storage单个用户表格的数据可以分布到多个存储节) I- e. D; c1 }+ Q5 i# O4 H7 m
点,数据总量几乎没有限制;而单个SQL Azure实例最大限制为50GB,如果用户的数4 J/ f- [- m3 W: h7 R. f8 k% V5 ^
据量大于最大值,需要用户在应用层对数据库进行水平或者垂直拆分,使用起来比
7 ^5 t* R, [! s$ ^( S I0 D较麻烦。8 }5 E1 y) J+ s A" ]9 Y
. X* W+ p1 }- l4 Z% [6 o* P
; f5 y0 |! e/ U) ~# c3 V
|
|