|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。- b Q1 Y! w1 }) U2 o. u2 R
$ x/ ~ I; Y8 G/ H5 l( i
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？. f7 l7 ^4 }9 i" q
/ s: o) g- W% h7 [/ m$ ~; u
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
( e0 _/ R6 X. m7 n8 m2 X5 B0 G# j' Y$ b# V. f
4 \9 N! O7 A, F* I" n% m2 t, S; t+ N) K
1 e' ~, t8 O1 J6 _图1-1 MongoDB架构图
1 {" p7 I- }$ `/ F8 I/ M4 ?9 ^' w
* A$ p/ @$ _' s5 W MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。: ^6 ~% q1 s; ]; b9 f( a+ W
7 Z( X+ {8 G5 w: }3 b; \: {Shards
9 @' V) e6 C, o/ i) D4 [
; h8 V1 H0 r+ U2 f MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
* k( Z' X r) s1 t
. R# {) E& S2 y! K9 \/ b Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。6 r Q. S' J# ^
, g5 j) C; ~) Y/ v 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。% r8 [2 ]. ~: U2 K7 t
' C g* M* N% q+ `5 y8 R 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。( f) x; {6 K$ Y1 o) }
! N+ Y% `# L4 T3 T
Shard keys
( A* U% @. z& t4 u7 j$ X: R, W ) i, G( o# _1 r9 u# q4 {8 a. L
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。9 v1 T+ A" F/ x" o8 Q% D8 G c* o
0 X. T+ \: ^5 W! N. p 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，* S" O. h0 X. `8 c
- ?. g# m* N6 T& _* u{4 w( c- j% [- l+ X9 U
"ISBN": "987-30-3652-5130-82",8 L- o3 }$ ^, D7 p! f
"Type": "CD",6 A2 N# @& G$ o, `+ P2 x/ m
"Author": "Nirvana",7 J/ M8 p7 U Y- |) B" Q* j
"Title": "Nevermind",+ J6 Q6 X! x5 d: a$ z1 w
"Genre": "Grunge",
# V; a6 y; Y+ \3 ? "Releasedate": "1991.09.24",
# X" N" J# T: R' \ "Tracklist": [
0 R x% t+ n, P$ l+ `0 Q0 c {
4 u0 X0 X9 q# N* x "Track" : "1",
& N' m* r/ Q5 ]0 t U "Title" : "Smells like teen spirit",# V* H H. D! T/ P, a7 W \! r) X
"Length" : "5:02"
- k+ b1 C* d1 p },8 ?. l* g# |$ N/ N8 p8 b
{% V6 {$ E$ {: S/ N. t( T
"Track" : "2",9 n9 Q: O' ]9 U8 R
"Title" : "In Bloom",
- E! p+ x8 A# R1 f' n7 I6 W! X" z7 { "Length" : "4:15"4 X" O D" O& o$ J/ N9 O
}
( N8 _* |* ?* v ]# x+ q# l9 J% q' p2 S" |- g) C; }0 g
}5 m' o0 I) M) d5 g4 d
0 C$ A$ ] c7 h! @3 e
{. n9 c$ v4 Z- f( [+ c
"ISBN": "987-1-4302-3051-9",
: u% ~) I# ?5 Z7 }4 @ "Type": "Book",
7 u0 E( m' U2 Y H1 h! K "Title": "Definite Guide to MongoDB: The NoSQL Database",
7 }5 O* ^: Q) Y1 M. S/ m' u6 h/ A "Publisher": "Apress",# L2 c7 W! M2 M
"Author": " Eelco Plugge",
: A4 X, p# _' O. ~7 [ "Releasedate": "2011.06.09": Z/ g) c6 ~( V$ Z, h3 z+ V9 }
}$ G) [( S# W( v. `$ M w' N: N
) Y* `: Y* d" {) v/ F: B' Y 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
: E! l. _+ q/ {( O' r: {0 F& L! ?! l7 r6 a
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。+ j( m0 ~- J5 g7 P1 F
9 Y5 s! J# w8 h2 T/ j7 Y. Q' | 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。) s6 M$ V) R- a
A& }, {" s( q9 b' Z2 @$ f
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
9 T: f6 x1 W* h7 c3 M0 E. k4 `" _- N% X7 Z z# I/ ?" L+ W/ t5 O' k y
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
/ k2 k9 \. ?9 Y9 z- H
, \% x" F7 N+ j, b) `4 IChunks9 j8 j z2 o4 Y4 E
a0 X( T+ [9 M7 `8 f MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
_7 b; Z+ k% {5 G3 v
0 e1 J, }4 j9 u' b. I+ s
8 d! c, F2 B" t$ O! z$ V图1-2 chunk的三元组 ) l! g. d2 V* Z8 f" f
0 o! Y9 f; S7 D* X E3 I4 Z8 B 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。9 t( a0 a7 `3 a7 S/ n
8 A. X- |3 k2 ?$ [6 E2 k 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。) P; v0 H2 E' x+ \3 T
: {; G9 u( ?4 V+ L( D Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。2 P# w/ F. X2 g/ v! j) V# i
4 t" I! U) O' i# U
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
* x% f0 l1 {) B1 t0 _8 {1 ?9 f2 _4 H% ]9 R" o) I. }" @: g
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
& T" q6 o# Z) j, x* b4 Q. @5 H: t) {6 v3 J: _
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
6 [ _, ^4 [1 v/ [ ]- ~+ ] _) J+ p+ G7 r
Replica set
6 S0 v% }! f# h- s- ?( w5 B
. F1 t. Z6 ?7 @# T8 h 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
7 H. ?) ~/ M5 }1 B% N& ?; Y
2 u$ G, e. P4 I! k 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。; Q; E( g2 [ H
: T) S+ r: C$ u/ y9 n Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。2 o3 ?% V5 A8 e2 q- U) _/ G. E
7 O: H4 s/ D2 r9 s) W
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。! f" v* i0 X; [5 K/ K! ^4 `7 R
: {" T/ |; W# A; I& I7 o
Config Server, e6 W0 u% F7 i0 T2 a R5 P5 @
; S/ e7 j$ q7 _; v) ~
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。3 ?* [+ ]6 o0 ^/ O! N7 G. C3 O. a
3 ]& ?5 g" k( K
每一个config server都包括了MongoDB中所有chunk的信息。
) I- `) Q# }) A d0 ~. b
$ V! ~6 ^( H _" Z7 h% z Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
" _! M0 u5 Y9 ]# ^. K: L* c! {% m
9 n! R8 u1 B$ s1 m* k0 X) M$ Y 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。, D$ T/ Y6 m K6 u
, A) b% n& @. `% m5 }( Q MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
) ]9 O! T5 g4 N& n
# E' S1 n$ g- J4 u. M$ FMongos9 @# Y7 _6 u/ \1 o
N' W6 z/ M# H2 G
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。; F$ }2 T/ W' v; k
# @/ N+ Q+ M% U3 h% b6 Y 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。6 p7 T5 L9 l; \, m7 z
- d! K/ B3 [) N: @+ T
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
- l. a2 p, {) g M4 f
/ Q; n. q* e7 v Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。) [ {) [& ]) _
( T) n$ i: f K2 m& |" b 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。" c% v% Z, D8 p) r
# c. \' @$ x( R! x5 g' w
6 o, \8 I0 }( ?! q: s% J: aReference，: s/ e+ L, m. l) s1 e. u: Q
; ?$ u+ A$ L, D u7 i2 D/ k[0] Architectural Overview
/ n: y8 \' d' J" s" Qhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
4 P, J* @7 m: ^, S |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
