|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
% l7 e+ r8 n0 g2 O( c: F+ `5 T! A9 Y1 ~& c
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
/ V' g( x6 |# f7 @0 h* t" v/ [ Y0 o6 s# j8 _0 y$ I. ?0 c8 b
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。# c- e* g8 }8 Z0 Q- x
$ f& ?1 D8 r3 \6 _& x2 F
( t/ g- z) n7 K! f! E- Y1 G9 i
3 m4 l- z8 q/ s9 T
图1-1 MongoDB架构图 6 s0 W" n& r! S+ _
3 T* B9 h7 L: P8 c MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
$ p) p1 i( H3 z; O" g$ V/ M) T8 m6 O X% K# c2 v
Shards3 E& y B/ P( x- l( }: Z9 r1 r) G
6 v/ z9 W5 k2 L/ i
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。$ J9 X. D" v8 I
9 ?9 G3 J1 J5 @2 E; O Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
1 r" G. n3 z7 N% k: ?% Y* H/ {7 ~! b' v* l
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。5 y1 y. [$ y7 @
' [1 v/ R5 s1 f* m0 w
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
/ V' m- Q5 d1 Q) x
, w: P9 ]1 g7 X& C# a2 P) iShard keys
5 H9 d! i6 h9 N5 b1 b* l! h 2 ]" P Q% X( E/ v- `, Q$ `
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。" j! L( ?) s0 N. x ~6 P
! p. x6 g) p# x3 J3 d4 z 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，- Q! \/ e; ?$ M0 g+ T y4 ?1 X
9 E' J7 u; m% K+ s- y, V7 S9 M. j
{- F& @3 J$ D) m2 D% j0 U
"ISBN": "987-30-3652-5130-82",. W" q# p% I( k% s/ s% `: \. R
"Type": "CD",& U. H: f# H$ X' U
"Author": "Nirvana",
* S" z) }' \+ X( ?% D; F "Title": "Nevermind",
7 Q1 ^- X0 l1 j8 ]- h5 v "Genre": "Grunge",
( G* v, K, N: Q A# ? "Releasedate": "1991.09.24",3 ]6 I! l0 Z1 |) `) \' v
"Tracklist": [( h, M# I. U9 u
{1 h; {) b, u* X% A# ?; }
"Track" : "1",
( |1 X; g( Y; i5 e "Title" : "Smells like teen spirit",6 y$ g. A% s% e8 L7 l
"Length" : "5:02"5 I6 M" O) s V$ Q' p
},0 ^+ F- `4 B# ~8 ]
{
1 ]0 A# o, a1 A( P; ` "Track" : "2",
% L# |2 h1 j2 `! ^( x! L "Title" : "In Bloom",- j- f, r' S) J2 X+ Z
"Length" : "4:15"
/ C2 V3 [' T& |; s! {1 i# o* f5 M }
, [' G7 X4 J3 w/ W. ?) ` ]8 U$ V+ y- G' v$ F* C, Y# |
}
/ Y: \4 q; P1 D' y4 f3 f! |% c; Y6 x9 `8 d/ ^' t) l; O+ y# A
{
" p# |! J* F u5 a1 v$ } "ISBN": "987-1-4302-3051-9",
* t3 B/ I/ C. Y8 ]$ l "Type": "Book",
% p% C: v7 z' l3 K& V0 v "Title": "Definite Guide to MongoDB: The NoSQL Database",
5 Y' \- D$ D: W- e9 C. N "Publisher": "Apress",2 _5 Y: }( Q) l+ |) W- a, |4 r
"Author": " Eelco Plugge",
* V* S# e+ h1 n( P5 Y4 z9 _% c "Releasedate": "2011.06.09"/ o1 w r- m8 s& h
}7 f" i$ b: E( r$ D
1 W J' t% j/ [ 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
Q: r0 k! o1 L0 k2 @# [6 E% M
5 Y" O" w! {2 X3 e0 O+ b 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。2 s6 M" O; w& a- Y( r
# I, r$ Z) {" Q1 R2 h
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。+ r% C% u& ~% W) Y) y! i
$ x* w+ E! } i4 f 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
. f% W; A9 T7 h) S1 r' ]" x1 s; H+ y) k3 _1 }
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。; S4 ^2 B. I* n$ p) v9 e4 m2 k5 p
# ?% M" i/ k0 |. gChunks6 o, i. X8 k, R' S7 i e& h9 g- `
5 y& Y& L8 J) h& D) i7 R4 X
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
4 M7 W* g- m! i1 u5 [( _
7 Y" x) F: b2 Z0 a. f/ e- ?
. R* a" ], C7 H2 d+ h
图1-2 chunk的三元组
' a7 c2 G% H; m' o# G: a# K+ f: t; K2 V2 e- B7 [0 h
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
' d; f6 R. `5 M# D' i1 D/ K$ u1 D
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
+ Q, r, F% T$ |$ f; P0 h- s6 y! o+ U) g
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
, o1 w3 _+ b% t4 A% Y5 D. B8 D5 J- ^. }2 r7 J% K
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
8 P h% Z& l5 Q H- V3 E- C) s9 {+ {- s) h8 L
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。9 v' V$ A# d0 L, f- E! H/ }
8 d, o" o& u% \9 ^& u O9 D; _ 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。6 x) O) g( `. ] r
) }$ u8 ?8 D& ?) {- K% p/ P- n
Replica set
5 ] d1 i. K' O6 B. z5 _9 T1 [2 o" {
- I! U* ?2 t# W$ k" u! b/ z1 V: R y3 N 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。% V5 T2 J3 h6 {: Q+ \# k
) n( V% ?' P& F a4 O, {2 c 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。 j% [ P/ Y( _6 }2 G& a" Q/ i8 \+ o
' q1 X+ b- s. z. V1 j% m8 _( A* \ Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
/ v" g: u! |* N8 a$ K0 G3 X( I6 Y3 u3 w- v. u8 `
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
9 l8 k+ U/ K8 R# q4 Q6 h$ B+ b' P3 t: b" q( p7 h
Config Server" f# x" @3 \+ B
+ u2 v+ a; y L3 q4 Z5 Z Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
8 W7 m5 s( \0 \
* m @( h6 l4 A! U% M9 m, z' I 每一个config server都包括了MongoDB中所有chunk的信息。
, x) X+ i! q7 l) f: {! p+ D/ i& q6 K, [( m
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。7 n2 ^2 k+ @* z1 }" j
' f0 X6 F, i# X
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。 x2 n4 s# W8 y' ]4 E3 G3 w
* p ?6 A, W6 T: d; W; I ~9 j MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。+ r: E& W1 X3 S* s" ~& q/ }" i: k' x
- h- K( q4 j4 \- jMongos
7 E: D/ D9 @' A3 i/ j1 Q7 a2 | r U3 l! T! S- k+ L% F
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。: c0 Y9 l* a% t
* f* g1 n* q: |5 j1 ^. ]# B 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。" O7 @4 j/ I' s, q# A5 q9 A
" g) P+ v7 b1 m7 I, x
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
6 p0 f8 K5 D* t" a" q2 [1 f% h2 b- G+ K1 S& q( U
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
8 k8 z, F% I+ u' d( K+ B/ z5 Z3 ~; m( ?8 }0 g2 t' W' {
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
. p# A) o2 Q/ M$ Q6 v
$ f1 R/ d+ I- @' E' h
3 k2 d; |; ~. `& Y3 o j. o% V+ qReference，
- A8 S( T: G* E+ k/ B( D3 t9 i4 O/ n+ F, N, ^4 p" ]! J
[0] Architectural Overview7 x2 f9 X* K x" {# T9 M
http://www.mongodb.org/display/DOCS/Sharding+Introduction
- }, J$ t4 R+ O5 \7 o+ v7 I |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
1 G2 }9 o( A# K( L# Y2 ~" \1 G