|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
, a3 D: j/ f( w; z& ~- s
1 X4 [. p/ D: v& u6 Q 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？7 y' O3 t; l& } H! j1 ~6 T8 b
# n7 F1 K H9 s: |! e6 C
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
- k9 ?# P( s, V' f
. t8 |0 B6 g) r, k- u, ]1 A1 c
4 s1 ~, }8 v9 O1 H" e! a+ c! e: }
9 G; @4 A0 y8 v' }+ V图1-1 MongoDB架构图
g% T$ s, P0 r6 d4 L8 \4 o* ~2 g4 O0 ?0 b3 l
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。6 o; S5 e" |0 ^: ?$ {* j
, T! d. P [+ G% E4 i) N
Shards: w( U' o+ A+ L6 ?6 [( @- V* J
6 m& V! _$ Z6 n8 \- T; w
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。# q% Y# [# E2 v
$ I1 i2 z. [" o
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
' _/ v! Z5 _8 q% q/ C* R8 K" _3 |5 w7 R8 j& O( N+ m3 V' Y: d/ v% h7 e: x
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
/ A; v8 c" ^. N1 L% P. k
6 e4 s5 L/ m* y" h+ P( s f 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
( V9 ?+ }7 j' e. r& E# @% T( Q# a' m& m$ ^
Shard keys
& {: ?" P. \# p- f* Q. H1 t 6 D: {. b4 i) a, s7 M
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。1 x+ D2 W$ ^- E2 ~# _' `
: }7 `6 b2 H- T* F3 K; ]/ ? 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
: ^+ ]% I9 u3 R6 N. Z
3 V5 Q8 Y+ f, C0 c% a4 }- I, g{
$ H' c$ j: p2 w' b, ` "ISBN": "987-30-3652-5130-82",
+ h% n7 v( {8 C0 x0 I0 `1 K2 c5 ~ "Type": "CD",1 j* T4 |- }/ n+ ?' L7 K
"Author": "Nirvana",
) G/ Y$ i8 K4 W' D "Title": "Nevermind",& U* T% N f, \, f) V( @
"Genre": "Grunge",4 P7 F6 L7 H: a5 T! m8 t) h3 h1 o
"Releasedate": "1991.09.24",
! r8 v- C5 t& U7 b6 p# q "Tracklist": [
1 V# d5 _% r! o; ?# _, a {+ J2 O" u3 n+ H s: X/ ~
"Track" : "1",6 t7 E1 v. Z3 z+ s l
"Title" : "Smells like teen spirit",
. n% n8 o: ]( u5 f" O$ Z9 h* Z "Length" : "5:02"/ s8 j% b# Q4 c6 s
},/ E* C# j- f5 r. B, S6 Q2 z( O
{& G: T6 n6 h' I' w" ]- p% d: V
"Track" : "2",
2 Y2 G0 V# T$ u" a! E) R7 d "Title" : "In Bloom",- k1 Q0 S6 z0 P! E3 l+ v" {
"Length" : "4:15"
5 K, R8 Z4 H6 y0 O2 ?4 v. s }
! \+ j! ~0 y! r: f/ | ]! M/ O- u! ^" o, E) o
}
! Q: R, M |8 a0 P, Y! ~7 B! O3 [/ _
{' R! n% i5 K& I$ y
"ISBN": "987-1-4302-3051-9",! G& v& x# o4 F
"Type": "Book",
, M. U; U& M* O& V* u0 P: d+ V3 k" _ "Title": "Definite Guide to MongoDB: The NoSQL Database",
^$ X* E( d1 T- R "Publisher": "Apress",
, g6 X9 `# V2 x3 ], t0 n$ _ "Author": " Eelco Plugge",8 i o) m0 F) x
"Releasedate": "2011.06.09"' h3 \$ r6 I/ k7 J4 N6 M
}
: d. C& V( b& Z2 k4 O I7 I! Q% ]# Y; r( y" g4 G, t @
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。+ T+ \3 o6 U, i! i0 o
9 I% d! h: U; e1 H
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
) l0 Y5 h U1 J/ B% P3 G6 C, T& u5 `% N3 b) k, a; `
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
9 \ l; J/ z) D6 h+ N4 V9 J- `: j' e* v$ u- r
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
8 x# d8 P3 j( [! Y4 r
; |& Q7 W8 s7 u3 J) _6 E 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。' u; V% D/ q6 I. n. w$ ~
4 [4 \! r) i, j4 X; B2 X+ T2 @7 ^6 ZChunks2 j) f2 ]/ c; _% }9 j
4 F- G" g0 K' H6 s MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。/ L' N& P6 {: c3 [8 X! M
0 e2 ^9 ]) B5 ?& S6 K8 |" _
% F% b- i2 j# E, Q/ P7 B
图1-2 chunk的三元组
+ R8 o; ^9 f: k1 Y2 b/ ^ k- r# a( U: y. k, ?
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
; H2 i2 Y6 m; C9 g6 [2 u
% K2 F; b/ a# i5 R5 `6 ^4 I 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。7 r3 `5 @; h$ l* w, V
, j" H2 K0 \4 f8 u
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
% e) h; [3 o' L, j" ^6 Z# [& S5 d& c7 U1 Q: q, x
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
) j) U: x% J( i7 U4 K1 A" T0 h6 A+ k
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
( ^* B: y) d7 G4 w; X9 u5 @7 z" I
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
8 N0 l8 m) O% d) N m+ G" @' C$ R( p/ r+ ]6 P* S1 C7 h
Replica set4 W' I. m* s6 N8 Q% j' `2 Y5 ?
: i! Z6 I0 \1 }5 G! r9 B
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。7 g1 x" n2 T" m
- Q' P5 | p. G
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
7 M: P2 D3 W8 Z+ d" H* g0 S7 E8 _' t
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。: z& K3 r, \& L2 l; n" ]
9 b& U* U/ G8 F- ]" S: _7 m
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
O0 [! U" Z( |) h% r$ c
+ ~+ \8 @& Q: C j* k) ^; wConfig Server V0 E+ p0 }' z8 W+ p) P0 ]
; J1 O/ J# A. W" O! ~
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。: u# U0 M* R$ e: l
4 i6 e* _' R8 t: G4 g% M 每一个config server都包括了MongoDB中所有chunk的信息。
: G5 f, w3 a& e, I! M) P. S4 C
1 X) M0 n9 z* J; b Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。0 M) q; r1 N2 i, Q U
/ m9 I, i2 |2 Z5 F6 I 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。4 U0 T' _) I6 J% h
6 b& `3 ~! }3 a, Y1 n
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
' `3 R# R) ?7 R: H9 X; C2 s, s
- j1 n- y8 M* @+ O* @$ QMongos& F L. E1 ~6 q6 Z( w
! p$ a- Z' v0 Q" r, ?7 |9 _ 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
, P+ B/ @5 S' g- m2 Q) p- u, J a* K( n t s! H7 `& s8 R7 H
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
3 o3 \: h) N: p5 B3 w0 O L8 P- {" l9 U& C* @2 q! H7 [
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
* m# I2 z" }; S v7 e* L2 |+ V/ C( _ @! \9 p' L
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。1 X+ j; z1 d7 ?. T' C7 B- \
+ ?0 F0 E* b# w/ F 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
! B, J7 c* j) v8 T3 h
: \" f/ f7 {& Q1 U
0 l& e% w' Y' L- N- [4 U4 ^5 oReference，5 Z. W! `) o- m/ ^
# J# n: C* N3 i: ]* l* T2 A/ o0 _1 I( H6 j[0] Architectural Overview
2 }2 r. R4 c# d8 p( Chttp://www.mongodb.org/display/DOCS/Sharding+Introduction
8 V* U' O7 ~4 L; n& W1 i' Y |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
$ i, m( J& U( s( N