|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。" e" ?2 u' q+ Q Z! G; g
2 [9 F9 U/ _2 d9 p 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?4 r2 s! E+ r& N& A
) h' u# i: k6 r; n( U; f) \ Z1 w 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。- F1 M) w* w( @9 A$ o/ e
8 o/ p ?3 Q$ s4 I3 N" [* f- J, Y
( F- P6 Z4 \' @- u- C
1 d: |- B5 f, O: M6 y
图1-1 MongoDB架构图
8 I7 O0 T" K- I* j' y+ B) {. n; E& x: U/ }
MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。
_' b2 W) C: Z' ]2 b. d9 [7 Z# ]5 z
Shards
) f: Z( a; {) \ j( Z
3 _4 c2 P/ _; w& K MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。
6 c3 B) R3 Y6 _& J% N/ u) @: D6 P; h& b K) S% {
Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。
: |7 @# f; ~# A# r9 z! g) E$ M. i4 i3 d
每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。, E7 Y; o- G- P9 \1 H& c+ k; a
8 v3 K, P$ v# j+ t 如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
" k% k' U* L( |" ?% n c- k
~* A4 w' Z5 n' A' gShard keys3 e) H I: U9 |5 i( R
. |. H# R- g; D/ }8 F; W
为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。
* @1 q7 O2 w6 S; Q* E( r5 ]$ c: P7 c( d0 [0 g8 m" Y. K$ ?! f* B
如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,& z4 e' o6 O$ T( I
; l& P6 |3 f; h+ M2 |4 n) M{ T- ?8 Z9 e3 }- _, `$ E0 j1 o
"ISBN": "987-30-3652-5130-82",( a/ |/ w4 t# L+ Y1 y* ^
"Type": "CD",( N& K3 @0 Z _7 t7 _! d+ G
"Author": "Nirvana",
9 t' i. s% V3 ~. j4 j- U* m) H: s/ } "Title": "Nevermind",/ Z z) z) @1 c+ d1 `
"Genre": "Grunge",/ ] L- J0 L' I! y8 F0 L
"Releasedate": "1991.09.24",
e% s& H9 \+ G* J3 c( g2 B "Tracklist": [+ N. ^% [ J0 @) A z6 H
{- U9 P* d, z7 f# G& _
"Track" : "1",
1 [. ]6 r6 `" ^ "Title" : "Smells like teen spirit",9 U$ ]; H% g% Z4 m. j" T( I. g
"Length" : "5:02"
9 B, J. x2 [, `7 j8 y! J. | },
3 \; @ d/ p( E5 m1 o {
: D# P3 v7 U/ V: S& ? "Track" : "2",
# r1 k9 `1 z, _) B "Title" : "In Bloom",! h8 P, A+ j; h4 t
"Length" : "4:15"
2 U5 K9 v$ r g [: g& q }' M4 d' E ~" g3 S* ?5 t
]# Q8 K1 p- l: ?4 E+ u0 `
}3 p+ D, L5 |( w! e, t
9 e8 O, O9 E' K, K{6 X! I$ S# Q8 @3 Q: Y
"ISBN": "987-1-4302-3051-9", f" M( c& T1 i( @9 ~5 y
"Type": "Book",3 n9 ]5 s5 h( w
"Title": "Definite Guide to MongoDB: The NoSQL Database",
6 R' v; E5 A5 M# i a "Publisher": "Apress",
4 x& _6 f j" @9 s8 D- Z "Author": " Eelco Plugge",# ^& u3 ^" ^! H
"Releasedate": "2011.06.09"
F2 F ], Y- C9 V0 f# y! Z}
$ _" P7 p4 S7 x7 {" m9 Q+ \1 r. G1 o7 Q( `" h. m- F% R
假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。1 b$ h5 \2 @2 h2 @7 }) _! Q. n1 _" d
- _. A2 K6 g+ O& I8 @ 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。2 F9 |; a$ z! n' E; m v3 v0 z
( v% H8 \5 w2 z9 w$ c
例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。' Q- N7 i& e B" D- @9 B& j
" W' ]% s' x# S6 ^& O- A0 [ 很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。/ G* k% N4 g; x' T% f
/ [" x3 J, m6 u8 n, I 延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。7 n2 Z/ n1 i4 X
. k3 }5 U% Q- |% h/ I
Chunks, V4 v1 J5 N; ?! L4 m! j
/ @, O/ ]: s5 y
MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。3 N& D' k- S7 k$ f
3 Z' y' B% F( T- K
# W; k+ U6 W' } Y0 ?/ w6 i: Y图1-2 chunk的三元组
1 f/ r( Z6 ?2 T$ s
, A- \- O% r- X& d8 I; }+ q! W 其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
& e M& ^7 G& [" y. N8 d2 Q+ r
如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
- |' d. \ ?+ S( s, w" E9 f! S. \, b& ~# i
Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。8 l% ?7 B5 Z+ l) B8 y
! B& o& g. R* g- z
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。" p L0 [9 y2 u c
3 B1 }9 P$ c+ M6 ~' N 当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
1 ?3 m' {4 G; `9 q5 f3 t2 \' [; R' @5 q5 X7 ^$ O( P; N/ P1 y; h# R
这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。2 ]$ A) P" Q+ B) d q4 n& |; P7 {
7 |1 Q) g; y8 X; ~
Replica set* ~ \* P( ~9 y8 s
: v7 Y. j9 u- e- K! _- j
在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
; ]2 T( X% t/ t# R$ `; U& A9 o# i
2 O3 Y- V/ U3 k2 ^) p8 ~& l 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。
9 [* T; u6 s( S1 Z' I+ |/ }. T+ c4 i7 r _" K
Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。
% E: n% _# C, V U+ n3 b6 Y" {4 a0 Z7 U, h# T
Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
, l; b/ C( f6 r7 p, ^! b: T" B! B% W- L& U5 m% d4 j: @
Config Server5 s5 B4 ]: V" h9 U: k! c
5 o* @' u `- a2 ?
Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。: p' F2 n8 m2 b" }, i) _+ h) k
3 L: X( d( L- { Z) i( o 每一个config server都包括了MongoDB中所有chunk的信息。
n7 ~. t, H) |2 m r% x
0 K3 ^) c& u5 U Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。
0 g5 }1 |8 o; ^3 x6 v4 f5 Q) C1 x% n7 S @3 h( m4 ]& v: Z2 b
如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。; j7 |# c/ w- H) V
8 O C1 k, b! e8 ]' y8 T6 Y) a
MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。
+ p$ D' [# K- X7 i0 b3 p) R
" N% k) A9 @+ \, E: o/ r7 q& ?Mongos
% a: J$ Y% A: }0 C1 r5 v1 B2 v
8 f. n" ^% M9 E; ^9 q! d 用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。9 B" v) J$ D E- {7 ^. ?1 ~
/ E+ R+ p' b+ q# ^: C9 d0 K% ^& i
当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。
2 a' K; q/ ~" K' {8 n% {# u% _0 O( p# b. E8 b# p! y
Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。3 E; c$ `& L; B( _% {
$ N$ P% |. P, a( o+ @/ m4 `/ h
Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。$ l% L" n9 a+ X" I$ y; @# O
; G2 X' L# C: p 通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。# ~. P q3 d- k# y9 J& L
# g; j% a& k7 P; }: E8 E
' V. A0 K& ?4 m: w( i
Reference,
7 |0 Y. F0 ^6 S4 m# I0 K
1 i& s# m/ ]" c$ D[0] Architectural Overview
) ?9 K% k) l0 T! ?http://www.mongodb.org/display/DOCS/Sharding+Introduction0 k! C2 y2 E8 ]3 R2 `' i" {! G% C
|
评分
-
查看全部评分
|