|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
; D/ B; R1 I1 o2 P
" `) \ s9 T) x. t* v/ H+ u 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
0 ?$ q( v7 Q' C7 T& P6 \% |7 `7 f! b- p
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。: ?1 p8 T3 W" T/ Y
- `- t! a8 Y- B! E0 H
, | a+ x- b7 b0 v+ G/ c% @
! P- _' Z6 f/ J. M, E: g# t j/ v图1-1 MongoDB架构图
, n( G" m8 `5 p+ F' S+ ?
/ d; o8 Y6 ]8 ~ MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
9 k) m! H; [3 L0 R( s/ @; X4 _* H* Y; @/ B! p! ^/ p
Shards
; c. ]' c2 j/ [* B- v4 Z* a- y( v8 ?7 P
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
7 `1 a1 x. n- r5 R4 g& U' R/ ~4 T$ n! n3 O. N8 m: t, M
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
& P9 [8 d7 x; y. r( \+ B% J3 a4 C4 `; N1 p0 X' Z
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。" Y: V8 k. E: z7 O& C+ ~# ]
S: f% w: m$ Z ]$ u9 ]9 v/ L# c
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
3 v) U% c; L7 l( h; M* U: [+ n- p7 T! p9 e( s% k- I
Shard keys
. c( p& ^& p5 ?; p! e $ a {- e3 Y d5 b! f$ K
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
* z# m5 W+ G! x# o; Q
8 b$ B& u' A+ O# e/ H 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
1 h9 l/ r# J) s+ i1 h" l, b( m! y/ N* {6 L9 K0 T: ~3 W( J0 P
{: N; X* b; Z. @- ]# H+ n
"ISBN": "987-30-3652-5130-82",
# ? R5 \: @( E; }- n! v "Type": "CD",
( @2 C/ k% g2 o2 I4 ~( ~, O "Author": "Nirvana",
" u6 \" l3 s! [3 w$ R "Title": "Nevermind",
: Y1 f/ r1 x+ q/ c, k) v "Genre": "Grunge",7 t- B- y$ K8 F$ F5 a
"Releasedate": "1991.09.24",6 [* y9 P3 q. a2 ^: `
"Tracklist": [
1 Y% u! H+ n2 }* M! U. v {
0 M! @& s" @" B2 P, C) @2 b8 f0 M "Track" : "1"," v+ d& ]. T- q) p/ X0 n) r
"Title" : "Smells like teen spirit",; b$ \' C: y4 g3 B
"Length" : "5:02"
+ \ N b; a( a' g; r+ w# k# s },4 v/ S) f8 ^0 K; M
{
7 J0 K3 m# L i "Track" : "2",
d* T5 l: x, W- R( V* M0 Z "Title" : "In Bloom",: M9 @' D" b, x3 y
"Length" : "4:15"$ ?# F6 j, F# F; A* N# M( L2 K
}
1 E5 y" M \1 U1 f# P% T4 { ]
* [0 }- j8 r K0 r9 B- j}& w- P' O+ ]- @8 m3 g% u" l
* j8 t9 y O- G% G, @8 V: Q
{
( z/ J) O- z: x" u6 s; v "ISBN": "987-1-4302-3051-9",/ i( g& y0 t1 k; b% m& M& h+ \
"Type": "Book",7 `4 H; n& G6 d/ l8 W4 c3 F
"Title": "Definite Guide to MongoDB: The NoSQL Database",; ~, e9 X, s$ ?
"Publisher": "Apress"," ~' h& X5 Q6 g% e4 K) d1 x( Q
"Author": " Eelco Plugge",7 Z6 y4 W1 I" y, Z% k$ w1 g' t
"Releasedate": "2011.06.09"
# ~( I3 h7 U! f6 J0 e" X}2 x6 {- g: a! h0 q/ U0 Z0 a
5 \% F8 K5 w: W. R9 l m 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
8 A7 Q/ O8 O( O1 e E- Y
1 q3 V, N2 S$ Z3 A 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
/ i. U3 d1 ]' w. @4 ^, ^3 B6 F& ?
7 B, n1 H J5 P$ V( W3 c' v O 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
/ g( {1 O5 ~. _& e/ n# s5 v0 v
# h% L! F! `6 z" o" B 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。5 b5 U. J0 e7 F% M" {
2 ~( ] \7 I) l9 q6 N3 ~
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
4 i7 P) V+ {% _$ k2 F: C
, t5 |# p- ]9 Y7 |/ m$ ~7 B n. c; SChunks
' S1 a7 R# [" M# v ; p# ~ Z9 D t, I& q7 M0 _2 |3 C
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
$ V! S. U6 U: R) }9 c, G& S7 \/ K% Y G9 q
( O. k6 q" S% x, K9 ?7 `图1-2 chunk的三元组 6 }3 k! T. \" A
2 Z N! Y2 b0 D
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。. L7 [* h8 z' ] m0 h1 Q) f% G9 ~
! a, g- F# y) k5 G. w 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。! I9 X0 q; j0 A5 T+ C+ u
" {1 F; o9 a3 T" v3 _1 Q
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。3 l9 P* m3 R& q) ?9 n$ n
) ~; |" N ]+ N- u
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
2 I% M" x' N, F
2 a- j8 r$ e0 v% f& I 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
2 t4 E& p( z9 [
8 U N$ I2 @4 x+ i6 N 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。9 E/ ]' N8 M$ y. o
C# t2 y% I# j0 R7 J( c
Replica set
( ?% g, c4 k" j+ I0 i. l- i# g% Y * q' _ ?( j- M: b! H: J9 U
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
8 J: v% L$ ^0 z* G/ t& o6 O: n1 I
' [0 l+ }3 }% w1 [ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。: N7 e, |* f; H* A
1 m0 W7 Q s0 @3 u% d: l8 H% Z1 z$ Y" ^: f
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
7 K; G. m5 |" H9 C& J* b0 ~+ M) a: O1 O0 @% c
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
6 V) i* I0 q4 Z' e4 ]
, r/ E7 W u& e0 O% g. ?1 i" b5 nConfig Server
0 g2 ?, I$ p3 w! j . [* m7 {: [" p) ?$ \
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。3 I) b5 e" x- q. h' J* \
# {- M, n0 U) z' j% ~: z+ I; a' f 每一个config server都包括了MongoDB中所有chunk的信息。
% K! W: `* f7 L5 b
0 X) y# t: L- V: l' }) r( l Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
: \) @. r& U4 _- Q+ z( ]3 r6 C L, E
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
! s3 J- w6 K: Q0 J
( R2 B9 N3 k7 A$ S MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
) j6 D* k4 w# ?
. b+ l) @! L: c ~' e( _2 X+ ^Mongos
: l4 R" [* \* Z; m" w6 N6 L. Y+ t2 M9 c7 J3 m1 p
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。 H! x, o* w+ ~7 c+ p ` [# [
; v4 G& Q% Q. J" Q& P 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
3 r+ y6 t4 `, O# L" K4 g, q7 ~( f2 F3 A" E! Q D
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。# G" L/ T& j) h! j3 m" C
2 ~" {. P' U/ N+ E' t Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
& Y: Q* D; l4 P- {9 X+ A) f; A8 r9 f4 z4 Q+ _8 @
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。- J4 {3 n1 ~" J+ @
0 v) [$ ]) J8 L4 Z* q' O7 u
( @# a! j' D1 ^* H, J4 _4 RReference，1 J' m( I% y* r6 R& l
3 M2 p s/ [+ ^0 r
[0] Architectural Overview
5 v% f6 p$ W; b3 Rhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
# Q! W8 R1 l! M% r1 c |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
5 L% O7 [# V4 p' \' {0 _, l