|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
# w$ K2 W+ { ^
% r& x: i. s p2 _/ g 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
: T2 @, ]/ e v- T+ s
7 g1 C; d0 ]8 ?7 U2 {. @ 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
# u# A3 g8 I$ W9 E2 ?+ f
& i- X2 h2 n' w6 h R0 h
* n6 p9 t0 Z" i
' B3 C/ O" Z- ^* H( r- I6 g( ?图1-1 MongoDB架构图 ; X0 R" R+ _0 z! B# f8 M; }
9 Q) `9 O! ^! u% f
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
( t, s2 o: a, v" m+ Y/ t5 [- V# N3 L+ b% D5 \. Q7 h6 d
Shards7 i- S. `& y, H0 T2 V" R' p
- p, ^; J9 [3 `, k: R7 a, V8 N4 O" [ MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。( ~7 V8 E; B" L, u7 f; v
( Z9 k/ z" K2 ]1 L- g4 e- D( I
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
9 r2 a5 t, N. m0 `( ?" |. e d! m/ F ]% f2 w( P
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。- Z5 ?$ `8 s, h5 k6 X
) k8 j% l; |2 i8 R
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
; D! A) D% @7 J# e" h! X! h% Z0 u6 k2 D! e
Shard keys
. W2 w7 j' U {! h9 V
. n) w& _3 N; L- H& w& z& a9 f/ d 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
7 [# `" f$ G; b& e; \; s: ~8 n) k2 s- u4 g) U9 r: R
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
3 `0 \8 ~8 P" O, }3 V* \5 A/ d8 Y
7 T5 I" ?% V7 z* d{
6 c/ L2 n) }9 [" i2 E- D8 n) { "ISBN": "987-30-3652-5130-82",
9 t) @/ {0 E+ B0 Y, y* S5 N "Type": "CD",4 n/ g; z! Z) V
"Author": "Nirvana",1 H; a/ U: ^+ G: l6 X9 C+ U) B
"Title": "Nevermind",2 q+ e1 X" f$ A# S% X
"Genre": "Grunge",% T# J( M) H3 D) W% c `) g
"Releasedate": "1991.09.24",
; W$ Y6 o1 J6 h% ? "Tracklist": [( X! T) M+ o1 A7 B/ |7 @
{
1 P, D" i* ?9 A3 F! y2 H6 }8 P9 c "Track" : "1",* {) S% r* c; L& U! j, m3 Q
"Title" : "Smells like teen spirit",$ U) }: d* T5 L
"Length" : "5:02"9 N- y* o9 ~; b. ~
},
N; }& V @6 ? {
- k1 i: w5 M; N "Track" : "2"," A; I. s3 P$ v, t$ w0 N
"Title" : "In Bloom",
$ I& t/ Q' I& E7 { "Length" : "4:15"* D1 m0 e' o: d6 ?. Q/ [8 l
}9 Y. A0 S( m# j% ] e
]$ E: z; ^6 m9 A3 a7 i3 I
}# K6 y' R; |. f; N
9 ~- z! ]% {, K. p{
9 c, g+ e7 z; W8 @- E0 q9 A" Z "ISBN": "987-1-4302-3051-9",8 z$ \' T U1 x6 j# L4 q( A: ]
"Type": "Book",2 ^! ]$ d% J6 h. s. i4 c- |/ Z
"Title": "Definite Guide to MongoDB: The NoSQL Database",
1 D7 N+ j' T, g0 \ "Publisher": "Apress",+ Z1 j$ [7 M# e1 b, r# L( W
"Author": " Eelco Plugge",
* p, o1 X* X9 r1 i- ^- a "Releasedate": "2011.06.09"3 M; U3 ~7 Q7 A5 O8 \
}
" W0 t: Z @+ J6 L
9 d( I9 n3 e( ?3 [' b; N 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。3 T/ L, {# Z; U$ A: j
2 S/ S) D3 U% r! D3 Q( R" B+ \5 B
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。: @; ?" |3 I7 C: Q4 d
) M9 M% u3 d( L/ Q4 M, n 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。: g; g* B) j' m) n x6 ^+ B4 m6 Y
/ k& V0 H0 s [0 d2 M7 D
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。6 ~( Q& c- m; o& c
/ l6 U# q! Y/ G
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
- K1 A) G5 x4 Q' V$ ^9 K& _4 `2 S7 j' D
Chunks, V! V8 C6 L6 {/ x$ Z' O
9 a" g2 l" J" @ y* ?
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
I( b- w* E1 B8 p4 M
" A$ ]8 L" P/ |( ~
9 O& k0 v2 {! K2 o, J9 T图1-2 chunk的三元组 2 p* ~. ^) M% C* v* P" Z- H
! i! g" R" G/ |' y- R; o1 [
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。" W$ I% J9 I. ?7 A& d; h
+ u8 e7 C( E/ D) x9 W, v3 Z1 W/ Y
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
& E( M, Q% z' Z9 ~3 }5 [3 e, q9 T( L+ w0 Z
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。2 a0 D* |4 I9 ~. J! b% y
) l4 R# ]7 n4 k, [- {1 l+ k9 b
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
6 s6 F0 N0 R9 Z. E8 R( u5 ]1 d9 {& G# E; t2 ]; B
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。 V* M' c7 n6 t( r
1 P8 \7 b) C% s" B5 J 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
! p9 k- u2 G# ?% v; J5 U' x+ y
9 J4 o) w- @, t$ W/ A! aReplica set
1 {; o: ]. S1 V5 W, z* a
- K7 R. z3 k* ?0 t9 B 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
5 n. }' C4 t1 ^8 P: j
& v) l# Q$ `) O; ? 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。2 Y" D" Y6 Q: H7 {3 U5 J7 f! }
" o3 E, T& `3 `/ `: }- O Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。$ }( S5 a) {& ^, w
+ l, d7 ~3 v7 H6 p) d1 {/ A/ K, q) p( E Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
, @& d0 p6 C! }
. R. ^ d, T1 YConfig Server4 P4 B0 p! W/ f y3 r/ m
! N% }/ l0 d: ^ Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
/ p% L. P0 e n) Z% {( n( L1 U
每一个config server都包括了MongoDB中所有chunk的信息。7 r3 f! b6 Y; ]5 Q e) s
4 m/ D, l# K) y' ~ Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。( I1 r6 L& k9 m
1 B! K {( b4 k" w9 a 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
; ~' c) H( p3 b9 R! ^/ T9 y% d/ m& t3 l6 S# R, t
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
" x0 {& i% l5 d7 E- c. Y g9 _$ O5 c, q; w3 X
Mongos
% |! Q7 v9 J6 J, g6 a0 G
2 \8 Q" ?8 H; B 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
4 X4 r- x' X8 `* a( U P% u0 v& L4 t! }# M3 v
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。% |1 R! }' T V; v2 w( |
: [- }$ _5 b2 X0 t0 ~$ R- E
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
3 M! I) B! a: j. C6 w
, I A0 J1 C; H' Q0 `6 M2 i9 G Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
5 E) r7 f! w+ U, Y# \$ y! X! I S
& N& _9 W4 M1 b( i 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。6 V2 ~6 {9 T/ R
# b" C$ V; X! b0 D1 Z1 E; G) `4 _9 l' A/ \2 o4 N% X
Reference，8 |' H( V% k+ M9 Q x$ ?
; B3 u8 N" d" M[0] Architectural Overview
3 U q: u8 N$ ?7 x. Whttp://www.mongodb.org/display/DOCS/Sharding+Introduction
2 R9 O# k2 e$ T* S, ]9 E9 g |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
" L2 w! V/ Z% O+ x