|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。5 M3 A2 Z% _9 x* p
% }8 N4 P0 \! v' h; A/ w5 H, Y 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？% Z6 S. D' x" I% O8 e. I
2 b% ^8 Z9 }+ Q u 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。, W& v; J8 t9 u# ?: p6 s$ U
# W/ U& u* ]( |- k) L
4 G0 U5 ], ~3 }8 B
# C: D2 Z1 y' z+ n- h' G( A
图1-1 MongoDB架构图
. N" h# J' m! _) U9 z& N9 \- [/ @
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
! I% o! C7 j: B1 n. E+ Y) E+ {3 S9 y& g6 S- D
Shards6 {! d9 ~/ r& U& \- w1 s7 q
5 X- `# k) b- B+ E& L# O8 x MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
. C: r2 ]1 a! }- e- o6 P w% h9 G" b4 y3 N* ?, Z) k
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
7 B( z1 x0 w9 S0 J2 `& S, b
8 {# C: J0 G5 s) |6 B9 w 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。* ]0 }' i. }8 G) k1 U
( z7 p9 G. f I0 X% g 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。- j* |* R+ D; n0 D) a
g5 E+ c/ @1 Q1 ?7 KShard keys: c/ h) b3 Q! M3 {0 {- Z
; }5 R2 H U" j! c* y
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
# o$ z1 |$ v6 |1 k6 v
* ?+ F( h) J: J* g3 F1 w+ |3 \) L; L4 \; | 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，8 d/ s2 Y' a! l* Y- B, a1 v+ I
5 j6 n' V y" N' S{
; Z" h+ K/ [# E7 t f% u( R "ISBN": "987-30-3652-5130-82",3 F4 @- ~$ t$ f8 N4 [
"Type": "CD",
v Q1 \8 a6 l9 w' ^2 U "Author": "Nirvana",# _/ \1 D: [" i) c% G4 D6 m
"Title": "Nevermind",1 R0 {. }3 q) @5 z7 c% O7 D, H0 r
"Genre": "Grunge",
_$ z0 R5 `' L "Releasedate": "1991.09.24",! O" P% V: }. U. ] P$ }5 H0 ?2 L, Y
"Tracklist": [
4 S9 F1 R7 L8 M8 V {& ~. _! w& H6 ]% H- S) M) n0 g( v
"Track" : "1",
' C$ l: W" I1 z+ R7 V# G "Title" : "Smells like teen spirit",
0 T/ P$ Y+ o5 r& `' I "Length" : "5:02"
( v8 ]% m0 b3 P/ Z },
7 o$ x) q: Z/ \- j {) V. V l2 e2 b/ O( [- k
"Track" : "2",
$ x( E( e7 o7 [* ]4 _8 H4 h& j "Title" : "In Bloom",4 S- F+ ]/ G# Q5 f: j4 y5 }* r
"Length" : "4:15"' ?" B F/ U+ T% Y* {
}' r8 o) g/ X0 x. z' ~* k( b2 t
]% Q2 C" v) `; ^9 L- L
}
* S$ V8 V- h# ]) `' `% P- Q- r, Z; z R
{# L9 B9 R& b' J' q7 x
"ISBN": "987-1-4302-3051-9",! Y) w0 t/ |" x' o
"Type": "Book",, ~9 Z( v- X9 [6 S7 u ?
"Title": "Definite Guide to MongoDB: The NoSQL Database",6 U1 ?/ ~+ M' _( n9 |$ L+ p
"Publisher": "Apress",
) H2 T# F7 O1 P r% {9 F "Author": " Eelco Plugge",
3 _6 F: }3 n) W8 p7 v/ \( E "Releasedate": "2011.06.09"
2 t2 Z* S2 c4 W7 U}2 P- d% v* B7 O! L' t& l
' F6 C6 @& u: c% c J. M! N 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。0 \1 s+ ]5 d ?" x$ y* F
5 k! q$ e4 a, v- ^) G7 l 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。/ ~7 ^( K8 u8 [6 A1 n: h8 D* f
, c. J* f' K# G( G2 W
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
: B; R6 K# Y5 H n7 W
3 a5 A9 |6 b! n7 L 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
. H( [8 h# {6 ?
- q" A6 C5 e: X' Z, `: A& ]3 p- j 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。1 y7 o3 h( B! N3 R0 ~. z
( k" \3 j5 ~% n. ?! p6 [0 ]Chunks! D' A, U0 ~3 d4 j. b3 z# v
3 t5 I* n$ S+ ^ M/ z4 j" s$ K) V MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
O/ P; T+ B, O6 Z& |5 J1 K! c+ ~5 q& d$ o: t4 |9 y0 N
( h& Q( ~/ P' } Q( O u9 K- r1 Y图1-2 chunk的三元组
, b. J; b& I% l& D" N4 o5 L2 }( ` @; }2 x
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。& k4 c, q( k6 q
2 C3 N) s8 _3 |) c# |
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
- V) h% a. v/ b8 V
0 Y! D# z6 J" f Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
# E* V2 q: V% u! | n" x: m; ^- W3 h; K8 C% [. t
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
1 x) l) \( \5 ^/ A g5 j
6 [7 F1 L' y& ]4 Q 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。' q0 V C4 i' g
& Y# {2 b3 Y# j0 O' H) Y 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。) M v* _- L4 v. F K% ^
% x* X/ |, [& z+ O2 zReplica set
5 s8 }8 ]* m& C; K' e" O! t 6 ?4 D% j. |$ R* `8 c
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。$ f( y8 B8 w" z
# L c t8 f* V
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
6 l, c" x T3 Z! {! h: k( @8 L+ @' T- N* [
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。3 h, g0 B6 C6 C4 N; I
$ Z4 b' z4 o7 G4 \9 r Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。! y3 ]$ M S% f; `* Y
6 ]$ v- S" h" [4 HConfig Server
$ R0 v( i6 s6 |4 S7 `2 N - ~3 X7 Y! B h; k3 j. Y# t
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
3 f. T3 x& n; z7 l
, V& j4 t0 G5 Q" s# N 每一个config server都包括了MongoDB中所有chunk的信息。, j4 x4 U8 C* d5 h6 E
# D" a6 w$ D. A" U$ m Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
0 a4 ]- v" R. Y/ Q$ v8 r
, [# A/ b- v8 k% l 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。% O; x+ U" h0 b
4 F3 U3 m& j# B0 S9 ]0 X
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
* ?8 }& d9 ^) T' ^8 J, E2 G9 W8 D" L4 j u0 {) N6 t
Mongos4 s! F: \; U9 e$ B
1 b) s9 V' p4 Q7 w- }# i 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。: j! z0 S7 p. N l2 ?7 r
2 G4 v" C1 j( |& f9 \9 P
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。; w" Q7 E! H A
+ @4 [9 ~! D0 Q5 F" ~ Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
/ s( e1 O1 t# J- R3 V) L7 W
: z! ]" e1 E% t$ s- [' u6 t+ ^ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
- k+ z- P5 @5 X% F1 {9 m9 F
' {* ~, M& S, s C0 W1 r; { 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。 ^# U1 c- y4 \; `7 |) a& _
6 H, I7 w4 O- o# ?
5 n! ~- h' c: b8 L {' B) Q \Reference，2 r2 C3 o. V$ b$ J$ v* J
7 A+ \! K: b8 G[0] Architectural Overview
2 y0 h+ w* `. w3 ] bhttp://www.mongodb.org/display/DOCS/Sharding+Introduction- A2 t" D7 U" |+ ]* q
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
