爱吱声
标题: Sharding中Chunks的切分和迁移 [打印本页]
作者: shengnan007 时间: 2012-9-18 12:37
标题: Sharding中Chunks的切分和迁移
在上一篇文章“MongoDB架构概览”中，我们简单介绍了一下MongoDB中的shard，接下来，我们详细的讲解一下MongoDB的sharding model。
% S% F2 _8 x' c; m2 X' `; ~) D% ~) ^. W9 z1 O, j( b# q9 @
当MongoDB的一个 collection 数据量太大时，我们按照shard key，把该collection分成多个chunks，多个chunks聚集在一起，组成了一个shard。) y; V; q$ D: \' v# j; g) k. ~% b
7 T# I6 G7 a" ~% E; e: |# b5 P6 {0 B 每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。如图2-1所示。3 e/ X4 G; u. N5 c8 J" z+ t6 y
# K! M3 _: M( \$ ~, n
& J2 F+ y2 h$ N7 ]0 A/ n; P6 p! e* T
. R4 D/ x) ]8 j图2-1 shard key、chunk和shard的关系
, n* [; {& R* n" ~" o2 q% G8 w 通过图2-1我们可以看到，数据在整个key space上的分布是不均匀的，这就导致了chunk中存储的数据量会不均匀。如果一个chunk中存储的数据太多了怎么办？多个chunks构成了一个shard，因此shard中的数据量也会不均匀，如果一个shard中存储的数据太多了怎么办？. X0 f# B, u# L* t
) x( u3 B* F q1 Q& P 上一篇文章中，我们提到了解决办法。一个 chunk最多能够存储64MB的数据。当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
5 d2 |- W' i; S/ X; x- r$ U$ V5 s- D7 p
当用户产生存储数据的需求时，把插入数据的请求发送给mongos，mongos先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers，同时，mongos会根据历史上插入的每条数据的平均大小，判断这条数据插入到这个shard server的某个chunk后，是否会导致这个chunk的大小近似达到或者超过64M。
0 n/ ]0 h) D( i3 j K( J T8 D; D n5 n& p8 I7 ]- i
如果mongos经过判断，发现chunk在插入这条数据之后，会近似达到或者超过64M，那么就说明这个chunk需要进行切分。Mongos就要和这个chunk所在的shard server联系，并发送一个切分chunk的请求。
8 D6 k9 C Y* P K& j8 _4 _, {) l6 g8 `; r
Shard server接收到mongos发送的请求之后，首先查询这个chunk的shard key range，然后根据这个key range，计算一个midpoint，然后把chunk从midpoint处分为两部分。同时，把这个变化通知到config server。: q7 F" a! A, ?2 M; E0 f* C; L
* N8 H4 b$ D4 x2 B- L8 V+ A" H 请注意，这里只是切分chunk，切分后的chunk仍然在这个shard中。随着系统的运行，chunk中的数据量在增长，虽然通过切分操作，保持每个chunk中的数据不超过64M，但是， shard 中包含的 chunk 数量在增长。如果 shard server中的数据太多了怎么办？MongoDB通过chunk的迁移，来均衡shard servers之间的数据量。
1 I! G7 W, ~) o) a3 B4 t# M' V2 l: q1 b; m2 v. D c* ]
在mongos上运行着一个“balancer”进程，这个进程的任务是确保每个shard servers上的数据规模大致相同。当数据规模不均衡的状态被检测到之后，这个balancer会联系那个数据较多的shard，发出一个chunk迁移的命令。1 R& D. [$ M9 f6 C7 u
, s: {4 q5 {/ t* T3 F
如何界定什么是数据规模不均衡呢？如果存储chunks最多的shard server，比存储chunks最少的shard server，chunks的个数之差超过预定的一个阈值n，balancer就向这个 shard server，发起chunk迁移指令。- h! u+ V+ P+ d3 j" h
" i3 e6 |! N: r. _) W 在MongoDB中，n的值，与一个collection可以分成多少个chunks有关系，chunks的个数越多，n就越大，但是至少n要大于2。当shard servers中chunks个数的差值小于等于2的时候，迁移就可以结束了。. F$ _) Z" h& L& e8 X: k. H
& n m5 h- K2 r0 C0 r; m Chunk的迁移是在线进行的，也就是说所有的shard server都处于工作状态。Mongos从数据多的shard server中，选择一个chunk，迁移到一个数据少的shard server中。 为了方便理解，下文中，我们把数据多的shard server叫做orig server，数据少的shard server叫做dest server。
2 ^2 }; k+ ?7 Y0 W3 u8 o( G y
% ]2 a' A* c; H 迁移的过程中，首先 orig server向 dest server联系，成功建立数据通道之后，chunk数据会被从orig server拷贝到dest server。这个过程会持续一段时间，时间长短，取决于数据的大小，如图2-2中的过程A。; q1 w, v6 `( C/ x
- t* [/ e/ Q a6 G) f+ x( ~ 在这期间，orig server可能会不断接收到mongos转发来的用户请求，包括insert、update等等，导致这个chunk包含的数据发生变化。这些新增的数据变更会被记录下来，不妨称之为 delta update。当过程 A 结束后，orig server 将向 dest server传输delta update，如图2-2中的过程B。5 X+ ?* @' W+ L/ ?/ x0 W) W3 v
! N+ b- \% d3 h% f$ a: S2 W. m7 j7 f
在执行过程 B 期间，orig server很可能继续接收到mongos转发来的用户请求，导致这个chunk包含的数据进一步发生变化。当 orig server向 dest server，传输完第一轮 delta update以后，紧接着开始传第二轮 delta update，然后传第三轮 delta update。如此反复更新 delta，理论上可能会永久地持续下去。; [1 I1 k2 R& l& ~5 \9 ^
8 Y# G8 n4 b* c2 p/ ^ 为杜绝这个可能，我们可以设置一个最大的传输轮次，当进行到最后一轮传输时，orig server会停止接受来自mongos的所有更新请求，并把这些请求记录下来。 V+ D2 v" t5 @$ }4 H$ y- n+ f' L
1 [7 y5 w. q# z/ X" m! F2 k0 |5 W! C1 g+ \$ j
图2-2 chunk的迁移过程
当最后一轮传输结束之后，会经过如下的几个步骤来结束chunk迁移的操作。
1. Dest server会通知config server，该chunk已经从orig server迁移到了dest server中。Config server更新这个chunk的映射信息，如图2-2中的过程1。
2. Dest server通知orig server，数据传输已经结束，让orig server向 Mongos，提交一个StaleConfigException，如图2-2中的过程2.1和2.2。
3. Mongos会从config server查询到 dest server 的地址，如图2-2中的过程3.1。
接着，从orig server获取到最后一轮传输时，orig server尚未执行的，来自用户的数据更新请求，如图2-2中的过程3.2。
最后，Mongos 从orig server 获得这些尚未处理的请求后，把它们转发给dest server处理，如图2-2中的过程3.3。
4. 以上的过程结束之后，在未来的某个时间，orig server会把这份数据物理删除。
在迁移的过程中，存在着一种特殊情况。假如这个被迁移的chunk，正面临着高频率的更新请求，那么在传输delta update的时候，会发现delta update越来越大，以至于delta update的增长速度，大于从orig server到dest server的传输速度。
在这种情况下，整个迁移过程要中断，之前所传输的所有数据都被放弃，也就是图2-2中的过程A和B，以及过程 1-3，通通被放弃，相当于这个迁移操作没有发生过。Mongos会从 orig server 中，选择另外的一个chunk，重新开始迁移操作。选择的标准，是这个chunk 的数据更新的频率不高。
6 y9 Z, d2 x, `9 J" ?/ g+ h
Reference，
[0] MongoDb Architecture
作者: puber 时间: 2012-9-27 17:18
底层运作机制最迷人。
作者: shengnan007 时间: 2012-9-27 17:53
puber 发表于 2012-9-27 17:18 
& n7 d! s. D. k7 ~; P% W底层运作机制最迷人。
9 u9 U) c$ t! W' G& v; e) t也最不好寫呀
| 欢迎光临 爱吱声 (http://www.aswetalk.net/bbs/) |
Powered by Discuz! X3.2 |