|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
4 B1 N% o% ]- J4 k8 K
( V7 O. p. K: p6 N. S 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
: K! e) N. h, `7 d; m3 |+ N* U% r a: \
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
/ L1 U/ ^5 M, N* ?% J
6 F" M/ l+ m0 D: V/ \( ], a; ?8 @
% b+ P5 b" Q; a; \* d: T# w- M; N4 v5 m! A" x7 l) I. w/ ~' _
图1-1 MongoDB架构图
% l/ y" F; |$ \6 n1 q
! B' j8 y1 G) s" O* O4 k" }; ~" I MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。& X& c" J# g& g. R p6 v J
; w4 Y" t7 a& K, XShards6 N- m7 _0 M4 X4 q
# E+ B4 b- u, P c$ u v; F MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
! s( `& j9 X5 \# {7 T7 U
8 y3 \- k6 Z! w: }7 A Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。, j% u; o5 S. A. [# m
q1 K/ Y3 \& v) K' z 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
4 c, C$ p; a X6 L* j( G$ }% a- y7 q {- w3 \; B5 s2 t Y
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。/ p0 \% v4 ?) U# z
) X B* z% T& N! r$ YShard keys4 e" @( X( S: Y# v5 ^2 _- ?! ?4 D
7 k/ A, b: c% N% I( ~* D* p) b 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。! O. O$ m% R" A- K( m& }5 J, E* a
8 G Y) p* B/ t# Y1 B' I( Y 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，( Z: Z7 ?7 C z* U0 @
7 y% }' r9 T$ h+ s, k7 W3 H& p
{& |, t; F& V7 y; K
"ISBN": "987-30-3652-5130-82",
0 T/ g' i/ d$ x( T' ~- H "Type": "CD",4 ]7 a! ?3 d1 D; a
"Author": "Nirvana",6 W- ^* k; ?5 c& x7 K8 [$ o2 R& p# j
"Title": "Nevermind",
# J! }# o. g. j: u. z "Genre": "Grunge",# c9 ^/ u# Y- s* D/ _
"Releasedate": "1991.09.24",
6 U$ w" l: G3 u0 y% `6 z6 p5 U, f "Tracklist": [- ]% u; A. ~2 M% i
{
4 t8 p1 A% s. |# Z" a$ J$ U8 V0 j- X "Track" : "1",# H: }& x4 f! V- e2 S
"Title" : "Smells like teen spirit",
$ Q* b& e& \* ?/ J "Length" : "5:02"1 T7 a7 J6 K: e5 {$ D% `
},
% z; ]4 w* E8 [* k. O {/ z" B+ h3 z- I0 P
"Track" : "2",. _ K( O( n+ m
"Title" : "In Bloom",. s/ z5 \+ o; R& B$ d5 B! P5 F# D2 K3 C2 q
"Length" : "4:15"; q9 B0 ?; m$ x
}: L* O- A0 e& b2 k
] C3 n% ?( s, D- H# H" I& ]: ~
}( ?0 L' B3 J" x. x$ H1 Q; \0 Q5 X
& H2 T' ^* q! M& U{
& D% z8 T1 |/ ]( h7 V) l "ISBN": "987-1-4302-3051-9",2 G0 @+ B" H% l
"Type": "Book",; `. q/ O2 e/ w* E: P
"Title": "Definite Guide to MongoDB: The NoSQL Database",
- ^6 z* m& u: b "Publisher": "Apress",
; j2 D* q* ~7 B: y9 e "Author": " Eelco Plugge",5 _3 O+ \ f1 D1 t9 z
"Releasedate": "2011.06.09". K. w! u; V# U) X
}+ F& h# w4 G- S$ Z+ Z2 ?% K6 t
3 h! D2 C: U' s
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。3 h3 ~ ?2 N1 L; L y
3 S, t( R \6 @& g 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。- a5 O7 k6 G1 D* t2 m
0 _- q6 g5 N# Y$ {$ i8 C9 z* ]1 ]
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。& n! g: F+ ~! m6 `
; U; ~$ K! y& N q; w2 w, R. H9 { 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。) _4 v& [2 } _
$ Y. ~& s7 Q- d) h% m 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。% w; H O) x5 Q
" D7 v* w3 I8 K* B+ ?/ N7 wChunks
7 Z1 C' C- v4 g" G6 `& L # O1 Z0 J" L- E& h& ~# \
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。$ h% [" D8 ^. _
( q- `' D2 X* C( q$ S0 S
6 i& `- A/ k- H" `
图1-2 chunk的三元组 # U7 ]% Z" i h) _
7 A- W5 M$ ?4 D( h6 K
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。! c( a" U: M1 _1 j2 a! x- b
& H: `- J/ v) i- ?+ W2 f 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。, J1 K, x+ `3 E+ B3 {
- a- }9 ?9 _" H# _ ~( X4 \" J0 b Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
. F6 r S, ] Q$ z) C- \/ U1 p, ] a) f3 c2 o! j
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
9 u9 H3 d- c w, H8 H( M6 o4 J n% Q" X1 t# Q7 C
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。9 N) d7 v; T X+ u9 w" v% e5 p
, H3 B7 Y# d% M9 {3 e& T
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
" Q% `* y& ^9 c" t' M2 c7 {/ r* l. S/ }- @, ^$ C
Replica set! S% [* d( D; [
& F8 k; V5 D& ^& | 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
: \: e( P. {) T& Z7 D2 t+ l% Y* u% J9 K& w& q
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
- O. d# w6 h4 Y2 V5 W
3 ]& N# |) i7 J b# A, v Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
0 r6 {" D8 y+ P% F) B2 t
4 l* h: H# ?% k& ~ Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。: c4 E4 u V( o: j' z
) k6 l0 G. r) A; A+ Y
Config Server$ I6 i2 L, o4 O
, x: G7 L9 G& A: }4 o2 j* M Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
% f. L' a. H/ ]0 O; S. u3 V# x+ R6 e! { I& p, `7 ]: E& k, L) j
每一个config server都包括了MongoDB中所有chunk的信息。% X' f E# V+ O5 M
6 S2 j6 g( h4 ^( m3 m: T
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
/ z$ }% q% s% ]5 }+ M+ x# l
, }" F6 F- N% ]" G 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
, S8 L: f& j, z( f2 t6 u2 ?* X9 V) ?2 l! M
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。& V2 ]4 I4 k7 T
# U! Z/ |, V- ^8 m$ j
Mongos
2 y* J0 V8 Y) F7 m1 z) x: ~6 s+ u* n8 C
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
( [# m, e0 A L) f9 e1 a6 ?) i8 m) z/ h7 T. S0 _/ y3 y
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
$ x5 X1 Y# L' |* V' h1 @+ W# r9 |' x8 i# f5 i7 t3 p) l3 z! j/ f
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。* h! \. e) q; _! p
( o6 R% `$ I9 ^2 R( `
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。9 J3 y4 s! ~; w, h
1 t4 ]3 j; h* S" l% M; C! x 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。' j8 N" F9 n; k |' m' H
s: V1 G) I3 a
( X l+ H7 x2 w+ ]+ ~/ a- ]/ xReference，2 m5 `) Q9 D. j+ P
! M+ y; }, z7 B4 O# ]
[0] Architectural Overview
6 N$ \8 q3 ?) a$ j/ shttp://www.mongodb.org/display/DOCS/Sharding+Introduction
( A4 d, v; Z; f' B5 H6 Q6 v9 x1 f |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
