|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
T, Y4 z! x( Z' o8 y
& n. I( I) W4 P; o/ i9 E 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
& m7 q( {; G* K+ U' o6 i3 n! F
2 A+ X( X+ J5 S7 l 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。; w- M5 u; U; x, x. x' m# g% k
' v$ k; k% @- T" ?) W
5 F+ ]8 i% \! Q/ e" Y+ C( X& U: [6 @# H1 u$ Z# M
图1-1 MongoDB架构图 # n- S8 n& v5 S* x
6 S* b- P) ~) b
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
G: S; E/ h8 B+ V( O& j! }' ]: E! Z0 w: c9 {
Shards; l, K3 J- D; G# U) j4 U9 m
) ^) Y1 F+ a8 i! P' g8 \ MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。/ w) n/ R T& F9 s' X
6 P! \8 v2 Y6 p- Z
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
" l$ J6 n5 d% C- M( z0 `; J# i6 _' u2 ^5 g3 ^3 U
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
1 e* R- t" a1 ~5 Q8 E/ W9 H6 S1 _ f/ p# I& `7 j }: M
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
. z5 K2 i3 b N! b" P ~" R' ^( ~6 g' B' \" S, ~' f( o
Shard keys; u$ q0 e; A% {4 @$ x* g
! p n- T/ V4 S) c/ L0 }
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。8 X( ^) i( x) {" V; u& p c% c
. \, _0 m. \- j- g) J0 b 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
5 U+ s& y* Y& Z2 @
: ?# J4 V1 f( N. H {# O6 ~4 ^3 M+ t{
3 F- g- `; Z: V1 l* F6 T "ISBN": "987-30-3652-5130-82",
+ O7 m: F l( j1 W& m: f "Type": "CD",
2 H2 `. |; c" r. X6 |+ e7 e* o! P "Author": "Nirvana",9 G( [, g* w4 X$ Q9 J- ^
"Title": "Nevermind",8 q1 r N$ Y! _5 n, Q! }
"Genre": "Grunge", R2 y5 F& c P# o% }, t7 R- R4 M
"Releasedate": "1991.09.24",
- ?8 A! o3 g3 I* a* t. V "Tracklist": [0 O8 d. B& s: F& W: u; b! ^$ K9 O
{
& _8 k( ]9 H3 J3 |6 S* d "Track" : "1",
% m- H0 L8 f. s6 r1 f& N: J3 R "Title" : "Smells like teen spirit",; K9 ~8 e1 W: L1 h6 W6 u
"Length" : "5:02"
' }: l+ c7 Q- ` },3 \ J" k6 ^# t1 V
{- c( T5 \9 t8 H2 ~! Y- j: r
"Track" : "2",
1 L2 S/ R. F/ u/ x8 L "Title" : "In Bloom",( F) G4 H2 J) B
"Length" : "4:15"
: U; @* Y g! v- H* ~1 R, ~- Z: |+ Q }
) B$ j2 I$ F t2 {! w! A ]
5 w: X4 m+ _; `2 u) L}& m2 H% z' O+ m- z
( }+ r6 _7 J! ~5 U, _0 ?- W: v8 |& O
{1 o! z% Z; K: V% X: R4 K0 r
"ISBN": "987-1-4302-3051-9",0 b8 D H& E4 I, b/ G
"Type": "Book",
. T' T' }0 u) m( A. ] "Title": "Definite Guide to MongoDB: The NoSQL Database",
5 d( [' v% ?# ]( ^4 S2 H. g "Publisher": "Apress",* ~# {4 `5 ]- s4 ~
"Author": " Eelco Plugge",& I$ B6 h- i' F, S! o
"Releasedate": "2011.06.09"7 ` }9 @- [3 Z5 E/ m$ n
}, v( w* l' _# j! H, G3 F9 b5 e2 }
: j d; X! C/ f3 q
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。$ h, d7 G9 ~) I/ F+ ]
. R2 p/ X/ `+ S4 I8 C4 v
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
: G. A3 l0 a% b/ Y
" A- F" G7 ]: D. z 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
. c- }- D+ h& H6 L& d4 _$ k; |6 S# a1 C% l5 ]# M* s+ w
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。6 I% l" N I5 |3 [
! D( v. g( a. M) }' ^( s. R4 C# @ 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。- m. Z5 @1 g9 y& B) [4 }# `
! t5 z* U3 i9 _2 w9 {# g( w. @Chunks
' q5 d( h! d x3 T9 u8 _% J
( S) q0 D; A1 y8 x5 j MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
& S# A' f9 f8 A$ u$ v; g& O2 L1 Z1 v
! ?/ h7 P$ g1 A2 |
9 k5 V2 A; t+ d. W
图1-2 chunk的三元组 0 V/ ]0 `: {8 U7 m, C
9 J. u/ p% Y. v, y" w" J; \
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。5 L# z2 R7 |7 z: R% m( {4 W) x1 V
. ]2 U ?+ F) z2 u1 i* r* V
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
* q: Y2 ?8 P$ T
" [2 e* N. o3 Y Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
, g# l1 n, s3 i/ i/ j0 H
1 z" C/ C% N5 o0 c: L/ X7 ~! P 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
7 u, a; [8 ^' N0 R4 o( O8 q) S) M. k7 C: ~( ^
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。9 l* _5 H* V, W: J
* H! v# g) u# C 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
# C) u5 T# c# Y L$ t. w: J
2 Y, L% A9 Q* C( u& f- UReplica set, a* f! ?0 u. q2 h& ^$ ~2 o
. R" ^+ N% w: ? 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。7 C& n% k6 l2 t6 x' p
$ s& e2 K* }9 F/ D7 J
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
# |; ]( G8 L0 T x, y0 Q6 k3 @* w/ S, o
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
8 N6 ?' M# @9 K, }8 j/ S- v$ T( ?9 L# N. e% X C
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。( f U# Z2 R" y4 h1 I2 R
2 V: @( p. e) a6 K4 wConfig Server4 J5 N, C7 L4 j2 i: k9 F5 s
+ _6 o5 B4 c3 f) U
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
6 t8 S5 a/ F9 q0 y7 `) U7 s8 a; u: m$ s/ y
每一个config server都包括了MongoDB中所有chunk的信息。
2 a3 D$ ], ~# p" r8 }. W4 z7 n8 m9 ]/ S2 O8 k; B
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
1 \7 g8 ]- `) A" a
p* A$ d4 L9 l. P6 v0 C q" j* E4 C 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。3 r5 q, `& y b( Z
! J) W: G9 Z( @1 F* R& J$ L) l
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
( Z5 B8 M" ]7 C. `! L4 ]+ t+ k0 ^ k! Q, O- x4 U
Mongos2 ]2 P* ?+ \2 f/ z
5 ?/ i: l. H0 l2 J 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。0 W! [* p5 x+ c0 t" @; d( i& o
% ^6 K) K4 Y& s- Y! k4 l
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
# ~5 ~4 B# A% Y: u0 D+ v% D* F* ~2 I
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
3 M( X4 c& g- d/ B4 |& W; O4 A& `4 J9 O @9 w: K; C0 H
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
! h" _& C U8 c$ P/ G b0 ~1 [. |3 }/ _. M& @8 T2 B" b8 q
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。" w* l9 U8 C [9 J2 u
$ q: m4 T3 W( T7 Q+ U
- W u: j$ Y9 v- |' t
Reference，( L K) _' |& {! D
4 u2 u( X# M% ~5 U9 @5 p% X
[0] Architectural Overview' P" }+ d# J9 N' F2 i, O
http://www.mongodb.org/display/DOCS/Sharding+Introduction* G! |+ \( D% Q( u
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
& M1 u+ a, K5 B" E; B) _