|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。0 ~- D* D+ w3 A- o e
, |: o1 C D I0 B3 U# r& U 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?
/ d4 @( {3 K4 z7 x$ f
7 Q" d- n8 L, G% [ 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。9 p4 b( b# O L# d6 ~
9 h* L' M; J: [6 {
7 l/ O/ a$ I) L3 V0 w/ |( x/ `- x
1 [& j6 ? a( Y9 p; z L) s1 {图1-1 MongoDB架构图
2 ~# [: R, }/ L$ R" A% V& h2 d8 J
MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。
: p, C9 c! \( b, H4 _+ X& a5 Z
% G* {3 P# i* v' Q# {% Q/ T3 f- fShards; Q& K5 [2 J3 U- N0 H) R6 \) L
B$ Q# X6 i# L6 N% ~& U8 e! i
MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。$ N. D' D3 a! R3 @
1 s" Y7 \1 G f, M7 V, p- R3 w Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。
) F5 h3 l+ I4 }! D. u* D# t' a' r
每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。! U; l5 x9 g. z( S
3 q5 ^3 [9 \/ V* ~* I
如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
0 e* C3 ?/ v% ?+ z! ^& `2 \3 @
" ~) J/ }" s/ G4 ^& y7 TShard keys
# ]1 | G w% t e+ b- p4 C% Y
7 J! Q2 e" g* ^4 H4 s# G3 K0 i( n 为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。6 n: K, L/ S/ q2 k
8 h: R5 \/ Q- H0 [: e" K' D- h 如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
+ y( t3 e& u$ D, \& }$ L9 X+ ?( ^, `# l3 C* U, A. `
{
4 u4 j) `5 @" W "ISBN": "987-30-3652-5130-82",# h" g4 ^7 S- z
"Type": "CD",2 K9 u7 s1 y( k- T2 I) H$ F
"Author": "Nirvana",) K7 p: |- Q1 Q$ e" Y$ o
"Title": "Nevermind"," L! h- s+ J* C. y |3 p" M6 t
"Genre": "Grunge",
" M4 _0 _" ~& \4 a* e "Releasedate": "1991.09.24",
$ k+ ]/ i! A" ~' Y "Tracklist": [, P0 z: E# w# u
{. R9 p0 R, Y! y3 \# P4 [$ X
"Track" : "1",% v2 e5 }4 Z+ {) ?4 V
"Title" : "Smells like teen spirit",$ p; V, e9 U9 |+ A
"Length" : "5:02"' w+ V" ]. i% e2 }" M# C$ E
},
6 g2 ^6 H$ V1 F/ {9 U4 V; W {
' [$ B( u9 j0 y1 v* t& j "Track" : "2",
% d* ~; J- H3 z# f- g/ X "Title" : "In Bloom",5 i7 \- q- \ ~& b0 i3 s
"Length" : "4:15"; e b; p' A/ q- v
}( B8 E) r) t3 @3 `, j1 `* R
]
2 u/ }: ~9 p2 y}
8 i/ E: j6 `) d+ r' F5 C: \1 F! }6 ~. J4 g( L+ V
{, p( H3 v( T; |5 u: P# v/ ^* @ T' t
"ISBN": "987-1-4302-3051-9",
+ s7 |9 |, w1 @5 L8 [ "Type": "Book",' C B6 q) G' P& q1 o4 W
"Title": "Definite Guide to MongoDB: The NoSQL Database",0 V* ]/ ^ l5 ^
"Publisher": "Apress",
) ]$ s! T% S" C7 d! Z& W) L/ a4 p "Author": " Eelco Plugge",# m: O5 c0 ?# r6 {3 {' j
"Releasedate": "2011.06.09"
$ A6 j& R- A" ^& g- F}! \6 _6 }, _9 n: R' N: l; S/ I
# H) ~/ h. A! ? 假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。
# p( {+ o4 t ?# \/ k* \1 R5 H4 P
5 ^3 Q) E$ p/ k8 q. ]' { 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
' |4 N$ `! ~) k4 D+ O9 H; I9 Q
[) b. a) o1 H N7 O 例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。
! @( L( N+ O6 R# C4 C. W
' j1 S6 H1 L s7 V* K 很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。4 [5 `/ X% T" o: }
) B7 B- ^- O4 C$ X) C
延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。. A; T c! F3 `
4 T. {) Y( I& f( QChunks$ d( I( R4 B" V% T' p" v
* T7 ?) L* X, ]
MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。. E) W$ b; [0 w, A) L" l9 k8 V1 ]
3 p, m; s4 a% _$ j1 A1 e0 l- k( I" n% Q
5 j* h+ t$ Q% n; h, K- w图1-2 chunk的三元组 ! E& {: |( A0 b$ e
# C8 D3 e8 v* ]+ S; C0 Z; c# D 其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。$ X9 q# b3 _0 q# b/ `
x2 m7 c; t( ?6 ~) W- r
如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
% {* e. r* D, B2 _1 m" g
, Z) \: ^+ p8 D) P' h; \4 s Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。+ f6 l1 ?. R0 Z, ~- p+ I
; g. t, I. ^. C 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。
9 ]/ e5 a# a0 M' v7 P! [
8 I; \9 v0 m/ `6 G7 R% Q 当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
& f _% X1 E& C R# x7 P' d& ?& V1 u& ~4 l1 N4 n& H
这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。# c9 g+ }, j- t3 a
) s" R* I6 O" Q, S3 V l2 v# {# o. e) W
Replica set9 w& h( a4 a5 D: y
' _2 g# I3 X2 B8 a 在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
6 b% f: n2 S5 e' |; e' H$ e
, l9 p% e" j1 e( ~ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。
+ S2 L) J! j V U& U* K
' J3 ^% ^% I% {( L Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。) ?& M% a/ u" u) ^$ N* {; M
# o, o1 Y: K6 S% u. ~# P Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
; ?) t+ U3 e& F, Q) {% P' H2 e* @# A: W
Config Server
8 N9 U& l0 j6 _" n- {5 g& N3 ]
3 {) Z/ i' G4 m# n6 u Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。4 I+ x1 j% S3 p' w
) P5 V. M2 {5 n, x 每一个config server都包括了MongoDB中所有chunk的信息。
0 S7 E m+ A" j0 V1 B+ F* M/ i
4 [9 ]8 c: t: Z! j: c) o Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。
$ g+ W% c9 Y( L5 l3 J0 N% L3 _$ @, _# I
如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。
8 M# }1 A y# j" ^" }! y9 J, R2 P/ l% C/ R6 i1 R/ M& ]
MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。+ X# ]2 H" T2 L7 @+ I; I6 }7 u
! _8 p/ C g7 g9 t6 S [
Mongos2 g# _1 i& {' v) v
9 W- I! M; t5 ^& a) N9 Y 用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。
5 z F4 X7 m, _% }! q+ F" `! K
' X5 x {. E- B 当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。' b H( p, S: P1 e q+ \
% F( q- i7 `$ K3 I
Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。
" s2 L1 V, x( t8 q6 ~/ m
a v& _( `, l( [" H H& B w# ? Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。5 O# p/ Z0 e; a) ]1 ?# x
; @0 L; @; g9 M# p: A* d 通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。
, p( l+ y0 i8 B$ g" M% K: E! t5 q" x s) S% M, \, ^
7 G: H3 |+ Y+ ~8 y7 n
Reference,
' m2 k+ F1 W; g3 n- ?
3 C6 k b5 b$ A( G! l[0] Architectural Overview# V3 q* T+ i" z6 z0 c- T
http://www.mongodb.org/display/DOCS/Sharding+Introduction
/ S7 B$ Z* V+ b: o4 n4 C7 O; d3 V |
评分
-
查看全部评分
|