|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
! A4 c! B) }3 L$ O8 K# x$ @: r+ i# g1 `& {4 P
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
3 u1 r. ?+ F9 D) O3 U$ J. V8 k
# n( k' n8 T0 p 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。- p% a& \& P& M& P7 R& u
+ W# J, G! c5 P4 |
+ H# I8 ]; C& x
% f4 h1 F- c5 p. a- l( I
图1-1 MongoDB架构图
O* ^/ J/ [6 t3 b& u. w( [7 f
. z2 l% x% A3 G" m3 R* r MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
$ l3 R8 X: D& B' p2 x# x l8 ^ w
" R8 H7 ^. N9 E yShards
) b/ o7 b* N" C4 {* Q$ {5 }8 B$ ]! ?* `' m, G1 L, u! @
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。# T r; z% l Z( H
. M: k% O7 t, k- h" Z$ r Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
9 @' i1 [7 I7 ~" t* u3 c! p) l2 J3 M
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。, e8 t1 l2 C# n7 F: H) ?& b1 a R6 M
( r3 @" Z, P% C0 T, [& f3 Q2 t- A
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
$ ]. G% x& x6 S5 F# D/ k7 t2 Y# K/ O% y; m5 n6 u! Q
Shard keys
6 V. u+ G9 y0 [0 a: M4 f( v: i
: V' X7 ^1 h( C" Q 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
. a* J- c( r7 O8 r' E+ t% @7 g
$ M! u& j8 h4 ]4 B4 A 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，' j( b0 j4 A. a5 _' M
. x' n$ Q" D+ @
{
+ N$ l3 Z" V/ s5 \ "ISBN": "987-30-3652-5130-82",
) Q* a$ ?* a! O. S1 z. y "Type": "CD",
, g8 c% F0 P6 p2 z3 k" P- _ "Author": "Nirvana",+ I) ]4 \9 ?. Z) N6 v x1 v5 w& l
"Title": "Nevermind",
4 c7 I+ e2 b9 w: X" | "Genre": "Grunge",2 [' [! u7 k7 k9 @+ _
"Releasedate": "1991.09.24",$ o! }5 M& C2 w$ z4 z, X2 _
"Tracklist": [3 }9 Q R) {& n5 X
{
# h9 Z3 V! M* [4 }. ^) Z$ B "Track" : "1",
$ B% m" z7 s3 w. r "Title" : "Smells like teen spirit",% ^5 i0 G: d8 ?8 S) c$ C3 R
"Length" : "5:02"
) E$ _, T2 c' {7 S% ?# ?( l0 e9 J7 X0 y },
# @3 ^/ V5 M7 i! G% S$ T/ ] {
+ m+ ?& J. z1 ?: w% B- e3 Z "Track" : "2",2 I% u: o9 Z8 ~% N' d
"Title" : "In Bloom",
# h& s( P: x/ X2 S" g) r! S "Length" : "4:15"
4 O: K3 t4 W. A; X/ x }
7 f5 I) @) _4 r+ t2 u# A: S ]
$ Z# {4 W6 m7 n% f# H}* E& H0 b7 [, y: \; |
( b# s' D* E; @" S. A{
* ]- i8 `9 v2 I "ISBN": "987-1-4302-3051-9",* I5 \" y2 N8 e3 L* g: \
"Type": "Book",! U5 U& U& t3 _
"Title": "Definite Guide to MongoDB: The NoSQL Database",
. H& t# X$ I' m1 J0 w4 D "Publisher": "Apress"," a: x1 J8 o0 G6 L
"Author": " Eelco Plugge",6 g. s5 }% l4 I) L
"Releasedate": "2011.06.09"
; V& e" T) ?+ |$ {}& |( X# u9 f! M. v/ W/ A! n3 K% w
! Z7 B8 l* R( G2 v+ H0 H
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
4 z, s, k" e& K& n8 g5 f* ?1 _# ~8 e- m; y) }
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。3 H9 V/ Z' y/ n/ T# ?7 f) X+ H
5 x( W& ^8 E0 e7 P 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
' y- _5 Y3 N5 x9 @4 C4 Y6 ?
- `1 z7 Z2 b7 @% b2 p% S8 M1 H 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
8 ?( x) c8 e, k5 _
: p5 F% g5 J m7 Y7 l% o 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
" y2 R4 L: V5 @! w D: N: S/ D
; y2 ]$ X" d' C" BChunks) G# _# i0 Z; ~/ u5 `. ^! `
. E8 Q! x4 J5 W0 R* ?% U* O- x: n
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
3 q$ {6 n( I, ~& \; k+ _* S/ A* Q, }, [& }& T, d% C/ k8 H: K5 y! t
% `, t) I( i5 v7 U0 s+ V3 n
图1-2 chunk的三元组
) E2 T" A7 |8 H* P5 M) ^0 b4 I9 z
3 g+ p7 V$ W. O8 H% E 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
! p: I t3 D; Q) m3 F( A: l
* \ G2 i5 a' h$ y L 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
& G! z% X( L; w1 V4 O, ^' E0 u" y& h
# l4 Z$ A6 `- M# C. T, \! V Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
/ r6 j& }/ N# s+ }. ^8 K6 C% S- q: D/ n( y
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
' P+ p8 Z Y) r8 D- n/ O! l" r
+ m; m2 I( ^$ D h 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
9 x; @' ~9 O, r, t2 w- h9 J" K( D0 I, T; B# D7 G9 ^& I; D
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。0 r3 N7 ?# Y& [1 ]
$ S) c2 x) S F. ~
Replica set6 ~# ~7 @) e% B6 h3 b1 y1 A
8 d; ~2 A H0 `0 S' P6 O9 p 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。 Y- V2 A; a/ A& h0 }( D% T D
! M6 A9 }# N+ Y3 x8 C" v/ H 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
" M, J: L; i+ H1 a. f' {* r* b$ F0 h1 l: v" {" i( b! s1 I+ W* p% Y
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
; O1 l! q: w3 r6 p
/ v$ R Z8 H# _/ u U Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
4 `/ @! y( B! K& T
, Q4 Y7 u+ B! C& M2 U9 U/ nConfig Server1 P3 @! p& [2 g- A
$ ]( Q. s- m0 F) C E
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
3 X; r2 W4 a- M+ Z! _
+ ^- N$ }; g1 ?" w$ D: ^ 每一个config server都包括了MongoDB中所有chunk的信息。
3 ^& f8 x2 l! l, X
# Y4 L' l1 Z. c% L$ u. A Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。6 H1 Y$ x* z& z* c; s( h
& |6 i6 k1 ^( k A6 T- S
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
/ t+ l7 B* H3 B7 b4 H( Z. \; P. D) N" f1 I
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
( u4 H- z9 W. ]' d$ N# e: T) D2 D6 q: V+ N4 X
Mongos2 p2 d0 [- A3 E1 s! I2 Q+ Y
+ @& J- }8 g1 |8 `" r" X
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。; U$ U& l2 X3 T8 m: k+ _) e
$ t- X; K Q* w" c7 H: u0 w 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。/ i/ X) j6 ?2 {, d9 r7 O: T0 s) `+ @
# k/ A" A1 I5 s+ y: h Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
( a1 Y4 _4 w8 n/ I7 G+ a3 a
8 R# N, R* m; w# }0 n Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。+ o- i( v X* ?0 T8 X; O8 {
6 |! @# d* R9 J A) {
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
) }+ v& @8 W2 V9 w3 d
/ C( h" y; k2 L( `7 ^" Q7 A4 k3 ^( N7 [3 t0 c3 ^
Reference，! y _$ |( C( j8 a; N- Q. q
6 y/ W6 t$ u: U5 P5 U) C
[0] Architectural Overview
5 ?5 ]+ G, L2 c" g3 Zhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
0 W, j6 C' a9 E" E: [8 C |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
