设为首页收藏本站

爱吱声

 找回密码
 注册
搜索
查看: 3814|回复: 2
打印 上一主题 下一主题

[信息技术] Sharding中Chunks的切分和迁移

[复制链接]

该用户从未签到

跳转到指定楼层
楼主
发表于 2012-9-18 12:37:48 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
    在上一篇文章“MongoDB架构概览”中,我们简单介绍了一下MongoDB中的shard,接下来,我们详细的讲解一下MongoDB的sharding model。
  Q! Z3 T& u2 e# w! {
8 B9 ?- G* Z; m- [, {5 Y7 x/ H    当MongoDB的一个 collection 数据量太大时,我们按照shard key,把该collection分成多个chunks,多个chunks聚集在一起,组成了一个shard。3 e7 l" z, @1 A

  s/ m& E! C4 E5 [    每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。如图2-1所示。
' O( _9 a: F+ r4 }& t5 B8 b( m7 F: [& n5 P; v6 ^

" N% W3 ]! p. d. P  u& c+ @* q( Q. `6 q
图2-1 shard key、chunk和shard的关系
( o& z- S1 o" p9 c* o$ b1 K4 M
    通过图2-1我们可以看到,数据在整个key space上的分布是不均匀的,这就导致了chunk中存储的数据量会不均匀。如果一个chunk中存储的数据太多了怎么办?多个chunks构成了一个shard,因此shard中的数据量也会不均匀,如果一个shard中存储的数据太多了怎么办?
5 N, Z2 D: u% \: J7 |+ j3 b( p
6 s0 e* |, l4 t: i    上一篇文章中,我们提到了解决办法。一个 chunk最多能够存储64MB的数据。当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
; I, m) h. Y- s4 m9 I  T" I$ x5 c
0 l& w2 r  Z8 |4 u2 m+ ]' r    当用户产生存储数据的需求时,把插入数据的请求发送给mongos,mongos先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers,同时,mongos会根据历史上插入的每条数据的平均大小,判断这条数据插入到这个shard server的某个chunk后,是否会导致这个chunk的大小近似达到或者超过64M。$ L, @, g% [9 ^8 M& w* c

- s7 K2 x/ m4 K% a    如果mongos经过判断,发现chunk在插入这条数据之后,会近似达到或者超过64M,那么就说明这个chunk需要进行切分。Mongos就要和这个chunk所在的shard server联系,并发送一个切分chunk的请求。5 M( ?1 I8 z) u# N: b) L& o

7 t9 }# [# I( ~* Y1 r- K    Shard server接收到mongos发送的请求之后,首先查询这个chunk的shard key range,然后根据这个key range,计算一个midpoint,然后把chunk从midpoint处分为两部分。同时,把这个变化通知到config server。
" S! u+ M5 _0 X. X% @8 y/ e5 `" s6 N$ g7 y" Q4 q
    请注意,这里只是切分chunk,切分后的chunk仍然在这个shard中。随着系统的运行,chunk中的数据量在增长,虽然通过切分操作,保持每个chunk中的数据不超过64M,但是, shard 中包含的 chunk 数量在增长。如果 shard server中的数据太多了怎么办?MongoDB通过chunk的迁移,来均衡shard servers之间的数据量。
$ H6 B3 B: R2 z8 k5 v+ Y: [8 k1 L- V0 o
    在mongos上运行着一个“balancer”进程,这个进程的任务是确保每个shard servers上的数据规模大致相同。当数据规模不均衡的状态被检测到之后,这个balancer会联系那个数据较多的shard,发出一个chunk迁移的命令。
! U$ ]* O$ L& E. O$ q1 N1 r# `7 H2 B/ E
    如何界定什么是数据规模不均衡呢?如果存储chunks最多的shard server,比存储chunks最少的shard server,chunks的个数之差超过预定的一个阈值n,balancer就向这个 shard server,发起chunk迁移指令。% T+ {# ^" K; }, T# H* `
. Q- A7 F& ^, f4 A" O. q
    在MongoDB中,n的值,与一个collection可以分成多少个chunks有关系,chunks的个数越多,n就越大,但是至少n要大于2。当shard servers中chunks个数的差值小于等于2的时候,迁移就可以结束了。
% G# b& U% V: F2 }7 `
9 M+ @! q8 m" s8 x& _. u# B  _. q    Chunk的迁移是在线进行的,也就是说所有的shard server都处于工作状态。Mongos从数据多的shard server中,选择一个chunk,迁移到一个数据少的shard server中。 为了方便理解,下文中,我们把数据多的shard server叫做orig server,数据少的shard server叫做dest server。
* N2 x" r' r% f3 h, g: F# A) L8 Q
# q* J+ J! e4 S9 I% }    迁移的过程中,首先 orig server向 dest server联系,成功建立数据通道之后,chunk数据会被从orig server拷贝到dest server。这个过程会持续一段时间,时间长短,取决于数据的大小,如图2-2中的过程A。
% j0 r" l/ I4 N4 F' A5 Z' c- N2 X  K- F" S1 F3 h9 Y5 c3 [
    在这期间,orig server可能会不断接收到mongos转发来的用户请求,包括insert、update等等,导致这个chunk包含的数据发生变化。这些新增的数据变更会被记录下来,不妨称之为 delta update。当过程 A 结束后,orig server 将向 dest server传输delta update,如图2-2中的过程B。
8 p2 g4 ^3 X( A' s1 A* O
! K& J/ u; Z+ m$ j, ~: T1 z    在执行过程 B 期间,orig server很可能继续接收到mongos转发来的用户请求,导致这个chunk包含的数据进一步发生变化。当 orig server向 dest server,传输完第一轮 delta update以后,紧接着开始传第二轮 delta update,然后传第三轮 delta update。如此反复更新 delta,理论上可能会永久地持续下去。. X$ m4 e- y, N; y* c
( h, X- W9 t; F- c9 {7 ^
    为杜绝这个可能,我们可以设置一个最大的传输轮次,当进行到最后一轮传输时,orig server会停止接受来自mongos的所有更新请求,并把这些请求记录下来。: i: F' F0 T  }4 A5 i
" V; z# ~; U% R9 q' y* b7 I/ e% a2 Y! ~% B

6 _9 r' y( N# L4 d( H) C1 C# Q
图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 的数据更新的频率不高。

8 g8 [8 F- t- n3 B5 r- m( y- l6 B
Reference
[0] MongoDb Architecture

评分

参与人数 1爱元 +10 学识 +5 收起 理由
不爱吱声 + 10 + 5 谢谢!有你,爱坛更精彩

查看全部评分

该用户从未签到

沙发
发表于 2012-9-27 17:18:01 | 只看该作者
底层运作机制最迷人。

该用户从未签到

板凳
 楼主| 发表于 2012-9-27 17:53:29 | 只看该作者
puber 发表于 2012-9-27 17:18
7 p( y; z. t) C& l; `& \, w) e底层运作机制最迷人。
0 a# M! ^8 Q) S) x5 V/ O
也最不好寫呀

点评

对技术宅来说,只要能搞懂,一切都是值的,因为那代表终极快感。:)  发表于 2012-9-27 18:02

手机版|小黑屋|Archiver|网站错误报告|爱吱声   

GMT+8, 2024-12-23 12:27 , Processed in 0.039501 second(s), 25 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表