|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。2 }# z W: S2 u
0 q! \7 [/ F: Y3 {" ]
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
8 j$ \" R0 I. B Z z2 f4 N/ ^+ N+ {; E/ B8 m7 m
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
" h0 c6 B* @, |7 h; g8 f
4 L! A h @; [. l( o
- W* p; U9 o; i0 p* R" x& o' e3 A' z
! w9 q) ]/ j* \# Q$ A6 \, |图1-1 MongoDB架构图
) ]+ e. S1 s( L/ t. ?& y
% g) u8 E# ^0 c MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。, h1 e5 `3 c' F, \. a! r4 z' |
/ k+ @+ L6 O6 |0 m9 f# d
Shards, ]/ y$ L R j! b t. c' `; i3 b
; \2 K$ V/ `3 N( J$ K* i* [
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
$ u' q5 H$ h# u+ ]: q
j8 P) o/ m: ^5 z) ~& m2 @ Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。0 H8 z- o7 B+ N8 z2 ~. t
2 Y' ^* D$ [! s- S 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。* d: }! J$ N u( g- N: U
7 `5 |' U/ d& k) J4 X# E- t' q 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
# p; a6 w4 R/ S; ?* N
/ _1 Y, |4 ~6 [- c6 zShard keys2 i2 C* e/ C, D6 V0 ]
3 _( Y1 d/ x) p6 l$ {3 P( o/ j 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
* L# z9 [( `) V( z0 a( X' [
. B2 U3 F/ H. o2 I: F' t 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
4 I7 b3 b9 w, k
4 @5 A, N; E' o3 i; ?{5 Y; M3 [5 [. q) B
"ISBN": "987-30-3652-5130-82",+ M; ]! S" W: d# X+ N- D j5 ^6 e- f
"Type": "CD",
. ?* R/ \+ J3 Y2 Q s2 ^ "Author": "Nirvana",
0 q0 M' [8 k% C" o "Title": "Nevermind",; w F: K: N( e" o
"Genre": "Grunge",
2 H) T# x8 A- Y& ~/ p4 [ "Releasedate": "1991.09.24",
( a+ m! q. t' {8 k9 l "Tracklist": [' w* Q( r9 S) K+ U) S0 k
{( l6 M% ]1 l j t x
"Track" : "1",: G( Q" `9 K% Y! U( O* f4 i
"Title" : "Smells like teen spirit",
# @4 o6 g, H) B! i "Length" : "5:02"
' y/ X1 k3 ]+ Z( ?+ R' r },$ \9 H* o. [ T" d* ^# q$ s
{) b7 _: x; c+ [4 s" u
"Track" : "2",+ o" l4 K0 T4 a" p7 {2 w0 o/ W8 A
"Title" : "In Bloom",. i3 o. E3 y" O s3 U4 j! R
"Length" : "4:15"0 ?/ S, w5 W+ d
}
. a/ [! _) n- R. l ]
% n( c- T4 \( y9 a+ R}- I3 |0 |3 C% ~/ n2 Z
7 X/ L7 r' d- q: Q{
5 U5 n P/ |( Q& H8 N3 ] "ISBN": "987-1-4302-3051-9",; w U* D0 u2 ]5 U
"Type": "Book",
+ i0 E4 ^' q9 }4 e$ h w) i! v, ~ "Title": "Definite Guide to MongoDB: The NoSQL Database",
5 s* Z0 k# k2 K+ F- T' o+ r "Publisher": "Apress",
/ f" n1 `8 X5 D- a6 m; M "Author": " Eelco Plugge",6 N {4 U3 r- L+ o
"Releasedate": "2011.06.09"7 I6 H/ ~) }+ Y7 e* K/ A" \, _7 H5 {
}
r. H2 R, r1 F6 f5 f8 r; k! o( ]
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。, k2 u' f3 d( F5 x6 J9 X
) j, x% V/ d' B( ~2 E 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
5 p* u# X3 }2 G" a, Z) Z2 }
8 c, N" }' r# {/ A# E9 s 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
( y0 L a _+ e9 b0 l* L& Q2 o M7 q `0 K. l
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。2 S& Z8 y2 W: d6 L
: ~/ p" r6 ?; k2 j2 i 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。2 x8 C2 G, b3 L( Y# h5 J- P
+ R+ x# k4 S/ n: pChunks
6 C" m7 t6 h9 S2 T: a
9 u# @5 k* H( i& x MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。: B8 |7 p# f9 o( m& k0 W7 L
! I) }9 q1 \# F" T) x
: A; I0 A9 Y' a+ @6 P* r; w/ p* U
图1-2 chunk的三元组
0 g# X% ? Q5 Z) U+ x }: j2 o
' a; v; h7 R. I/ r% `8 S 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
& ~% Z. `! O4 L4 C* u: D
0 h, w( Y0 j9 R- o/ E6 j! \ 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。% h/ e; @" x9 ?" P' ?& t. J
: c/ I# o! X3 _: u2 o
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
9 @, v) n: F2 c; H! ?& ~6 P
0 F: _& H$ j3 @+ _ 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
0 x7 L/ k% E1 T& i/ s" {; W6 b# l1 Q9 ?% y, @8 q5 {9 ~' t- B) y
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。3 Q' i4 W! m* I7 h) k( G
/ |# J. V: V5 J: t/ q
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
3 y8 {6 D4 X0 c( u* G2 A( K3 V2 N/ r
Replica set/ r( L+ W3 Y K ]) s- F
* \# c# b# m. {; w
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
, o4 G1 P) Y" K2 ]8 p5 l v! g: l2 W U1 u
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。* k, @2 b% v+ P8 j* E6 q/ J5 o6 Y* X
$ B. z n S; v" H1 g Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
, e" t' `& E: ~9 w' u0 z6 W
1 T" C$ Q* Z* i3 O Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。: T" j. Y1 o" C$ ~$ r
8 J! O# }. L' x7 O9 H" {9 {# {Config Server5 ]( d$ h# u: ]% r `
3 W6 G2 v" R- G* q Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。* Q3 n# L) g- l! h7 H( f1 p
- T1 Q# E; z; g. d* W
每一个config server都包括了MongoDB中所有chunk的信息。- l! B: {/ |& V) v2 p
9 }/ @: l l+ b7 m
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。* f. } j+ P: L/ S6 ]/ O. H
# S3 U8 }) O1 N' t* v
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
7 b+ N% i' n' G, g" B
g* u. e4 P" e& k2 f v# V MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
. y# N3 Q7 }9 Q% c
9 ^% o* c2 k8 i6 w9 D/ P5 BMongos
- B t F# B" U5 \6 t( U- H ?: F+ t+ ?! o$ p. i
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。 ^" ^- I* E9 E7 O
1 P1 \5 n3 {1 G4 k3 {, [; S Q
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
0 S9 _# q# o i6 K4 {6 t5 Y R
2 q! n/ H8 P7 R Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
- E1 v( p! C2 b# j5 l- O- I, w4 l8 \' o2 g
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。5 z/ B8 E. A1 F3 I7 t- \4 V
( n3 @- S: f8 y+ \$ y& Y2 h z 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
1 W K0 J, b7 ]5 \# p0 O0 W! K% A u6 H' @
* h5 |. \: J7 Q) V# g9 |: uReference，
7 L8 Z% n0 T+ \ k6 Q8 v e; s' X3 q: m& b
[0] Architectural Overview: M% w0 R0 {2 }
http://www.mongodb.org/display/DOCS/Sharding+Introduction
- r, P- }1 i" c* h |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
