|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。
; q8 }% r. f$ b% L" q
: k& P' p/ |: `" ?9 D- f, i1 j 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?: {8 Y5 F" D! X! s' D5 f4 ]( w+ s
5 H( V1 p/ N. Z! J1 _ 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。
7 z. ~7 }" A7 o& F9 B* l& R. G" u( y/ B
, U+ |: h7 R$ n6 H( e+ c" i" k- z4 h7 B4 T* T
图1-1 MongoDB架构图 3 K8 y. G8 r* W% B. i7 t9 w
9 c2 F3 V" V7 A9 E0 {: S. c MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。6 k. y: t$ g/ M
8 J% k4 `* l! j% v7 ]3 l' gShards3 y4 x- T. x; E; n: B& r
" l0 X% j( Y3 x8 }. z9 @$ I
MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。+ e% Q5 J' s6 o
1 h4 n* S" l4 T' a1 S0 Z% a
Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。
+ p! F- g8 Q3 S/ A* Y
+ j Y4 i7 m$ } 每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。
$ y( B6 u& {( o* ?, j2 H) \) |1 X4 i/ E# u. B \" c
如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。" \' F/ \ W" t3 V
3 k$ {# V7 M* H* N8 p; H/ J
Shard keys
4 u( I6 P. f; K1 l! ` , u. h: \2 \, P* B
为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。4 Y1 N$ [1 n/ b
- j9 K7 k0 A/ M. U8 v 如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
, {- n8 Y' Y; j" n6 O$ Z- B( Q* E: Y: X9 X5 k
{" U7 k/ p( C1 ~6 Q
"ISBN": "987-30-3652-5130-82",. D" _+ Y9 s, \
"Type": "CD",. k7 c8 l5 F4 D' ^* [, f
"Author": "Nirvana",6 h' l- O' r: _) h
"Title": "Nevermind",
$ X% j1 u" Q* Z9 H "Genre": "Grunge",
i. Y1 Z2 |- K# i9 g "Releasedate": "1991.09.24",1 b6 t' R9 w: y3 ]# w
"Tracklist": [
* K! N( k$ H+ K, S0 h {+ Q3 @$ S) \9 i n9 u) f5 @
"Track" : "1"," ]6 I @6 k4 K# U7 G/ f; e
"Title" : "Smells like teen spirit",
$ z( t4 F. {9 F "Length" : "5:02"* u: |. M; J3 w0 n) D; H: W
},
8 t! G0 X; b L0 t8 v, N" e- H( o {0 Z7 Q' H4 u8 L+ Z2 U
"Track" : "2",
5 a5 k) O `( |* s" ~ "Title" : "In Bloom",
3 B6 d6 A9 D0 L/ N "Length" : "4:15"* U/ e# u& N3 t c
}
2 _ v' o0 ]! d4 S ], W) z5 e: j0 Y
}
; w" l9 w' y. w' ^2 O6 s, W6 P3 `1 y9 q7 w2 u" {; _: k
{
8 w) a2 H H8 e4 y "ISBN": "987-1-4302-3051-9",/ H u* m0 {- }! ~6 J* ^4 Q
"Type": "Book",& t5 l" Y% v+ \! \9 _! p* @* }8 t
"Title": "Definite Guide to MongoDB: The NoSQL Database",
& H( e; G- @' I& [7 z: y/ F& _& C0 ] "Publisher": "Apress",
" r! _! ], x- G" O {1 o "Author": " Eelco Plugge",0 n0 O5 V x' V/ v! Q+ \6 [: s( Z
"Releasedate": "2011.06.09"7 m6 v7 A3 V$ ^1 F* g" c; @: M# Y
}
, ^6 e8 |: p/ \& B$ g0 {0 H" B8 {5 z
假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。
1 `: L! }0 [$ m+ k. L
% Q7 \) [/ o2 f 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
5 B$ v. K5 K3 b8 _( F# g5 j. K- P6 q# F
例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。) f4 O J1 I, t6 T" o: ^
7 r! _! p& t1 O8 x 很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。; T- i4 L4 z/ |
/ v0 P$ u- S' m' g& z$ m, B( ^ 延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。
: l% E: v/ v* Y8 `3 S6 z! y; Q% r# A) D/ g0 ~) }# ~
Chunks- l x$ i' Q; C9 ~" \2 h* h
+ J: n, f8 c, a- i; e
MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。
: Y3 g( ^5 k' q( t1 ~* T( ~0 i( _
" c5 p# J8 E) w8 J; V
( C* t. d: [7 c* B$ W9 a3 Z图1-2 chunk的三元组
; U; s0 f8 a% e4 y
' Z1 G0 C! L) ?4 R' W 其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
" _( n" g y6 |; V! A5 H. T$ ?. x4 z
如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。3 o- n' }& ~4 L1 ^; `
5 x( R3 x( y8 W& ~* |; ]
Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。0 d9 Z P, ]: i
( a( Y$ O8 F& u! b$ [, D 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。( c, z9 Q9 ?, u: C+ H9 r& W, A
# W$ a7 T) s# j' r 当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
! q- q7 W. Q6 \6 U* [
8 c! E9 H' {) H0 m 这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。
. r _5 ?: n" h g
. y" S4 x3 m$ S/ i0 w5 J! v; hReplica set, I" X5 h3 p, g# G# Y0 h1 x9 v/ }
- |5 \* s5 `# H% X. L 在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
* L3 F4 ?+ q5 q" ?
% C9 e. ` ]2 i3 Y 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。1 I0 d+ p- b5 R- u
" e) r' G! E& i+ v) I Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。
% @7 _4 O9 q, x% I
2 {) `6 d# Z3 q- q' E$ i9 ~ Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
T% R/ ^8 F5 n( J) N& R& q1 v# O" d9 L. x/ [+ T: ~) r$ I* E% h
Config Server
6 z d' \2 l. A& w, r 4 i2 N% i* y6 Q' R( M" \
Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。; @& w8 Y$ g: }7 F
1 B V, t1 p: u) x% f5 \9 E
每一个config server都包括了MongoDB中所有chunk的信息。' e. p; h" u' q; Z
3 m. ?; s5 k& r- ^$ T: |, S
Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。
: U5 p2 H& g, c4 L0 g8 X/ V
( C' U' W+ @% q/ G$ ] 如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。
+ I! ?1 E. g+ P* K3 v: F% @: N
% P2 X$ S$ A) ^- N7 m MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。
8 ]( G: H# S2 p5 j* o# ~; Z# |- D0 ]+ U0 n0 N( Y, b9 \7 O M+ @, P
Mongos7 Y0 E: |# W' O6 U7 r0 r: _
6 F3 U! h ^' C- J" E
用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。' b% J! @. u/ [; v" ]
6 c |8 y0 M- F) [ 当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。+ u4 u/ V/ w* l6 y `
9 M2 h! a1 Q; M4 L: g4 W Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。
2 r6 J) i; r/ T) Q9 M
1 Q( G: K3 e" y Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。
5 C: z1 m' \% }+ G1 g7 |9 {- ]' S7 M$ ?' e
通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。. ?% H! Y- X/ t! }* U
! {$ T1 w: }+ L2 c
7 i! L: `+ K* f! \5 x7 s+ ]Reference,
+ J9 L' z' g7 ~7 K2 L9 I2 `" G# Q9 ?
[0] Architectural Overview" Q" f% X- f9 B7 I( i" [ o/ h
http://www.mongodb.org/display/DOCS/Sharding+Introduction; T# @& H) b! L% c+ X. |' B
|
评分
-
查看全部评分
|