|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。0 G! Z# t) S4 {
; U" ]& B. H3 ~9 l- t1 Y/ Z3 L7 X
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？' e, d O6 _" {8 x- O" D/ i$ [/ b
9 A; d# b. n. M: p 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。2 ^) d# ?1 s9 @( O
& ^# w4 K# F1 K3 x
T/ |/ m7 d* b8 _
# S$ |3 ?" b0 ~7 O0 _
图1-1 MongoDB架构图 ; u. ?2 v2 [8 R) Z' L
1 J* b) x) q: O) B
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。! L; n$ l! ^$ x+ I" h; C2 _
/ j7 v* F8 X Y& i4 V
Shards7 M" g, \% y/ x/ d$ j
/ M- b; `- T% t0 s4 y" Z
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
) W: I9 p( M1 a) H L! I8 a7 N
. X% V; a3 U2 V" n* d* C- Z Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。 p% R# P- ]4 |; Z: |! h
! V' | _6 |* b! @4 E+ b- p 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
( u4 d g! T% W3 r, m; N! Z" Z0 ~6 S/ n
, c3 A' V" M) U5 n 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
6 o1 U+ a6 ^+ ]6 c; V0 D
4 j# d6 b# J6 ]4 R) S4 _: r- pShard keys
( {- z2 h; M8 G4 w& { & N$ K3 @; G M( K3 a
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
* i, j( o: N- A* J5 d. g+ n' [$ Q, n* U: V7 r1 [
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
. D9 p8 z" I7 t0 i! r6 _3 |1 ^5 h7 J/ L
{+ k$ u6 ~1 n$ K* r5 Y- K6 |& @, \8 |0 N
"ISBN": "987-30-3652-5130-82",
' n& W6 x3 f# n7 X5 h% M0 ^: } "Type": "CD",
+ A8 M- o7 o3 D2 z( A "Author": "Nirvana",) Q! i8 |' |5 p: W, i
"Title": "Nevermind",
5 L) O4 P/ c( N% g3 R "Genre": "Grunge",9 j5 P- P- u/ r4 W6 F
"Releasedate": "1991.09.24",
/ ?+ g5 w7 h* Y' a; A, k "Tracklist": [; G \5 ~: r( x- D( x2 `
{. @& n8 S) q% Q( h
"Track" : "1",
$ o' Q( j( u/ Y* E+ l/ ^1 m "Title" : "Smells like teen spirit",
, K0 N1 G" K D- O8 [1 m "Length" : "5:02". b e7 X0 z1 d% T( ^
},7 m4 ?6 L# s3 v- f- T! V/ Q# ~
{, f7 A" h% n! Z
"Track" : "2",
# I8 A2 s) j( C4 A8 {; B+ m "Title" : "In Bloom",
7 z2 y- ]0 w. @/ A* e& d5 _% D "Length" : "4:15"
8 y4 w u8 l* u# c. g/ W7 j }3 e* d7 `$ i* Z6 g" @ [
]+ Y1 U0 l, ^# @
}
& v5 {8 }/ u9 Z" [0 z* f+ P/ y6 \) e* P9 q/ [1 W
{
5 Z; z- h b, S8 r/ M "ISBN": "987-1-4302-3051-9",
0 F- Y2 T1 c* G7 I) T "Type": "Book",
% M! m1 ` E3 o" i "Title": "Definite Guide to MongoDB: The NoSQL Database",
( k& _* M5 N7 n: ]& |3 ?/ | "Publisher": "Apress",
) f0 w6 `$ d, ^; P1 U+ B "Author": " Eelco Plugge",
4 M: N ^% F* d- o5 H- l: ~! y "Releasedate": "2011.06.09"
, |& R7 M* I! o7 J}( ~9 h/ J" a7 `& a6 @
% l5 j$ G$ \4 U- _) X, p: h( r- g" Z 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。: b2 `! `6 C! P% d& d5 T
0 U+ c/ I) v1 q' A
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。8 e+ z# ?0 ^0 J( g3 `# p/ J
3 p6 L. b' E5 W+ X* L4 _8 h1 O 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。$ p$ ?1 g4 k- N$ g6 T) v' d3 f
3 J4 d3 @$ w U* J8 [9 H; d
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。) M# }; Q" q( f6 O
6 \7 J1 ? j$ j2 Z% x5 ]7 w 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
% v7 D6 K: n1 w v/ |% p O$ {) o! I5 Z& [! l7 Y: Z
Chunks0 S6 y E; L+ I
" Y8 C) [7 w' c) d; ]0 R5 {) j
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
3 D# m. v: h' d. D5 T: O1 K e) M6 J# }. J6 M
, |/ B* B4 v) a! a% }# h. P4 O9 P
图1-2 chunk的三元组 ! {: y0 |* E9 \* F" i
" E" k( r5 n: d, ]. l- r5 p
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。6 P' R6 a0 T0 l" H
) F' u' ^+ m" l* n" @* t
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。/ P; J$ z X3 d5 Y% N$ S8 z& E1 `2 J
% C" E! D7 ^" s1 O1 f0 q/ A Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。% q+ T& H2 o N3 d4 c
_; a' c6 Q4 \5 w) L2 ]! X% W 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
. |6 M& _6 i8 Y9 e0 d1 }$ w( l: v' U. }% M, J
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
/ ?9 F6 P+ p" b2 C/ U& _2 L0 J# Q4 @
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
) x; r0 t4 p9 `# o9 @
$ f: `0 d8 `! E2 B: aReplica set5 s( J6 H4 u) L7 g% n
: F a2 f5 c* `
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
h3 Z1 z! m& n
% B2 Q+ C- k. P' I/ \9 n 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。, ]1 S" L( q# I4 v4 K; @
7 U, G8 J. X, L3 e0 L9 C3 D
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。# i4 z; r% ]9 y. E
. @- D4 V. r* l Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
A4 ?: R6 F K' h( B- O0 G" I Z7 d8 e! c
Config Server1 b6 F; d0 r! m4 Z) `8 R" K/ _
& z* @' J- ^- j3 t6 T
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。4 v2 ~: ?# d4 |) h) @: m/ q! g$ \7 X
2 D/ X# e0 c$ G( ?' z$ V) N& }
每一个config server都包括了MongoDB中所有chunk的信息。' D' N/ g. |4 D
$ v; |8 Q/ c8 m$ i
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。% C0 P$ u+ ]" {9 f2 L
+ x/ F: V3 ^8 N 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
$ [3 {; q; D* N; Z1 d
, e& O& ~7 |. m5 o MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。: Z) ?+ e8 X* W6 Y% m& G7 H. B
* w7 z2 w! }$ k! d" x1 Y( ~8 A7 j
Mongos& V2 d1 l' n' p$ b& v
3 A) R+ p1 G* [% h$ s, t$ m' h" P' A& X
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。) C4 I1 j8 l5 _8 |
) W: C8 z6 X; q3 Z* @$ z! ~5 p+ r( M
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。, G: W2 \% S5 @% V% Q3 S
3 z( n/ M) K$ t9 e' F4 x6 T g9 O9 { Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。 W; k) ?* _, ? ^2 b/ }
6 V% q! K5 z2 E9 {+ U3 ~& [ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
* L9 e; f$ D& _1 K/ K: H0 n* l0 E J& b# E4 |0 F
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
' Q! A" F b; {- T2 n. ^, {
+ Z. f( k: B7 q/ Z
2 [2 P! F3 j% e2 G- g; z6 qReference，
; W6 S8 F7 W- n9 {9 B
/ q: E, o( G" |$ G5 i[0] Architectural Overview% C' ~' R+ D) P. t0 J/ b+ }
http://www.mongodb.org/display/DOCS/Sharding+Introduction
& J- k$ u- S! I) ^% T7 a2 N) J: @ |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
