|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。; ], K7 S) N- ]" p/ {
; C3 h8 r |1 i 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
: _* x" W9 M5 x) ~! s+ Y$ v3 j1 ^
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
$ a& j- q+ l$ J6 y
# E" v- z. k, { P' F8 i
8 [4 R. l/ A3 P) {6 T, Z% @( @# ^, s" a
图1-1 MongoDB架构图
* ^ K" Q2 I8 L
3 \6 ]+ ~- o ^ w2 G MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。! o) f+ D; {* e2 Q, z8 N# w
9 w& s( _" P; G7 h& jShards
# k7 ]/ C: K6 c5 Y& [& U& [# [. K8 Q
" v9 B5 N+ B& X- T! _ MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。* V! H6 P: w* x$ p* G, ?9 @
6 F% m1 ~3 g" @ Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
7 [, L' C. K/ U+ V* E8 C( N) L5 B/ `8 m( n, {
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
; r3 Z2 ~, J- s7 I) x$ W% W6 v! O. j% H0 v$ s- R y8 K
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
- X3 n2 G8 \9 E% U) o$ A" E0 ^: j& D5 f( h0 Z4 Z) ^6 A
Shard keys
. t+ I1 I' N; w3 L. L& @ $ ]: Y$ J- j9 m% n
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
6 L& f" e* N, Y Q: ]' V
. C+ n- _+ h! l 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
8 d5 b5 m7 d9 [, r% |
0 G0 n' ~/ e& v* [ r7 x2 F. G{% p$ _ e) f, `
"ISBN": "987-30-3652-5130-82",, a! K& V7 E6 g9 G$ n
"Type": "CD",- Z+ I$ Y% G& S# ~ t0 E7 D, r; D
"Author": "Nirvana",
" y1 e' y) W( ^7 _0 \. t "Title": "Nevermind",
4 N8 K" K h, P: X" f "Genre": "Grunge",
) \1 `2 O3 i9 R$ \ "Releasedate": "1991.09.24",
1 I% y; h: T+ Z2 b0 ^0 v "Tracklist": [+ b4 T1 @8 w2 U
{
3 n" m: ~& N% v) E' n" |# X2 x "Track" : "1",; Z9 @; n$ } g- k# f# X
"Title" : "Smells like teen spirit",2 ` D& o! ?1 V6 _
"Length" : "5:02"' c+ a) }5 l" I y4 J. [" {
},- G- I9 b8 m5 r# v' y5 l
{
3 u) g' C2 B( q' t "Track" : "2",
8 t9 _6 l' W/ v& ~$ p" l/ d "Title" : "In Bloom",& K$ w7 ~8 v4 _4 e
"Length" : "4:15"
1 g. I$ q0 r: \2 O$ h" U1 ? }
' k9 [7 b# @- l. i ]+ w8 ^- z8 {2 D# X
}+ T/ e2 q. Z: j
! t- D: U) E/ Z2 p" n9 l+ H# N5 ]{* @; ?9 r) S7 p9 s2 V, ~( C0 B
"ISBN": "987-1-4302-3051-9",# c+ |2 u( n: ]* u' a0 e/ v2 ^" z
"Type": "Book",' e2 N0 D5 A: B; b9 }4 v" j; u
"Title": "Definite Guide to MongoDB: The NoSQL Database",
" v: _1 j/ m. W. D# |9 `! H7 n "Publisher": "Apress",; Y3 u! t* g! ]( N; h O$ e
"Author": " Eelco Plugge",
" Y6 H3 q7 V4 O7 |8 g' S. A e "Releasedate": "2011.06.09": w4 V, y; m' J& r; ^+ ~- f
}
9 \2 ]/ ?7 I2 r5 l% B
3 \! c5 v `5 p 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。% _4 c/ ?- { G, `: s: a! V
( Q. z2 y4 i8 P% k* p
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。' M, |* T; w7 U- {0 b, \
2 } j+ R) I/ D: C- {$ z
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。: ^" f9 Y1 m4 Q) {+ i' B5 {: M3 a/ f
$ c: \3 y0 K% x4 W, ], ~, L 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
/ w' G* j, v' A5 u4 s! w7 ^ o/ J* f$ Y5 B: g
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
7 @) a6 u, Y& {& J4 X( o7 X
6 D, Q7 v+ }0 vChunks G2 ~( Q9 r1 E+ G6 g% i% Q' p
7 K$ @9 o; ` x* V! ?
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
$ {9 I5 t, W# Q. E2 G V6 Z+ c! h) B$ v5 g T1 N/ A y. o
3 W7 j& [) E" f; I图1-2 chunk的三元组
% s Q; p: o! I6 E2 K. J) C' o/ u* C5 s2 ?- u! y
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
$ u$ r: T* J8 x
2 d8 }0 X( \1 c6 ?: M" x7 C0 i0 `9 y 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。+ n6 o. }/ v& d0 C; G
. }. J9 R$ }4 r/ `4 R# A5 }
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。! z& m7 ~# [% V5 I5 V
q. r; V/ m1 _/ `8 c! ^" @ 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。3 ]7 c; U# M8 D' l' T6 l
" t2 @' S2 Q2 P" V+ X) N4 Z1 N 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。( ?0 T1 J5 s/ j3 E3 x+ e
& I2 h, ~+ S2 I. @4 X/ `3 j
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。- p; t1 `$ c1 w$ g
+ J% m9 F4 f' y3 Q# L) o$ vReplica set
- A T6 b7 s/ Z+ b
" d. o$ X4 _7 E 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。* w" Z" }2 P# W8 \( M0 z, k! m
! a- {" s6 @( |2 _. O4 |9 f8 |
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
9 F) F- K; C* [1 x( Z4 q% F; ~, X# E7 E' O
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
9 n) u& _, r3 G6 U8 I7 i, O: v; h6 ?
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。9 S/ T. @6 N2 t2 k4 Y/ Q
0 ]" V+ I) |! C7 L4 h; [Config Server
& Q2 R, e* J1 T9 ?) c, t# ]
2 r% i7 r: d9 ~' g8 Z- I" J' K, | Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。" i3 s4 ?9 E8 O
1 Q0 w# f) x, E; i
每一个config server都包括了MongoDB中所有chunk的信息。# M. Y# @, N: g" h+ ~ }
- W. A5 H5 p$ B" A4 C7 B( U g Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。% A. v1 b5 o# L4 @" |% ?2 O6 H0 p
2 [/ _) E0 W/ L0 l0 O/ c
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
# F" J$ F1 P3 i4 P, r' j6 w7 M3 w, T% I" @& K
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
& K" |: P6 e! n% m2 C' y; `4 e7 E$ M3 Z" ?1 _$ `
Mongos% E6 S( c: z! \. q Q; l: a
$ R5 ]% T% h/ a
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
% n# Y: D) x1 Q! k
' U3 R- A# F/ Y3 u$ M 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。0 `# x* n: ]" g* \/ P( H/ e+ v P
|0 l( y/ }) ~+ x4 \ Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
# f3 ~$ [) q3 N L5 I0 M) c+ k( Y" K: G1 I& d# W
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
, |/ C" w* D" x" P- x
/ ~3 H( G3 Y) z& ?: [ 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
6 l$ d# Q7 y; |$ L+ k: o0 K
( R! r9 v, A3 x3 l* @: W6 |- b
) ~& z8 i% J5 C. F( qReference，
4 }6 F$ k8 D6 z Q9 B! }) J7 t: Z- P$ R9 p+ F+ H; \
[0] Architectural Overview
4 \7 m7 A! m$ thttp://www.mongodb.org/display/DOCS/Sharding+Introduction( q( A4 \0 A6 r' X) L
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
% y% I" s" I. X0 k8 ^) ~) W2 B