|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。
- `7 I9 n9 M( y0 h2 `) P
8 L$ t z, Z( ^! o9 Q 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?( ?# ]8 Q( M$ n" h0 M1 S$ l
% _4 ~2 a& X1 C. U 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。5 s1 l4 A6 m# g
4 x$ g7 s! J2 _* L% P! u0 H4 j* @
: K" S4 ]6 N* q. J( d
7 s2 ]# R: W2 j+ W! c' X
图1-1 MongoDB架构图 # R: t, n3 }- h5 r" ^
a- a6 U* A: f( w3 C+ y
MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。
& P+ {6 {" F5 H8 k; M, \- d/ k( y R8 |1 y# s
Shards
4 b7 t! ?$ `5 J9 w7 w6 V
& p" i' s5 P* |! \ MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。& g7 A5 `2 U8 v- k1 h8 H
1 k& j9 u/ N! R% t7 q+ M Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。
$ T% h0 B* b) @: D6 M+ \: `. s) p N8 w( V2 }4 Z
每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。
0 N# e7 @8 }2 _+ ^# a" t! T6 @( l6 @. R y3 C
如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。 M( j6 N! u( q) x5 f& ~4 P7 I
/ R2 @5 A6 f! \, u/ P* f0 pShard keys) |. h/ T& P( R( r
9 p: t! l" K' [% a9 Z 为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。. l( n* W, A8 V
3 ~1 q! L& r& Q5 S$ G! l0 | 如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
% L' v6 G: r7 g& T& {: ~
1 W: B2 C7 h- w{
% [6 G5 V5 V0 E "ISBN": "987-30-3652-5130-82",, ]( ?. I4 g. m C/ R
"Type": "CD",; D. p s; w/ _ v5 Q5 V, @
"Author": "Nirvana",
5 v t B) L8 P: h& g( R+ ~ "Title": "Nevermind",
2 S) l" ~1 `! l! t "Genre": "Grunge",& P( O: h; j! ?
"Releasedate": "1991.09.24",
; ], a' b; P8 q6 Z( t "Tracklist": [; ]: P4 Y3 N8 {5 j$ b# u
{
# W# W4 c: t2 h+ Q6 y4 G/ L "Track" : "1",
- V5 s8 c* j, Y5 e2 K+ _( K "Title" : "Smells like teen spirit",
$ X6 E1 J; i7 }$ H; q "Length" : "5:02"4 a: m9 l4 ?2 F6 A5 {! v
},7 X0 {8 t6 }- x9 l1 c0 o2 J
{
; w8 Z) g" j6 i, A! o "Track" : "2"," Q$ V# l9 C% ~5 G2 H
"Title" : "In Bloom",9 Q0 p! K$ @: J' h X, i
"Length" : "4:15"8 E" h" n {) s+ Z
}6 ^. ]6 I7 V6 T9 K8 i% n+ O
]% \3 B. c4 t; R( X
}, e# j8 u- |& L; {) a% U& ^! @7 K# I
" P" a q' s& N ?" Y! D$ l0 T{" Z5 n/ a) T0 n7 E9 F
"ISBN": "987-1-4302-3051-9",+ x+ d; q4 }, H1 Q& E) _) O
"Type": "Book",
4 x8 {' g( l+ A/ Z+ ^3 I2 p; o "Title": "Definite Guide to MongoDB: The NoSQL Database",
; I/ {5 f% L7 i) J) t- Z. H/ a7 y- J "Publisher": "Apress",# T0 v% A% l; g: A K: K
"Author": " Eelco Plugge",
6 S$ g/ r/ P# @9 m "Releasedate": "2011.06.09"1 D5 i( }/ x- b( O. l0 O2 d
}
, H) C! u7 W: w7 X. v) U
% q- ?7 g0 l0 h 假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。, {8 B3 `* V+ ~. l& _% G8 _ a
# M; G7 b/ g7 E! n! Z0 W 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
. a7 U9 q! s2 B1 p5 q
* I! p' S6 A; u/ t$ R1 U 例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。
! x$ Y& m5 B( u9 M2 m+ Y
$ M) P2 j+ F" _" ^8 T 很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。: d* f9 ], C3 k0 c; ~0 \8 }
3 ~% E. a4 ` I; g4 g4 _6 f' L. [7 h
延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。/ V& Y+ q, V) b
. B8 L) Z4 z1 x- {8 T7 y' A
Chunks/ [& j5 ^$ X R! r4 c6 T2 ?
1 G$ u/ e0 C/ ?. f MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。
" n) P' N) C. M- X- N
/ C# G4 u2 |7 N# {) _: J6 v4 _) c
* D1 r6 ]$ \( h# F' s- z" B
图1-2 chunk的三元组
) z) r- ^! ` w9 e+ d; v+ k/ W T4 Y
其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
5 {; _4 E' s9 @+ N, J
5 C# S- z6 \7 X8 b/ Y. C9 S1 b$ V 如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。1 e) Z, \0 P* I/ K2 Q' h" d
' O* P4 D, a, Z
Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。
' |/ I8 u$ }4 `2 B# x
9 U/ p% t3 _, t 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。% X# v7 ?3 r' k* N
$ F( M% M) d& P% R( |. `7 }
当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
* w# n: d' y2 \+ X
* ~; _3 W3 _2 B# F( c 这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。
; X; G1 |7 ?; h8 K: T2 U% s6 \! N1 z/ Z$ a, Q; W# `. W+ Q. Q
Replica set0 z* T# ~1 S' q1 p4 Q" \ b7 \
5 {; G% B" g. g* I$ b! Z: J* o
在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。( e5 g7 S& H5 G) O7 i
6 ]4 l8 s2 T3 P% E$ b8 l- \
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。
: W. |0 j. z& n+ u; l: P2 z. [! V
Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。
# B$ {) u0 q, p, u) Y5 u7 M
# n3 |- i# \2 {5 P, U Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
( R2 h3 q' r4 H. a
' B3 l; e+ A0 m9 m+ d8 IConfig Server, f# ~, U6 X0 ]$ a/ c
7 \ U# C" \8 Y4 @+ o+ ^- c; j4 z! [
Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。7 b6 i$ [! X; b2 @
) e8 F$ _' l) K 每一个config server都包括了MongoDB中所有chunk的信息。
5 j+ A$ z" l" E R, l& }. c' Z8 i% {! \: a% X8 Z( H) A
Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。
' C( r/ M8 K/ b" g: ?4 k' o9 u2 _9 Q I
如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。/ f5 W7 e+ O# U4 O3 p) t
7 v9 v! [6 n3 q, h C
MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。$ r5 {7 Y) U+ b) c5 G& N7 l, s5 g
( |, v) j; }9 @, I% {Mongos5 x! y7 _7 f( E$ ^ {8 A
5 P# Y1 {3 b1 N2 }; h. C l 用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。, r1 Z9 I- Y \! i3 _! M
0 o. Q) x( Z4 Y 当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。# H! e1 B( t3 M% ^8 }* M
; G# a, g t1 k! |4 s7 ]6 P8 V Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。
* m" V/ }1 U1 P- s' h4 i
% h9 G% J( v2 {( i S Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。
) t& K4 Q+ n1 }) n p
% G1 j8 `0 x2 u4 G# V 通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。
: t0 Y& _" R7 O/ k; ^' l0 r$ x
9 u( z* u8 ~* z
+ X1 s9 I9 n- `; ~* [& ^, w- }Reference,; ` s' S) U+ e
0 g+ ?& q; Y; u: }( b* @9 J! Y[0] Architectural Overview) b+ G9 y" w# l8 p
http://www.mongodb.org/display/DOCS/Sharding+Introduction
4 O X+ i! s" A2 l8 A7 J) x |
评分
-
查看全部评分
|