|
|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。
* K& e1 s3 r, q0 U1 R& u5 n
4 }9 H1 j5 c( l. g 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?2 G8 h3 k/ e, S- u/ X5 R9 N, w
% K8 O) F3 m Z 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。
& K" m2 Z6 G/ m: q6 l4 s, |" U5 x% Q( V
. h' Z; }6 x; ~1 q5 s3 p3 A0 M# `
( S/ B. d; d2 B图1-1 MongoDB架构图 7 R y' \3 ^- `
: k4 a4 I# _( n; S, e" C/ D( u" V MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。2 e [% W5 i% ]
3 J4 p0 o. Z/ W2 p+ P4 ^
Shards
$ j# ?7 v1 [( A: Q6 ~
1 p0 D( ~0 e* T1 ?& I MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。' I( q% [4 E' O: I6 F1 \3 h) K
! S8 |' ~: U$ z" K) M0 R" t* @
Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。' H9 \' \+ ^. c% U" y
3 Z/ y5 f) J0 c! u
每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。
: V+ x# K. v: S5 J
6 ?& H, @! E2 |% x6 G; t! ]8 ^ 如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。% h4 n% r2 |- i5 C' E
) K9 ?1 l& G/ E3 R R( cShard keys
+ D5 U9 U3 r+ _' @8 l" _# L ( d; H1 U. x, F& l
为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。, c5 l# s0 Q% u/ }! A. D4 j
q+ k# G, U1 @ N/ e 如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
" d$ t/ t, Q' Y: [+ b" u# D' O. c. s3 ^" G3 R
{8 C1 y# b- B9 W6 U
"ISBN": "987-30-3652-5130-82",
& D8 s0 F2 P8 u5 A: D0 }: Z ~# i "Type": "CD",
0 w: F* w7 p' Y" @) u* Y "Author": "Nirvana",8 Z' a: `' ]6 N: q
"Title": "Nevermind",
7 X! R5 P0 Q7 R; W "Genre": "Grunge",
) E$ z/ h& h4 Z$ K2 | "Releasedate": "1991.09.24",
6 G/ d) y) I x5 L "Tracklist": [& o( d2 i, w& F, R7 I
{
1 f" A! @2 O$ }: G# ~ "Track" : "1", C, t% c$ s6 H; F- ~
"Title" : "Smells like teen spirit",' h% X) t6 u5 ], e7 p
"Length" : "5:02"( {# [7 W% d4 b M. M
},
+ E. ?' q7 }# X' l- B# F7 Q( W {) [0 ~/ V7 u! m5 i5 u+ m$ ]
"Track" : "2", Q, I1 d/ b6 b+ A4 q" N. _
"Title" : "In Bloom"," n8 A! S, G8 P3 R* { R. x5 ?
"Length" : "4:15"
3 @6 A! z! L+ }, I0 n }, @6 N2 A" O6 {5 h
]
# |4 p3 n. u, }; b O}
9 w# t% `) N# k+ ?" t
9 B* O+ j' t Q; Z: h3 ^+ ^{3 Y" }1 A0 B/ U( h- P
"ISBN": "987-1-4302-3051-9",
. T" s" D4 F* u5 R1 V( }. [ "Type": "Book",/ L) g. l4 z+ r1 c3 g# w& a; Q
"Title": "Definite Guide to MongoDB: The NoSQL Database",0 N' ?$ F1 a/ d' j. o4 H& T) ]. f2 e
"Publisher": "Apress",
1 p# h8 {; S5 u: C& C! q "Author": " Eelco Plugge",
1 t7 @0 n' [$ Y! m# g% ^ "Releasedate": "2011.06.09"
. u7 ?+ Q6 w! ~5 \7 n0 G4 d}
* s! B7 t) T( Q, a' _" z5 Y
. A9 s# I9 n! |- D' ? 假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。
4 p! _% A) G7 A& @, O! K, H8 f. r
( s& u0 M% |8 u0 u* f3 G9 S3 K 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。! B6 O( Z K. l# V0 \
; n# u4 k+ A3 @: V 例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。& i6 ~, a+ E9 W0 r
8 q; N& q! h$ ]5 l% W+ `
很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。
- W8 b- ?8 t* h: r( W& L3 J. e% e) H9 @ ^+ x5 m
延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。
& b3 d& G b/ U" u3 j4 y: O- N3 N- z; a3 P: N1 F
Chunks
- }4 U9 q. f0 {. h l& V) O# k & L7 W. h7 z4 F( S d
MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。$ ^. m" z$ r. }8 I f* m
2 k. @2 a" c- R* g8 z
8 x* Z$ R1 b$ B0 V( K图1-2 chunk的三元组 ) ?, `3 S1 }# J; t' r2 G6 d$ W
0 k" y1 e- `) Z3 A" ?+ z$ C 其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
) D) o- E' D6 ^% S# Z1 J$ n) F5 y0 _
如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
3 P; F+ T# A* e
0 s% P4 g- t! R# a$ r- N0 C Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。
- _: q' j; {; H6 Q7 q$ n x/ w3 c- @3 y; d% C$ n# g
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。# C" k0 @# g% L7 D
, i y! C/ {. J) T( a2 `
当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
4 N* P% C& ?+ b1 S$ H' J
! p7 w$ E5 [2 A4 x. j2 w 这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。% O- ^) f4 Q& ^! F. y8 ^+ S2 v* f
o6 i/ o# |2 `* U5 bReplica set+ {* p1 {7 F/ p) I$ j) C; \
1 D0 ?0 @+ J7 a, ^8 B
在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。2 y7 Q3 |5 c0 G7 f0 c# k- M) P
3 w4 W, p: {' S
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。: }9 j d3 Y# n k$ R @
) F; S3 d2 r/ y( n% v( Q
Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。
# u! E1 a @) d% o9 N' k: b9 |* r2 k: e5 m
Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
$ }) b+ h0 m2 K% B X* t; {1 ^6 h* z/ ^5 y" l5 z; }- l
Config Server6 b, H& e2 B% T$ Y) h z" i3 O
: b' F- K! k$ c2 u0 `/ l0 K) C Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。
4 a1 u- m- J$ G4 {5 |( S' M; x' p R9 A7 z
每一个config server都包括了MongoDB中所有chunk的信息。
- x: i, \, I; q' [8 g; b% a3 E3 j5 b+ ~* _6 j( k- F% j
Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。9 B# A% w7 q {6 g2 L# m _# ?
2 {% O4 p% N4 u0 K% ?0 b+ ` 如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。
" q0 _/ I+ D, Z) D: L' E+ Y# l. i: p P Z4 G
MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。
. B0 W9 ]& d% E1 u% T3 d- a7 h. R, j& n
Mongos9 w" ]1 v0 j" b+ _
3 ]1 T2 m7 a# F0 X- n 用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。
4 f5 X+ l2 s+ F0 o
6 S' w1 _5 Q/ L* T& i3 X 当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。+ t( i0 s7 w& T' I+ g
, R/ u+ q' j: X1 }4 f6 I
Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。 b( o; m7 v# S7 `' `9 [! ~$ T! I
/ S4 M; V2 e9 s5 r1 U F& \
Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。( }& L* A1 Q* y
2 d4 `4 O& ^) S% t0 ?7 r 通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。4 y4 U4 f; Q5 N. V
( C- r% G& a* x Q1 a
0 A6 V3 |. ?7 r6 h4 eReference,
# n3 U( R6 \* w4 `3 @, O- @3 {! E3 o; \7 B/ {; D2 R
[0] Architectural Overview2 c# w: a& w) ?0 l$ B+ {
http://www.mongodb.org/display/DOCS/Sharding+Introduction: \: N! o, K* w+ G9 h9 S9 q
|
评分
-
查看全部评分
|