|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
4 V4 d O) H' M" p q6 p: P, S0 d3 u3 s- ^. ^6 H2 F
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
' r7 }0 V; h% Q) s# W
' v j1 m- m& ` \6 A1 S; I 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。8 E6 [, ^1 t/ E: [3 J( L
- ?8 u- h) a8 R! O% D: o
) N/ \' |- A& Q; u) ?
) m$ f- ]3 ^7 _0 T3 \图1-1 MongoDB架构图
8 U7 k! _0 Z- ]0 U$ i
0 z# o; C% U; ]6 o& e( o* z0 C7 b MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。" _; v* ~$ {* s& A7 J
# @! i4 l- m3 T7 c3 P
Shards- y r; ?6 X1 j4 C$ r f, w
/ d. _+ G& q$ u) l MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
+ i l" ]/ V1 b' d' N
- g, v6 k1 @3 J: J5 d Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
) {/ ~/ K$ G( p D' H9 D1 M7 W- {4 J( c) ~- f0 a+ t/ N3 k
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
3 }+ x2 s. E0 z8 f& K9 D) Q0 i. T8 i# \; R
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。% |; ^9 w2 I* r d& L
5 M3 I8 B0 r3 V3 ^5 ?0 S
Shard keys
& U* ~( ]0 P5 l6 B' X- e5 S9 Y 5 X) P# N2 d( K9 E
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。( e$ H6 r" {; x
8 v. E* D* `4 j9 {* g6 s 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，- H- L5 D5 K8 ~: y
! {9 B( c. m6 @
{
: x: R( y& x' ^0 Q4 o! y/ A "ISBN": "987-30-3652-5130-82",# ]* w4 l9 l: Y3 D3 b
"Type": "CD",
9 I4 G4 k6 J" K3 M3 ] c& j# p "Author": "Nirvana",
$ X3 K7 ?! u* U) F "Title": "Nevermind",
5 X& A- Y0 J0 f "Genre": "Grunge",/ ?4 S- g& |3 Y5 E
"Releasedate": "1991.09.24",$ k5 n; n$ n. E
"Tracklist": [2 q4 F' B* u( ?
{1 M3 t1 y8 n% O" ]6 [9 I6 r
"Track" : "1",
$ o8 r5 ^5 Y5 i) s5 Y4 ] "Title" : "Smells like teen spirit",5 z, g! n: i" H& e1 l* L4 m
"Length" : "5:02" _+ ^' B" _2 H$ q# Y. i, Z
},6 Q9 D! w: _* O( y; S/ a4 V F6 r
{
( }. h3 ?" t, E+ l "Track" : "2",3 y: S. p2 F; j
"Title" : "In Bloom",2 U# ]( E$ `; Z+ z1 z) X$ Q
"Length" : "4:15"4 D; `0 S! L5 r: y; o$ X9 I$ V
}$ ~# i( _, ~8 {& k) Y
]# x& _* h: D7 g0 L
}
! D; J1 Z) K# p- e# O* ~
) g& K9 [! ^$ z5 l{
; w4 X2 G& q2 O; W4 n) @ "ISBN": "987-1-4302-3051-9",
5 L: l7 n" o5 J Z* A: Z/ W "Type": "Book",* y5 A9 Y' R$ @8 ]; I
"Title": "Definite Guide to MongoDB: The NoSQL Database",* _" z r N3 c! f/ M8 r
"Publisher": "Apress",9 W' f; @3 y9 E3 q) E. C" u- ?3 P
"Author": " Eelco Plugge",
6 V9 q$ u, q6 h3 l7 L "Releasedate": "2011.06.09"
8 o- p" R0 K o3 }* U}
1 T) u+ T( n6 B) r! ]* g8 G$ e
: Q0 O Z& n4 b* e) Z* v 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。& Z% g# T; O. V9 r% O7 o. N* w
# A9 T' G4 l% n
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。3 \6 @4 G5 A. K' l# N4 j
5 p: D6 _ T( A" j; H8 l3 i 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
+ { e. B, x4 P( J( D" u8 f, F: v
+ R2 T( a4 K$ ^ 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
1 l* |2 S: M2 ], x$ e
7 A. K \0 n- q& @: T$ R1 h 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
& r/ q8 l! j0 @) L8 @( x, O8 U) d$ p4 k5 Z9 Y$ a: I J- R7 ^
Chunks6 U& N3 K3 Q4 q, \. {
; R! @3 t9 H: Y# X3 Q MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
; M+ a- \4 B! a! q6 @/ P& o9 G5 l8 K
2 w/ `9 Z* @9 X+ \图1-2 chunk的三元组 ) ^$ Y/ U/ |+ G3 E! F
5 Y/ @/ y9 c5 |+ {
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
' X7 Z6 e w5 \8 T2 o- M0 g, E
6 x; Z) n! p$ Q: M+ f 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。1 \5 u, R9 m$ f* w
# m' j7 I m1 T( k
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。1 m' y5 o" [" M2 R. K+ L
, h7 ?" j$ a. B' A
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
, Y3 \: z, w$ y D: l
+ T/ E( M% p% P, k 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
: {" j% d" s' L- K3 h$ z
# M) J+ |9 y0 h6 ?, n+ s& L/ C' o 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。* |% h0 r! ~8 c! m' C
9 E% F4 X _8 c7 F" p3 n1 VReplica set: T L4 f1 f* M4 P7 S) R
- k3 o- S f6 b% ^6 S# R8 @& Y9 z 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
e: P( ~0 z# u7 C
/ ~1 M5 B F$ o+ x, `5 ?8 f F 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。$ p+ m; P: B0 H( F) \( U
5 b' k2 ]7 T2 @/ j3 J/ S p& T+ c
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。. Z2 `( ~2 x% Q6 R! v* ]$ o& w* l
9 }, B/ x o8 K
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
5 |" \, b( e$ j% U8 k
# y7 J! c0 t% H* O0 p7 M# aConfig Server! J5 ]5 y5 Y* Q# z& `
- f5 @2 g6 m$ T5 M3 O3 a Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
" F/ j' g3 s9 q! ^: w
, E- y5 f; s( b6 ]& w& k1 { X4 o 每一个config server都包括了MongoDB中所有chunk的信息。
5 F! k0 S F( _, }8 q
5 i, }+ L C. I/ c# o3 t$ @; \ Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
" _' ], N7 ]% U4 P! E7 R& Y' b" J1 V
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。9 C5 ?# a1 \! d' f3 }( E/ T
. M. Y2 D9 `! a! C, H4 w9 u# D MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
, i6 s# u7 `& \, L0 H) m( P6 C1 {+ B
Mongos# z- I5 M' o" @3 h
4 y- G; z* K9 i5 Y1 Q 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。' ^! S" A/ U, v/ j8 \( y, J- e
3 d) }0 O) I5 g( U* G4 Y& d- j 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
7 ]/ C' C& _1 g& @
3 W2 c7 F. S9 }8 ]4 c1 X Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。3 J5 ^" ^% F. }& y& f
- P ~5 z1 }, s3 B4 n- {3 }9 C
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
* H/ P, }( J* ]8 g4 c: q& C5 B
& k6 b& y; ^% Q) n) ~# c3 P: p 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。( R% F. q7 a! U; e, U! |% q
6 z) r) @2 ?* G) O3 b: M8 g% [
3 E2 |+ M7 w0 f! }; {- _/ tReference，
2 r, e) K+ \3 t" n1 S# F) ~
: r$ j8 J$ @: C# u8 M[0] Architectural Overview5 i- C; U# o4 Q/ W$ z2 D% |$ k
http://www.mongodb.org/display/DOCS/Sharding+Introduction6 T' O* L% Z& T% L
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
+ G) I9 f+ B4 b0 d/ z/ v