|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
3 t% ]# f' ]8 a, {1 @. [1 a2 }# i, h' u5 J' z4 G/ g' L* E, m
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
' p' S# [. G U6 b& I6 u- |4 U6 c* \8 W# S. \, P1 n
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。6 g1 B; s( y( `
8 m# ]2 A; n! P, Z9 x
5 W+ B3 n/ [' U( f; f8 a/ u {: \4 F% i# ^, n# X) f
图1-1 MongoDB架构图
2 c _ v9 S2 j9 i* C2 n8 w: u2 ~- k! l' ? G5 W$ p* R5 v
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。+ x! l {, s) ]" X! a5 H) P
4 f, X2 }" t' J/ p9 R; N8 CShards1 ^ ] m# ~2 Y* G
: N. E5 B. A4 t5 u
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。 B7 ?6 e6 P4 _0 B" m
* i7 e! U& x1 U7 U+ E( j
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。% P$ \9 V! U5 g
# L% O# U- B' e- o. i# k 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。( O J, q1 h# ^ v! f' h* J9 `8 s
" O: t2 x& l) U8 f
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
4 w. x( P: ^; l C. E" C# u5 Z6 P1 _: |# F. ~ k
Shard keys& D' c5 e+ }5 n$ s! }& c9 O9 U
" [* o. Q. z- i6 O3 v; n+ Q2 `
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。9 X: s2 ~3 f5 z: M! k$ l
. L0 P3 P: S+ C) ?9 C, t; ~ 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，( I5 B2 r( f' V {! \) i
3 @+ [$ V' H8 i; E
{ Z: p' [5 D5 ]+ g: d: K; D
"ISBN": "987-30-3652-5130-82",4 Z2 U' x8 a4 ^# d+ l7 d5 E
"Type": "CD",$ q( h: h# V. ? ^
"Author": "Nirvana",
7 R3 r3 }0 f" c. y! [ "Title": "Nevermind",
, Z1 [! ]& s- `4 l" W "Genre": "Grunge",
; I3 U- b, s0 }" h, Q( U1 z "Releasedate": "1991.09.24",
8 c9 g1 t- v, E2 j1 y "Tracklist": [
" K! U3 [) Z/ K. @+ i) g- p {; J+ x- v+ T) x
"Track" : "1",
: t$ x) @1 b4 b "Title" : "Smells like teen spirit",. Y/ a4 Z j# j) L& Y
"Length" : "5:02"
5 X* @& @: t; e% a* t0 ? },
& H' z) v/ H$ y) J# w; l0 j {
: `) D8 W8 n1 P& w3 w) \; q "Track" : "2",2 y t! Q8 o# {( w5 x+ Y
"Title" : "In Bloom", b7 { w% e# `
"Length" : "4:15"
+ \. B. j! v& ]0 m' u2 M }% c/ R' d4 h& v4 H9 `! ~
]
( u+ L& ^ {/ {. n& `. e9 f7 k}
) t6 Q, h7 w4 l; |# f3 H, S& c ^- L& R! r4 d) U
{& A+ P, P; w& u( F7 s3 v
"ISBN": "987-1-4302-3051-9",
9 ?7 L% m5 m! P "Type": "Book",
6 E% T! L c C6 X5 G "Title": "Definite Guide to MongoDB: The NoSQL Database",5 `- G7 A- p4 ~/ T E) |
"Publisher": "Apress",
9 e: D' L; p: x; w' J "Author": " Eelco Plugge",
7 t7 |% B4 Q" ?% B v/ ^+ U "Releasedate": "2011.06.09"
: O* z: K# A4 N9 a9 l: F# F}
- `5 z' V4 [& g& f2 j/ i8 {: g; Z d! a6 E1 v! u" |
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
4 Y) G! g8 e; D% {% ?/ W& }0 | j& d8 R4 J4 T/ s
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
7 f! H* r+ F4 h6 b) N5 l, g, M+ f8 ^: u
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。" y/ y/ ?. F# [3 @9 H# ~: b0 r
y! X5 e" @, E! f2 a) l
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。4 `2 k. k1 D/ S2 ]
( h) ~; n/ Y+ D R& \! `% }" n
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
: }" C) _0 m( d& ^: D# h3 H
O9 C4 F; s4 ]( OChunks
8 _' q5 I1 E! b
$ d' _$ l* K/ j7 j/ P7 J MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
/ k+ i' f% W4 f9 @4 r0 z
* n! @, ^0 p5 n3 V) K. ~7 C
2 P u% H4 L/ q5 F9 Q4 L( |图1-2 chunk的三元组
, U/ X* z5 F# i1 q! S5 Y2 A+ L N4 C8 ], }8 d. F2 d) h3 J$ U$ `; N
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
# f" a, [0 N* Q0 @; P m, D6 q* ^6 V4 A* Y8 X
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。) m. A8 \4 p6 [ Z, s+ ]
; u! g7 Q- E% R0 G5 F
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
; O; T. P+ O& a# n( U G6 M; |1 `& M# x& B
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。) V: z& h; Q+ \. ^6 T; f, E% S( p
* e# b8 n: P) u2 S1 Z9 M7 p5 f" H 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
9 U) H1 d; N* K2 Y
6 `7 L6 m' K# g& m7 [$ r 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。 [, ?: f! ]$ _1 t9 {9 K
) n9 Y$ O/ o# a- \/ o; OReplica set
% Y9 K4 v" ]6 H5 Y0 @5 }, ? # E4 b* j& b+ E0 Y- v6 [7 y
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
( }0 t/ l/ r7 p2 S' W
; \& B/ c% D7 H 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。* s1 S/ ~" c8 i- l9 \* b
# N3 ~; u' w8 `5 ^' v0 Z8 B Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。7 B! g3 V) N. p
6 i$ U6 R: f- G! Q Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。. l" K7 v1 [* C: {3 i7 n& m$ @5 [
3 V* X, v0 s+ J. [
Config Server
3 k* K0 ], I& Q' R& F9 T. J4 p / ?# D( R( r8 T
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
' L5 r ^! B" f2 S
- T, r* Y/ G. ?6 z2 `: ] 每一个config server都包括了MongoDB中所有chunk的信息。# K: R% F( t; E6 S1 u8 H4 v
5 v6 w6 K. O, h; A$ k- q" T Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
4 p/ Z: d @* |* J3 {3 O" Y" z; x: j% _; E" V1 M- m( c
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
) X$ p1 m- O. A# Z. R4 f8 k# _" V! z9 r" A7 \: U
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。' R; u) Z1 Z( S0 Q# F
3 x- t# J5 V/ Q H1 s' h3 I: WMongos
8 l4 E$ r, P. w- e& _% @! ?& N7 x, u" p% ~' q& g2 A2 {4 b: @" p: y5 a
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
/ r+ s$ `# u2 N- H( }2 E. J H: K) e+ x$ D& O) P7 _: r# ~
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。6 ~+ p0 s: c; |0 q7 u% F9 _
+ M6 q* D- ]8 S3 T
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。) f" c y" z {9 B2 Y, o% a5 u
/ ^1 F: W H+ e* R# R Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。& ^! g6 `9 N2 s7 c- ^! t9 h
3 R" D' ?# T# B% v: j) D 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。8 x+ a8 T2 u+ M
( _' K* k& Q0 F- I8 e; f- n$ N
0 U' O: @6 ?. p. P$ ]Reference，
; N# E5 g$ o* Z1 B% e9 V4 x# F' T, s2 M/ s5 H
[0] Architectural Overview
! y5 w4 r6 Q; _" T' g* |! Ehttp://www.mongodb.org/display/DOCS/Sharding+Introduction; Q6 E) N1 m* P9 h0 ~4 O
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
