|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
. r. W; ~7 `/ |4 R8 G/ _5 Z
6 b$ p0 @5 w4 q) s+ D [# {, j# g 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？0 C' l$ R8 G" X
. S6 Z" [9 w- ^0 a$ C$ P 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
" P6 `& S. w. ]$ p5 \2 v) ]& U4 Z
" O7 C) j! U! I
1 l% y% l' G# ? j5 l% _- r) l# F; u. z6 ~; O
图1-1 MongoDB架构图
$ u. A: W) J0 H: \! c$ f1 {+ r% k
! q* S$ z' f7 B MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。, I5 C; h0 P. |& `
, w% [3 R# E: c+ a1 JShards
+ [/ R: b; z" u: T4 _( ^4 y$ P3 m, w! D( K6 ~
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。) Z9 \: F! k& C; J8 Q2 l
" `: E: `+ O$ f' Q Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。! V' U. ~% I+ r0 v* \
' w* @/ P+ R; s) n# n& I
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。& h( g6 H2 x2 u& a
* r' N. T, t6 K2 _ 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。$ `& p# R4 \; t0 \3 i) O! d: h
1 B5 ]3 q$ B) {
Shard keys) J2 h5 w4 O3 a3 a
! D0 ? I% j) g$ }' H. O; D
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。. K& ~0 j/ Z+ a/ X9 t% w
1 q9 [! ] ]2 p9 n- T
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
' ^3 e3 E* n) } C$ n; q
; U2 D+ j6 s+ e" q& ^0 y{
4 d/ e3 S1 h. M% E$ ?0 U "ISBN": "987-30-3652-5130-82",
3 \$ b. C. D0 e9 h! } "Type": "CD",8 r9 K) [' i9 w. q5 q+ O
"Author": "Nirvana",
7 s. o p3 {! ] "Title": "Nevermind",
/ O/ P' I% b+ S/ @, s Q! j "Genre": "Grunge",4 H1 g) N( ~' b8 P& {8 k: a; b4 T, T# J
"Releasedate": "1991.09.24",
3 u' a' _5 I. Q. L# Q4 }$ V! H "Tracklist": [
/ U4 W8 `- {8 r0 L% R4 k9 H- q9 Q/ q {
# s( Z: u; J; V "Track" : "1",
; k4 k5 `5 C+ Z" n s' f "Title" : "Smells like teen spirit",
) C$ |# p8 @2 d8 |8 U) q% a "Length" : "5:02"
0 G: f% M5 v# Q1 [ },
, @5 j# a# T! z* R. P, P {
: W9 d5 F- k/ H1 T "Track" : "2",
0 T" C. ~1 G8 @ J# N "Title" : "In Bloom",
; f3 ^" j8 ] s1 z U "Length" : "4:15"9 S3 Z# e, o$ e. v/ a- O0 x9 t
}
% X+ L3 d- x, q# B, r0 _4 N ]5 j: t; O. {7 S; k& ^4 i# O
}
( @' w, P1 S i4 y$ d* z8 t8 W; T8 x# p' x# _; J8 i
{- x/ o0 T" O( Q+ `' R$ y
"ISBN": "987-1-4302-3051-9",5 V; @% D W1 t6 k$ l9 |
"Type": "Book",
) d6 c' V4 K5 m9 x3 s# D "Title": "Definite Guide to MongoDB: The NoSQL Database",! X8 H% D0 z% F: S
"Publisher": "Apress",
3 X/ S# i/ {; _1 p2 G8 }7 u% g& J, T "Author": " Eelco Plugge",% D) |7 s$ G4 p1 `" e9 B
"Releasedate": "2011.06.09"
' N* w t8 r0 s0 S! d}
' Q4 U8 g6 o1 i) {6 V! o7 x' X1 @* o; t8 F. @
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
( i: f6 i* Z) E [8 G" Q4 Z( X( V$ s2 r, g* C* e# [; Z
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。* Y5 w4 D0 ~; E
2 P4 e. b2 u0 |1 _& G 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
/ q/ |' O: P3 n/ }, \( j4 }) f- r: a# }1 g8 ~
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
( x* z7 m4 _8 r6 f3 h" Z [7 J: D0 n9 r9 E* s7 u+ W3 ]1 \
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。% i' A( H1 ^+ Q/ f& q$ c- A% \1 M
: {; J8 R0 J+ V# L5 i8 G8 h3 jChunks
! L, w4 B: u3 ?3 f1 x7 R9 H! e* O 0 }2 g% a! b' E" f. h/ l) Y
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。) A: N5 ^1 N0 t p. r2 A, t; Z
0 I2 j( o$ }( g1 R- `
: N# k5 u8 t/ m+ |' ?
图1-2 chunk的三元组 ! B+ Y T( J1 h% U# y3 f
1 j* Z2 `9 [3 D3 j7 l 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。. b8 ]0 x B r& T' M ^, z
/ e1 A, t" \! D% W0 p' c# @, a 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
: g4 }3 l' H9 O
; X4 K3 j0 F0 g$ D v Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。8 G* _/ t3 W. z( w& k/ h9 l& _
4 k: H" f- @0 F" z
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。+ O i0 f: t7 m2 G: M% C
1 X# L$ |+ F% R3 _
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。1 y. F( j1 ?+ G$ _% p. V
/ | k; s) p/ K$ R T2 x6 x
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。9 S) k& h; a- Z* j6 S+ G
6 S |4 [( ]' w
Replica set
" ~) x: }" `. ?! o9 g# n$ ? 1 K. ?) p* F& W$ o# H' `. H+ |
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。- I! p9 `) r0 {- X' D+ c: j# J
" [8 ~, ~; k+ T7 q! e; N0 C 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
' }* F) Q4 Z, N" |# W. q# X& K9 m9 U9 H+ L1 f0 a- j, @$ n/ H
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。. [$ P( {; A7 E* T2 z$ C# \+ @( ^( c
2 ?) T, N* X4 c3 Z% _4 ]$ P
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
! H! s: |& p; p7 V" x0 g, B- Z% w6 _2 ?( d- s1 T
Config Server/ Q) X! Y# f1 ?" H m0 Z
, X4 j' ?# i3 _ Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
9 t! X. d/ t" Y8 M3 m n+ z$ V8 r- ~( ^0 d* `, s6 `
每一个config server都包括了MongoDB中所有chunk的信息。0 D5 ~4 u5 F" B6 A! a& q
+ t4 H2 Y- `% D/ g, `" l3 ~
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
3 w, T5 n) |! |7 F6 H- k. \4 n) L# Y" T5 i' U
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。6 t6 V2 o0 W( o- f6 J2 P
) l. r6 `4 `, \4 E, n8 N+ x MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。. L* u: ?4 B" r
$ R9 W3 Q- T6 uMongos
. K2 E2 d6 E# O t, K1 N6 e. u% x5 @& w+ l" h5 ^9 T
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。6 X9 t! v- m6 B) G+ f* O
6 r& H$ P! K; x( l3 \
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
3 m( @4 G5 f: h3 R
! W$ W, l6 e6 b2 P6 \1 _ Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。; c+ Y; C' W+ h7 E) M
) ~- N# d% b% Q) H+ L
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
|2 h6 ?+ C% T* x. k/ I/ d( ^
- ]" |& V+ ]5 e( w. |: u5 ^5 { 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
. W; ]5 b6 H( u1 T6 T0 V. ?' D d a4 X; T
0 y- W3 ~/ u& c K* x0 |& I. l9 o2 H
Reference，
. M5 m5 e1 w, ?9 d0 D* @" q9 p! Q, p
[0] Architectural Overview; p, [- W- k+ T7 R0 r
http://www.mongodb.org/display/DOCS/Sharding+Introduction v) y! O9 [4 e- y/ n' d+ ?
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
+ j- a7 Y( F5 \1 M& z" Y