|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
% U9 T( ]4 l0 l# y' T: b# R# X T3 O5 _0 [ H
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？0 ^3 V5 m3 B( b8 F
* J: y7 n+ o& O& ~ 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。5 x) e1 V- _5 K9 H: {7 F+ | e
: z. ^# B0 j# b. f4 {2 ~
6 r# i3 L, E1 G) D$ _2 x) U; p
3 Q$ h# H% Q& ]6 X图1-1 MongoDB架构图
1 h: R V% S. U; t2 b9 u( w5 {5 m o, v( Q$ W/ ?
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
" k. p3 C! I& |' i) G- L
5 m! e7 n: P8 [Shards6 T' z9 d" w+ U
4 j$ p9 r: |3 n& M# E* ~ MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
# K9 o: s* W4 w! f
9 j4 o8 e& b; {& @7 B9 i Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。. o5 l4 K+ {5 e: z7 p' [! s# X& u
/ X" [7 w* }7 u0 a' a Z
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
# I7 q3 X# ~" e3 b, E$ _% f4 C
/ K1 u3 y4 X. p" s$ b 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。' s4 W+ R) S( \0 l2 k* S
& n [7 M& P( G" L1 z) lShard keys/ E7 O0 E7 Y- \
' d' o# Y9 D+ v6 ?$ A
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。, u [8 D8 p; s7 x) N/ J1 y
" `1 c( `' ~2 z9 d/ [
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
' `% y( O( u p" |3 M0 `9 Y: W4 e
/ }4 q+ e4 E, l8 J1 o# P3 r& Z9 `{
* K2 r3 P) D, {4 _# u+ t9 F9 u "ISBN": "987-30-3652-5130-82",
6 o" o# Q J5 ]# { "Type": "CD",& ]- D0 R6 R' Y3 y d( A' r
"Author": "Nirvana",% x# g$ O, n0 [/ |" ]- z; t" y! v
"Title": "Nevermind",
/ h3 L [' O: V" G+ p* ~. y8 [! Z "Genre": "Grunge",! K& [2 U G8 K3 D+ Q. Z7 j
"Releasedate": "1991.09.24",; x O3 {9 X* P" Y6 i- x. f2 Y h
"Tracklist": [
R2 |! x( @! f$ N- p8 w' P5 O6 } {
# u6 k- u& o1 M/ t$ K) `3 ] "Track" : "1",
% F$ [1 _4 t- g" V9 x "Title" : "Smells like teen spirit",0 [6 G1 I: t+ ?( J# \1 F
"Length" : "5:02"2 {9 o6 R8 l7 Z: O+ D) ]
},
: R; p& c4 m v% ^/ m {; W( c' C3 Q* ~* U
"Track" : "2",& X$ Y) Q/ ?+ c4 T. z
"Title" : "In Bloom",9 \4 o% D; N3 p! Q H5 {
"Length" : "4:15"/ C4 M& [$ B+ D$ N
}, ^, X G7 ]5 v/ G* ^4 t
]
S% ?: ~0 S! F. D C* F0 f}8 D' s: F( D5 O2 X
/ g. f# R! _4 `9 h4 p0 k+ u
{
" E b" c, X: C B- V1 U' k "ISBN": "987-1-4302-3051-9",
- l# b( M" u$ D4 o1 R7 f0 A& B% X "Type": "Book",+ v2 |" O( [, E/ ^+ t F
"Title": "Definite Guide to MongoDB: The NoSQL Database",9 a4 R- } {$ {. ^2 h$ F# C
"Publisher": "Apress",
( S$ L" n/ g% x5 ~5 {% G: x "Author": " Eelco Plugge",
5 H. J3 _, n" M& A) ~0 x "Releasedate": "2011.06.09"
. ?$ R5 F4 a$ ]# U}, C. V# j; f$ [" c
. x) w4 M5 B$ c
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
3 m8 A @: Z4 m. _
6 E, c# x, i7 ]8 I! \ 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
8 I6 \7 V5 W% D$ y; H& k0 V T2 l
/ o. S" `" G4 Q- P, M# W' d1 e3 Y, v 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。4 ]! I7 g4 \. p
: g8 u( W K5 @3 A0 I- s2 }% f
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。. v+ a2 g: A( o+ S5 ^
& p) E) J' [ {. p3 l
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
y3 W8 v" ?# E; y% t5 _# [
- t- q0 \7 y; p$ ~" x' @8 K6 cChunks7 C. o! O7 E2 ~5 ^
' Z1 R' v; _+ H; E# K, X
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。5 M% g! D* b" g4 T6 e0 s/ a
% i6 Q9 e# P" Z
, e m. }8 N, Q* ^5 i- \
图1-2 chunk的三元组
9 P7 f; T* S* }5 A9 Q" E5 D0 f5 K: U$ N0 o# n8 s, A7 E& J7 k
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。- y5 q$ O$ m% I( K
) |& y \/ i4 N1 g) y$ b. l& F 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
' h+ v0 ^/ t% o. K- F- ]- [1 g. D- y0 k. L
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
, w% U7 y, |! W6 ^& i2 X
1 z0 m, Z/ W8 u: V# F* B 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。& D Q. h8 ]2 n$ K
9 Z& C9 X% M4 s+ p: | 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
( ~5 Y' M2 Y9 A, ?9 l
: T6 T$ r# Z, X/ e) r" u4 D 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。+ D3 G! ?" ~9 O* B3 q
$ H; f% \7 }0 e( DReplica set( Q6 O( n4 s# w, S7 x
3 @ P/ N- G$ ~: v) {
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。6 t, U5 |# h3 e. r4 R
+ w' ^( V+ g5 S* j7 L! ^ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
j% A8 L/ R6 K# ^: M: u. j( N$ t9 _# [ Q. b; v
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。$ f1 F& [4 R! g5 a+ e- q6 |
4 `) ^6 n4 A1 V; d Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
5 ?) T. F2 u. t" p4 N, `+ U; _0 X& Y6 T: v
Config Server
# b4 ^$ g) r2 o, o$ A* k. ] . a- b, I* l; m2 H- P
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。+ u6 C& D9 U8 ~. B2 D: g/ }6 P( k
: |2 d" w9 f G A0 W" E* Z 每一个config server都包括了MongoDB中所有chunk的信息。* R9 l# y7 W& I T% z) }
2 X) u0 Y8 g9 L& @% Q
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。2 {3 a$ Y4 ~/ J; H K
& R& O$ v$ W2 s" V5 V
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。% y% l1 Z* n( d: g3 }! `" K9 A
* v" F) ]: M9 d: u MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
+ ]& Q( r; a& A7 J: U2 O
) x( a# {9 C& ~ ]' j6 |' RMongos
h; _ M5 G# A! I/ m% T0 w2 i$ E3 V0 Y) B# x9 N: c* _
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
1 h. Y+ g8 ?4 A: j; p4 J k4 J9 u, n4 [+ |: c# {8 l# z
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
- G: |' d4 a; g* T3 V. ] n: l
u* I# ~* d" I+ t! } Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
0 F8 S* \* G: w$ \7 O( O r5 }0 K& a6 v
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
* U) r/ B3 u# p7 a7 \+ m' E: T K2 F$ l! B, n* ]! a2 k& ^2 p( e
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。9 `# I& H! T3 N
1 m2 D6 `3 D) H
& Q& K' x$ H3 F% G7 f& ?" yReference，5 P% ^7 h* B3 G
/ u( B% P( v. r$ u! f6 d) V[0] Architectural Overview# r: R* N2 } M! P1 p7 ^3 F( b4 I
http://www.mongodb.org/display/DOCS/Sharding+Introduction( l# s! v' a! e5 U, L! b
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
5 T m' R7 M7 G: _( o$ P* X