|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。+ c, P2 ?$ P& m/ ]7 z
' _: C: K9 Y" {$ S+ y" F4 U% C
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
- o* ~. e* N6 v- ]% A3 J7 p; t- S* f. R
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
) D5 V$ ~' p) } t% U
6 @" T# q$ B% e( B" P3 w
% Q- F f/ H J. V3 ] n# H" t3 h% Z0 W7 _: f+ s
图1-1 MongoDB架构图 - Z N5 ^3 Y4 Q7 H8 i* @
9 m( R5 w. [ j* ]& _ MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。" {# h1 y# @) O; b, B
; D- l; k# E- r$ Y' X2 y; `8 v
Shards
# a. V4 j9 F( d' p( ~' b- c' L$ h4 G u3 {
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。7 L% }/ y( @& W% }1 m
) Y1 i% b) n, c% k Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
- }6 S' s* z, E0 u5 f. F& h1 H9 K# E7 m
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。, i+ h, R% |+ H, e+ M
6 Z: I @8 Z1 X, m4 H! | 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。, _6 i. O# q$ p3 g5 F
7 U. \/ u9 H Q- l
Shard keys2 G6 b! n0 D' ]' z7 b/ F' g( t
6 R- B3 }& h3 L- L" O8 h$ b ` 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。3 \, w4 l$ q4 J6 o2 l4 q
; f" [6 S# ?5 a) T) ?0 P
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
7 Y5 Y& I4 p5 w0 P
( m9 P/ G6 X5 b/ F i{
/ M) J. v8 }# Y% ^! S4 z "ISBN": "987-30-3652-5130-82",$ U( ^: M7 V" o; Y5 l- B- U) t+ ]" O7 T
"Type": "CD",
0 a) I9 t" w& o1 H$ N" ^& ] "Author": "Nirvana",; d3 O- t, {2 k6 w0 W5 l9 \
"Title": "Nevermind",
, t& J1 @! F$ o9 z* F3 b' N0 P "Genre": "Grunge",
1 N3 g9 K$ I$ y "Releasedate": "1991.09.24",6 b3 Z2 ?# t( z, b& D, O% l; d. N- M
"Tracklist": [
6 v( n' i0 i+ I; N( d1 @) K {
; B1 D- _+ H2 \4 l' @1 B& W/ L; q0 K "Track" : "1",
3 ^. ^- M& O% Q3 p `& r+ ? "Title" : "Smells like teen spirit", Z @6 d1 Y% T: Y8 v9 z, v
"Length" : "5:02"+ V, M- k3 X: p2 i* g' E; Z( Y
},3 P2 r7 S! o: y; Z K( M
{7 W5 K x8 s% q. S" h$ R# B$ u2 | i0 I
"Track" : "2",% K% e0 U" y) ~! I% S2 R
"Title" : "In Bloom",
! {9 q% g8 T V4 a5 k' A "Length" : "4:15"/ O5 N3 V( e4 u: X8 q6 d& M8 J
}
% D6 h3 y; u- R6 h1 e. I/ v' D& Y ]6 Z- x' V2 B- j7 n
}
. K0 R6 Z$ x2 e @: R
) H. U1 b5 b1 I7 l{1 J, M7 U9 G' |6 N+ J, E3 J
"ISBN": "987-1-4302-3051-9",
' Q- B6 k+ W- t* ` "Type": "Book",0 k+ [. |! y# d$ }4 w2 D" U
"Title": "Definite Guide to MongoDB: The NoSQL Database",
0 |. b7 s6 P. m ^ "Publisher": "Apress",
2 A3 q8 ]3 O. |) S "Author": " Eelco Plugge",3 k. h- {5 _6 W) n5 y) |1 e$ X
"Releasedate": "2011.06.09"% H4 a5 F- l6 k5 F# G4 u
}
, u% m I* \: ?$ ]! s' _" e5 B o7 F, y6 Z7 H% Z
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
? Z5 l7 @; M9 P% A2 _
. p9 J" g6 u& L! u+ [ 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
. G5 u6 }8 y/ J" ]' _9 I1 _2 a& p1 ~, {0 @( r( b
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。: \: J0 L& r/ J) q6 v
# s. G1 R% ]- |9 [! X2 M) S- D
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。$ a5 q" w" |/ _* n
1 |! t% N5 s4 I1 B 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
8 j, u( B/ d9 L. P
, e& M; |% N- x4 u- Q8 yChunks1 W- J: z/ x2 w
- O8 t# k5 o! ^$ y* X7 ?' S9 p MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。9 g4 k. S& z. E
( Z0 z* q; j) h2 k% c8 P+ H
3 c3 ]5 x8 |! ~( G9 t# k8 {! L# }图1-2 chunk的三元组 8 X2 E' h7 ^ Y- w) g
7 J) b0 ~/ v7 I& r9 P. g 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。" f. w l& X# ^% A. T+ F) a
+ Q! t* b% o6 ~- U( h 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
% \/ M4 T0 G! G: |0 Y) {
8 I& i# y' [8 m, \5 I: q Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。, l' J/ g& I0 \3 ]+ z; e5 L7 A1 W
, O2 L- C4 }4 t4 s. u! K+ j+ C5 l 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
1 z# M) K" ]7 [/ w2 x5 X5 C6 W
# Q* J# T5 G/ z% n 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
$ m& Z: y- P' A! `: A7 n1 a" @3 _ P2 E5 J
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
$ R! D" k( N) o2 c4 w# x* z) ]9 S
M/ y. s: U& E9 ^( o6 VReplica set+ d+ s- r, ~1 M7 h& ?! J" `
$ F1 j) z) [; y1 L0 o* h; S8 l/ { 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
+ w, l1 a2 y- Z( C; h _5 _. \2 L
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。6 I z- R& C% C ~/ ~
: B8 Y7 R5 p7 i( i1 c Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
) Z7 [, v6 y' ?) t& @: E6 h- N6 Q( d# r& {) i( Y& d A" [
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。9 l$ a/ j( a' ?; h3 c2 X
' U1 k+ Z8 M) { [9 J) V5 p
Config Server
6 _$ Y( z; ~. {: }" l
& P% Y- m8 l' i( ] Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。. ]& }: N6 W+ V2 ?; K
* I4 I0 f" O9 t1 K u( j& Z$ M
每一个config server都包括了MongoDB中所有chunk的信息。
3 O: _' Y6 _3 V: J( Q9 R
3 q/ S0 t1 q/ V( g Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。' f3 k! _) y5 t0 |+ A. ^' X
6 Z( y+ `% D; B 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
5 r! C% K2 L+ K& b: d: j. Y6 O. S& P( Y }; S7 h& ?+ `/ h% L3 v) J
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。! ~' D! p. G$ A9 ^
6 h6 @/ K% Q* }; _: }3 qMongos# O! c: ~/ N' q
* _; @/ C2 s/ z) G' i
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。0 {' l% S5 j6 R
" G% Z) Y& S$ B8 h1 n" m2 b 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
5 X6 ?/ d( @: s1 O! U- W
# x3 d- ? o1 |1 ^ Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。' ^( S Y' Z# t" [' R8 A* ^6 G
: L% M6 s! G! B$ d0 l9 i2 }( q Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
/ a3 y& a8 t) J7 M( ?2 z" y% N7 E. \, b% u/ v' I% F
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
' I9 o/ H' U5 S' R3 W# W5 ^: H/ S# U7 ]. z* R5 E0 E5 f
& h3 i3 \7 n7 ~+ O( [& d+ [Reference，, V+ T- K3 l7 F/ J* ]6 A: n
" X! h2 Z* i- ?) s. `; f5 G Y/ f[0] Architectural Overview5 T! i0 \* c$ }& ]$ K! Q1 v
http://www.mongodb.org/display/DOCS/Sharding+Introduction& P5 h0 ]9 u2 j) E5 [- }
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
