|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。1 I3 I0 ?" n e& g. I8 |3 r
) P0 B. z2 z2 ^7 O, R2 f 阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?
1 O$ G* E' T1 A+ p9 n: i- G% p6 [8 S t" l# g2 A) _
不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。" Z6 r# ?' p6 U. m9 n
8 U* ?3 s8 m' Z6 v
& @0 x5 L- O* v( c: B* E' b6 Q0 _. A' {* ?4 j0 x
图1-1 MongoDB架构图 # [0 Y1 s# G/ v& s
5 b6 E4 Q9 W/ ?* C( g1 B6 B5 C
MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。8 L+ T% q! i0 ?, a
4 ?- d0 y3 m. q% ?2 j
Shards
: ]% @5 Q: ]7 L2 @: a# Y: s9 f/ l8 G$ v# W: @: ^$ y0 _4 v
MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。. C5 }# e6 P3 I/ q! c( t) H: A9 u
2 D4 U7 _, q# i6 i/ d- Y r R
Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。1 ~; U5 `- Y- I- t9 m: I5 O
1 I4 y2 Z4 e# q- X- |4 K
每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。
v2 {" a# t# d. Q7 [- g
/ x+ K4 r) w8 L+ K3 G 如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。* u* ]5 }' X9 _; x
, ~5 w2 Q# p& @- M. }/ V( b( ?' @
Shard keys8 _6 Y2 }2 p) x& J+ L
# F3 {, D- |; q' O0 U 为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。
" S/ E( I( _3 D! W0 c S/ |! K$ j0 T# }* W
如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,% }! B0 a: d' q& ]4 ~
3 U8 h- b/ [" g3 [
{6 T3 ?, B) B7 J7 u9 Y& }2 ~3 K
"ISBN": "987-30-3652-5130-82",
; X9 q' a% e+ L6 [( Q- d "Type": "CD",) }- s. w) U/ X$ S9 d+ E
"Author": "Nirvana",
8 H% x# e G* b* w/ l0 W+ J+ s "Title": "Nevermind",
6 M+ U6 T) V6 v7 i& Q* B; Z' Y/ K "Genre": "Grunge",
5 o8 p. h( v. P* a "Releasedate": "1991.09.24",* Z W) i# A2 B" t$ n& A
"Tracklist": [( @! f1 L5 L+ s$ ?
{0 q" `5 ?; U3 Z
"Track" : "1",
. j, @7 ]; F6 v" g5 v "Title" : "Smells like teen spirit",6 W* M7 I9 C) B0 M3 l5 x/ a
"Length" : "5:02"; [2 {; r$ _4 p9 p5 t5 z* H
},
# q' E! x# u+ Y) D9 \3 a4 [ {
. }+ p- \8 |7 R7 F0 ^ "Track" : "2",
0 A D$ `( s }0 Q4 ?' @( w "Title" : "In Bloom"," S' c/ a1 R4 M: M, v
"Length" : "4:15"
- `2 Z) _# Q2 O8 ] }
/ A! Z- p. R! i ]
/ A Q7 |6 P2 T0 Q8 a) o}
) P( o" F6 j! \! ~
6 T/ K. K1 W' L& h{* ^7 v2 P- j5 w h& p% V( `8 O
"ISBN": "987-1-4302-3051-9",6 R" R; m/ ~9 A' Q+ D5 `
"Type": "Book",$ k) s4 `, m$ B8 o
"Title": "Definite Guide to MongoDB: The NoSQL Database",
1 L: i; g: T7 x0 W( n0 o% F "Publisher": "Apress",6 c8 x" C) G2 d. d3 x
"Author": " Eelco Plugge",# j8 f) ~5 K5 Q
"Releasedate": "2011.06.09"( u/ A2 q4 u: {. q, G
}
* _0 W4 M5 ]8 A/ Q/ R% `& V5 I( w5 p5 ~; k4 E2 O' R
假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。: ^, K) X" U6 ]" ]% {! z
; p$ ~8 Q+ y1 Q! y3 M 在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
) u9 z) A, i( c- T. N% {; A, M. o* v, T4 |# n
例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。. k9 Q7 m7 D& l1 ~: D$ H' I
7 ` R, L; J- n+ w. j& V
很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。
* { n# N% S6 m- j% L
6 d# A# y0 J* P 延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。
( U+ u% d" Q$ W( N" ^2 T: ^: z
B7 l" ?4 `6 R+ ]' Z/ CChunks
$ Z0 j0 u- A1 W/ _7 K4 F
( |: p6 S+ i) z MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。
6 ^5 }: v% ?- ~/ w7 o7 C2 h$ S0 E
0 j* g; \( p3 |& U4 N" H
0 M$ _5 w! g5 _4 n/ D# f9 C2 ^0 y图1-2 chunk的三元组 ) O7 I3 @7 _: L5 {0 t
: G; ? W+ t) g3 A4 ~& R! ]
其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
; F2 F5 a4 O3 ]; |
- ~" w, y7 `/ ]% H9 n9 B9 f. c) m 如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
' r& K2 |( q1 I7 k( E8 e c+ {$ a3 u' u2 i
Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。2 k2 H" F0 C5 j' V1 K+ d# g
& K* H3 j/ \: ] 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。
J/ a4 ~! m: Z4 p, |- b4 |: ]' F3 V) M4 S; P# y
当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
# h3 s4 u! r+ S. U9 ?0 V) Y& i) `4 _( E6 v% k( t0 \
这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。 O) k8 V4 f) A9 O
( \1 O1 L- f% @& a% v/ `2 D: s$ RReplica set
3 x0 ^; ^# B6 k( v7 l0 z
! v, F: }# f3 g6 G M! g 在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。( l; U" O5 Y- t- ^! j& j
" I1 I' L# P) c$ U
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。
d2 `1 o/ e& {, m" V4 l% N* G$ x% x7 j* `- N! b
Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。; \( _3 x, L/ y, |" G B+ a5 B
: U1 Q; k1 f* U4 Y
Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。' Y( h W+ T- K- D- H) n
2 `9 r* E# z3 p: VConfig Server! }# y5 _+ F. _1 a! Y! @4 N
3 h1 g/ d. a1 D i8 { Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。" [) T: X0 @# F, x# x1 z' X
2 c- D! G# E" Y v4 b0 O 每一个config server都包括了MongoDB中所有chunk的信息。8 I0 u3 K8 f/ Y' o9 i0 A' a
, v* d9 A3 c) Q0 |6 K) E4 {1 t
Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。
6 ?8 G! N$ |4 G h1 S! n6 R( X t# w) v: i
如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。' [9 i9 f, N- |4 E* |% z6 t
) p9 g) M! o! G# o" I% u8 V9 D2 ~ MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。
+ n# q+ l' I! A1 r, Y6 U- r1 K" _* g3 @: ]
Mongos8 ^8 p" p( t. {7 c4 T# r" ^, ^) {; b
r. _* I& z- ~ 用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。9 [; |4 z5 }4 q8 M, I9 x8 g9 v
% d |- p) K ^ g' x# o
当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。
* k$ D$ i }; q `
+ e( t( o3 `, Z% _ Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。
8 c* [8 _2 s" m0 g& B# e9 J% k& W" D4 D) Z% O9 b2 V
Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。
% p5 s# }; K& V( U2 Z# @$ _# L& M% l# C4 C9 I$ `: y
通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。
0 D; G6 B- C8 S: ~
. {1 Q8 v3 b' l$ N9 B% S! b& L1 x% m# Y" `$ `0 ~* I2 I8 q
Reference,2 B/ k7 O3 D6 W* m% [
% k( T# T% X. z9 f# `- [
[0] Architectural Overview
: d, t$ c0 f; y9 C% H0 A# Khttp://www.mongodb.org/display/DOCS/Sharding+Introduction
) R; O$ d. [0 r1 ^% J" C; A |
评分
-
查看全部评分
|