|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
5 \ w- r& K! j! y* W+ M" n: g9 R
2 p& K' U J4 F( { 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？5 q, Z' |/ F, K- D6 t9 P; G! ~
) {& J1 r; Q" `) h) `; e 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
% e4 d$ r. j+ W: V: c( [* W" |& i1 _2 i. P+ U0 a
" {& ]& J. n" u+ P! }: [! M
, B A# Z4 |. i ^& h图1-1 MongoDB架构图 . B% N: P4 G% D; z# ^3 z
$ V! w' k& m5 {( M7 K* l MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。6 V0 g9 j% ~; }) M7 R
% j, X9 E0 S! f) l# I9 k6 P* T
Shards
( i2 \6 Z) J( W% e
4 A, R2 [! V3 i2 f7 t MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
) q5 n8 Y& F* i9 P1 g( A5 g3 \0 t0 t) s) D4 B! O9 E
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。$ f5 U, f8 e* D, P6 p D) V
/ j9 B# a! C0 d 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
5 x. w) H! e6 S' V$ t3 C2 A+ a; k& i
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
/ W ]5 [- f: f6 y% r+ _' u8 }8 x3 _; a4 H# [- Q+ K
Shard keys/ f2 o( u) p, i- x) w
$ H3 H' i" p3 @" i; x 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
' L. o2 s+ b* S' o/ u# b/ }. z7 ?! n' r4 v+ M) n: `
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
6 |0 h! j/ Q5 ]( @
& @' t9 C$ S6 G% Q" l7 I1 q$ K* o{8 i5 R F& e e( ]0 k' P5 B
"ISBN": "987-30-3652-5130-82",' S# Q0 o: p ?, e; j) \- x
"Type": "CD",
' f0 O _4 a' v$ b% y* \ "Author": "Nirvana",
) g. a8 U$ o; M w4 C. ^ "Title": "Nevermind",- K5 S1 r% M- Z: x8 h2 K
"Genre": "Grunge",' {5 i( _+ J# y/ l
"Releasedate": "1991.09.24",1 X5 z5 X9 U7 [8 D5 i' R# }2 y! c, u
"Tracklist": [
T B b: N5 w3 ]1 a! h {
3 t% m$ h7 l" i) ?9 |" f "Track" : "1",. I/ f1 V8 U+ A& q
"Title" : "Smells like teen spirit",: s* V& P2 V0 q4 f
"Length" : "5:02"
) t1 W g$ `6 G+ a) u! {- G! @+ S },2 |5 {! O9 Q' c8 k; T+ @) v
{( b# J b: ?1 c; w5 y* q. m: ?
"Track" : "2",
* ^ Z/ N" V# J$ G9 @ "Title" : "In Bloom",) v& V* `/ j+ Y6 l% u$ B. X. F1 ]
"Length" : "4:15"
: j: Y2 x7 t' S }; S! U# ?: D% k" p5 s0 W: f) t! D3 t
]* k- X6 N' j; t2 U( Y! I) ^. w
}1 Z7 q7 H* G7 f' R- m0 L
! {& e( [ M m3 c
{
' A R2 f# v- B- v5 L "ISBN": "987-1-4302-3051-9",5 \) U5 A5 l" H6 M0 e- U( q4 p* m
"Type": "Book",
+ f, X9 Q. Q" B, n* n% j "Title": "Definite Guide to MongoDB: The NoSQL Database",
4 G8 J6 U3 D6 Z! V6 }6 U6 t! z "Publisher": "Apress",
3 M$ j, M) Q4 v6 q L \1 S, H "Author": " Eelco Plugge",! O8 |6 Q. k% ~
"Releasedate": "2011.06.09"
5 R$ p0 x9 K( [2 _/ M/ w/ h" ~0 e}, [0 `/ E6 w" s4 A
l) G m* W ] o
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。) R0 X- Q' C! r2 N E9 W
7 {; c* \& K1 Q9 `; a0 L# I
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
3 k0 ?$ {7 I/ w0 D( L [* z; t a) e9 }" [1 y
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
, E: { M% y$ r: h+ v
) z- s9 p. h; e: g 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
" l; y$ k, Y% H! [0 |
/ t0 O/ f: n0 {2 Z- w6 N2 R 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。. r7 G' t$ _) [: i0 c3 Q
( n- o' Z, ]! ^3 E6 Q
Chunks$ _0 G- l, H* g. V3 g7 G4 j
& m; n0 y) Z, ?, y5 ~; j
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
+ t! D$ J& x. E4 u! U' B7 W! a
* N* q5 _: D; N# p2 m; b# g' g
' ?8 p) S$ d Y, ~$ F
图1-2 chunk的三元组
# z& C. r& \3 c. T$ Y
& P* V; l+ e* d 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。, Y! [1 k' E, m8 I) x8 L* y! u
- ~5 s. e2 a) t& m3 w& I9 R% f 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。; c/ {) ?5 d: A- p. c- Y( c) B
9 n% p! H& P& Z9 E- K5 ? Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。$ w8 L( S+ L1 @0 P: \* M: ]
9 d1 ]3 g1 t' \; ?: j F( b 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
6 R2 R2 J/ X0 h! y1 i6 R* p+ d4 j- _+ k. @3 W
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。7 ~& N6 L* r3 v+ ^4 {
: c! u* R- x4 t% ]1 g6 y4 P
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
- o i' A0 W6 C7 m Q
9 p! z; t0 M1 K4 }" g: rReplica set
0 Z; I/ s3 k1 y3 B( r& o . V, D# _7 M. e$ d1 a9 p: b
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。+ N6 C: J( [2 K) w
4 |) T0 G! Y; o. d. T 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。# {: Q: L; Y( O1 N( l6 L) w
( k* U4 d% B8 i Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。8 \7 B& t3 W" g- r/ Z) B
, y) M4 z4 a% ]1 a. l
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。/ A, R& e' k l3 x$ N
* ?9 m% C& `; [' QConfig Server
. z! y7 d2 H$ e1 G: l' _$ N' {! F, Z
' u9 S. z* ?; B h Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。* R' G& q1 x. ?8 R8 r3 Q$ _
. N; L! L [8 k- U4 u9 x4 q. y b 每一个config server都包括了MongoDB中所有chunk的信息。
3 v0 }" `) q5 |& E) W$ C8 i. f7 H2 e1 ~9 q6 Z# C; |- S% p3 q/ a
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。, C) V% j% n a0 v% i9 a) X1 F
& t; z# B7 U' B* A3 l; ?2 K
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
3 i- P- B$ L, w- E3 ] g, C' q1 Q: q3 U
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
% m+ i* e1 n' J1 _
* d m; [) n* q. U4 u/ nMongos: l2 r+ C) J& G, j* Z- Q
2 i( ?5 t' @4 G, f) z0 a; ^: S/ O/ d/ w
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
. j% \! m) |& u( k( E7 K" M7 H
- s2 v9 {* @* ~3 k. [ 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
1 `5 w! I& p" e: ]/ ~1 j, n" c8 ]9 u; h r3 y% _) j& \. I
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
$ ?' U. s* z- M: `" y
% j6 \$ _2 A: h Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。4 D' l4 S1 c; i2 {/ F" q( S
- L: w2 F3 v7 ` 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。- R+ X5 W ]7 |. Z1 z) o
9 N* k! ?0 @" ?& L- b: d
! U! i& m1 Y; n4 ^6 b& gReference，
$ V; ~7 X* O. f
- z2 F0 s1 V) w& j* W2 X" r2 a[0] Architectural Overview
3 Q: a( k4 I; N5 F8 Ehttp://www.mongodb.org/display/DOCS/Sharding+Introduction2 l5 p, N! A. v& Q# C
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
