|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。, |2 H8 n% \- X/ J
" H/ O2 l+ e7 w. ~0 U2 } 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？3 q. u( Y7 K S! k+ K0 j
: F+ ` ^7 c, |( u5 V5 K! w 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。: `! @2 f. L# G: n8 M0 G
, T6 j$ [8 c: T* [$ r
. v. f+ |, r5 z6 B
) {, l3 Z! u3 v% E5 }图1-1 MongoDB架构图
9 ~" w; N9 }+ |4 ?" R! s$ r
: z3 B& i- d+ m7 r9 [6 {) `$ c5 [# R4 A MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。' K/ F2 }7 v$ Z( t2 l/ t$ W' }
7 Q3 `9 A0 x: d+ _0 A, wShards: J. o' J4 M' d
( P S: Z+ n& A! B; W0 W- A
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。% a u' Y/ i- d3 H6 p( Y5 X
$ C: g2 O# @# Z6 p, N Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
1 l1 ?. b/ e& Z2 m; k7 Y7 Q4 R# R5 q$ C% U4 O- o4 F
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
3 q, t7 m1 Y& ~6 x
4 F! G( v. v* {6 j/ K 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。# i8 ^ s) M% }) u
" h9 S9 r1 c. ?" j3 I6 N: r
Shard keys
2 H$ |9 \8 c9 y& ?8 x
- A) N9 K3 V: z: j6 U4 O 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。- M! g' E" C! v- U% V0 d2 r! C
+ a6 X, N* A9 @; E2 l" l5 i: \9 n q9 C
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
3 d* f r" x3 a j. x& b
. I) p' i4 D" b& T" e{/ a' c% A9 u8 h5 g0 f
"ISBN": "987-30-3652-5130-82",2 Z( t$ h! l' E& h* k) H# P
"Type": "CD",
+ \$ H7 F2 H% ?% [; ^0 q4 M "Author": "Nirvana",
) K$ H' i* N3 ? q C; ^6 M "Title": "Nevermind",
7 |8 b5 Z- I4 q# J# N "Genre": "Grunge",) H2 `# {. _ B P1 y
"Releasedate": "1991.09.24",
1 `; ^8 F, N6 Y7 K9 `) Z7 S. ^ "Tracklist": [- |( s+ y8 {7 q. |
{! N8 v. {" _3 F! W7 R1 R
"Track" : "1",+ }/ I2 }. R2 L$ r. E, v
"Title" : "Smells like teen spirit",
) J, g* ], `& W p3 X) b3 d( { "Length" : "5:02"% T) d4 k2 @( } V2 D" r
},
+ l% b+ h6 }) h {0 \, m1 `9 ~+ E, `) g' o7 l
"Track" : "2",
3 T9 V0 v- f4 x# b; c: q5 \ "Title" : "In Bloom",! H" e6 C5 L, J/ Z
"Length" : "4:15"
# Y1 c( y( ?/ H% M1 J }
7 @* D N) h Z8 v! C+ E. \" T ]
! `/ t$ Z' c3 S, q) B0 A! @# O}
; x _& |- a6 Y0 Y1 t( ?; f6 t' t2 }
{
2 F3 K2 Q; E5 W( Q7 z "ISBN": "987-1-4302-3051-9",
' K0 S# S5 V# `0 k+ Z "Type": "Book",
* l; e3 Q& m9 |6 J "Title": "Definite Guide to MongoDB: The NoSQL Database",! Y' O2 d5 {% A$ ]' J* L
"Publisher": "Apress",
- @/ n: i0 j( f; V/ o! X1 C "Author": " Eelco Plugge",4 e- o3 a; z6 k* R" L- n# }: C
"Releasedate": "2011.06.09"
3 b0 ~& m5 |# N}
" i8 z. J- f$ \: M* E* J0 b; \0 {8 H$ {
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
& f1 T# h& @+ |: n! U9 d& s# K3 x! `+ d! U
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
8 B7 r/ h6 i7 K0 ~
. B5 s* @" g& b& ~ 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
9 R2 e- {. z) G6 V% i2 V1 ?
4 V. `6 K1 d$ `% L8 v: n/ {* W 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
9 D/ R$ v; Z% P* J+ }5 ?
& R9 m9 A& E1 b2 p4 D+ R- k 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
/ H: o; v/ e0 H2 V x+ O) s( @( B! W+ Q! J3 j6 u
Chunks A( `3 P# T* o0 n
5 v" ]3 a' z: H: e: A6 s! m3 \
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
6 p( w U" S, u0 c. S9 k
! n) W7 `2 J1 l/ v! H/ z8 M
! D* h6 b+ K6 m5 ^$ ]
图1-2 chunk的三元组
) `% I& a+ J& _! L. a: D+ ~! a- I7 ]$ s
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
4 k7 F" @6 [1 _/ @8 }: Q* Y; D0 r4 D3 c2 [/ |
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。; {( y' q( J: ^+ \. i
0 c1 g4 M, d& M8 {9 g Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
6 J1 T# E, I M( }; m0 H) r3 j0 m
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
( v% J- e) S, R: c! S/ _$ _- L( b6 _: F
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
9 d& J& D4 T% f6 f6 ?0 z: v' |* |. g& |6 Y
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。5 w1 P. l3 N9 @" X, R$ p) U
) c2 E& ?; B& kReplica set
. n' P7 L- u0 q7 G, L& S; z) s
( \1 K* i8 q. v. F# _ 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。7 g/ G8 _/ _: y; C/ N" Y
! V: k) [% z" h& s0 V 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。5 ?5 V; M; T; T" l5 |: x3 `- J. H1 G* H. e
9 S, J6 y5 N9 V Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
6 R6 f( M3 l1 x/ N3 J3 A ^2 v
) E A6 T, t9 A8 C! }( W; n Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。$ I B7 ~6 D6 W
6 r. I! Q Y9 H9 @& \ U) k
Config Server
/ K6 k5 f! E7 H& v & m3 Q, g5 _! c4 C6 L! t: l* r
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
P0 k% t( [7 Y. m& n. r( w N; `" Z$ s# V; S
每一个config server都包括了MongoDB中所有chunk的信息。
- k) W0 s9 y9 i Y9 u( ?5 V
" A4 j7 m& C& V Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。7 ~3 a1 h( F0 m( ?/ }
- t- O" l* o- X5 h, f& s
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
! w! [- f6 j& E1 A( D6 Q& m# w3 a, ]7 k9 t1 }7 {0 H+ }
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。4 d: L% r, I' C* A5 |1 o
8 }( Z5 S: m: L$ OMongos. M, b' `9 h- r( b9 B. k
6 Z) m6 b$ z" `! ~! p
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。$ B" M( n( c$ M. c
1 q# b' v2 d+ M# B% c# i 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。7 y! t- I2 i6 r8 D' Q
( ]: l5 e# K B/ A8 [8 v% D& m Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
/ `& N) w7 Y: X: T' I+ w) G
$ p/ g5 D8 t1 G! V* Q$ e! f Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
2 @0 E9 ~% e) R# I, G& J6 r, d# H7 Q- E# m. }9 x4 U8 p
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
x! o% Y2 ^& o3 P! B7 e/ J* f
: Z9 x( E* E1 b& N; d' }3 N8 }2 c
Reference，
1 e+ \( u2 ^( d' ]7 @% s" w. V2 o* N, [2 B
[0] Architectural Overview
8 I5 F5 h, S8 b6 O0 o- D, Chttp://www.mongodb.org/display/DOCS/Sharding+Introduction- }, m% |% k. }5 ?5 P) y$ D
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
