|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。8 Q) q/ J3 o8 [1 R! M/ C+ B) O S7 ^
& }" n! `' \3 [! c' t 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
- T1 T' B! u; |9 x4 B
, \/ @0 }/ h" ~4 m0 J2 h& I5 U! B* P 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
' M( Z# V& S' O# E/ L: l4 ~) H( E3 K3 S1 M) S
$ W/ N* I5 X* w: r0 I: s% }/ r
2 S' U# t( \9 _% Q$ P2 _4 s# c图1-1 MongoDB架构图
3 Y& u" _3 G0 c* l* N# P: g. F5 Z( S! ?
2 L( Z( u, r4 i MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
9 ]! Q5 o' Z1 f) t S, C2 ]/ r* F
# S$ `+ @4 j! I* \Shards3 u( R+ R+ D8 ]- | C8 f: A
* ?; }1 Z @" g, a
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
* ^1 w* |% F, J6 n6 S
6 x: H3 }9 L+ G5 j Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。/ Y S8 ?, y+ S/ n; A* ?0 O9 ?
`9 D6 M$ t2 J" E+ _7 R
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。8 \. ]% T9 c: Q. D( X7 v
$ |# x, L- s* X( P: B
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
. [& V( G* e3 Q4 A& v+ _4 z
: ~ `9 Z9 i7 [$ L: g$ ZShard keys( _! d9 s2 o! W4 O) f
& m! q2 _, E5 K; Q 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
1 ^. l4 C4 w: e( Q# H; d5 m4 P% v, a* P
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
# S P7 ~( Z1 e8 h* V
6 R7 j0 X' u Q' M* i2 s{7 L9 \! l6 D" z
"ISBN": "987-30-3652-5130-82",
3 H1 u4 z* l7 x" |5 t "Type": "CD",
- |' X/ j. W1 Q7 u, Q* T "Author": "Nirvana",
. y U' B- V) G8 K "Title": "Nevermind",
+ a V) Q# _2 m, T5 p; o2 c "Genre": "Grunge",
9 B/ N+ V7 T. @$ m6 H# Q, W5 W "Releasedate": "1991.09.24", ?7 j4 G6 e! t7 I
"Tracklist": [9 P% t# B9 T" Y* e# l* ]- q4 z. w
{; `+ _1 q( n+ D3 }: Z
"Track" : "1",# M4 x. E8 Q' c9 T8 r
"Title" : "Smells like teen spirit",
. H, H' }$ e* } "Length" : "5:02"
) V/ ^! ~. T* ?: i },
( X) b" f3 Z4 M; L- C0 e {
1 e7 Y: o0 w. W) @9 \9 \ "Track" : "2",+ T) q+ ]0 f$ }* I3 H6 x' E o
"Title" : "In Bloom",2 g5 c# a6 Z) o5 P4 I3 W
"Length" : "4:15"
- b& R f; Y H' c' c }
0 J1 g% Z3 @ ]$ x+ o- b ]
) Y; G+ q7 V+ s6 u}
5 b; o/ J. ^+ [. l4 V7 B6 L
( f2 O# S- X9 Y{
3 m( U G" M& [$ J) s; ?1 h% s "ISBN": "987-1-4302-3051-9",
+ t; ~. s# p6 k3 o: y. \" j) d9 Q "Type": "Book",
# x* G" V8 I. g( Q% K+ j) Q% [' ^: c "Title": "Definite Guide to MongoDB: The NoSQL Database",# W. x' Y0 L; @1 ~) c8 ?; \
"Publisher": "Apress",
4 U E4 d2 r; P6 R5 {) _8 |, O "Author": " Eelco Plugge",, `9 N5 |1 e5 e
"Releasedate": "2011.06.09", H }4 w7 [2 D* _: |' D# u, \- N
}
9 O, {9 J+ c2 @: e3 ?' [% c$ H% D5 m6 [9 X
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。$ A, e: [+ `) J5 W& x
# C$ z2 p6 y) G1 a% `- l
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。3 d" R1 z* O. G1 b3 H. F2 \7 R
7 d( G" Q- {8 w/ d/ _. n 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。6 H' c9 f: p' N" i$ C* D: P: c
6 ~+ G$ ~; r9 R; L& W0 O! z# A 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
' @. B9 l9 v* n/ G% \, N9 b% u
) R6 {6 D& p) t7 K: Z9 I 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。& j( b9 S; i2 R s. ]% f- y3 k5 F |
0 I) T& [ ?9 G. u& B* lChunks
2 t1 w6 t }8 u
' M5 _# }7 \( _' k- F$ ~ MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。$ e+ A. Q; o- o' S( z
. `: d! L7 O$ d& V# @( k
8 I4 {6 J1 u4 Y7 |' |
图1-2 chunk的三元组
! x" ~6 }- N2 D0 h: N! E
. r* L. u( s0 d 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
0 F- W1 D) g8 _- s9 C/ m& f. L- C
P* \3 |* m3 X 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。$ L# T0 s+ @9 }* C% I' W
. N- U1 C% [; P, X" }% M% V* ] Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。) a3 b3 L: H* `5 K8 m2 j5 q& x
# p. s2 H$ d4 s3 D) p8 O% a 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
/ k% k3 I1 q/ T/ {/ K$ ~6 J D4 a+ I( {- f& I& p$ J. ~
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
" Q; c N7 ?/ x$ \7 I) r
6 f2 H& W5 B- h- v6 T 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。* e4 O, j9 s' v/ z/ t- @7 T: h# J8 @
: T# o) R8 D3 m9 _ p) e- p
Replica set3 x) I. M4 g2 w5 R6 r% f8 i. M
% f. Y% y$ b1 i5 m* s* e 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
% D6 D+ T( s D, D/ Y @% x9 O) R7 I0 m: ^& Y& G: H
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。6 d( S: W, y* ?
2 }7 v- m- x+ a, P& X$ i Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。1 J! ]4 x% k' o, W- U/ J4 ~
" @" g$ z( G1 w$ _; W0 U. Z; p Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。% P5 u, } c" t9 w' `0 W3 d- _
& E1 X6 w' l: b0 m, B( W* ?: mConfig Server$ R1 J4 i; w+ L5 N2 ^1 c+ E' b
3 e9 a* E+ [& p I0 A. {! R Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
( f. t) @+ {- h, r7 g! N% M, j) M5 W+ S" H+ A
每一个config server都包括了MongoDB中所有chunk的信息。
: A9 [9 i' O9 u9 G. E' v# I7 S7 k6 e; C% h; I) `8 `, B
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
" C( E8 o) Q' P, j. Z* S. ^ y
# `# Z0 X: A$ J% L1 p" d 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。4 _& p0 U* t3 V ?" T
; D+ H7 n: _3 i
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
% S' x6 P, l1 f- r% |, M$ Y& Y0 y' y8 j5 t# T, u. P
Mongos
\: H/ V4 ~$ P" N c% I/ Q: x7 `8 U: d
# B( |0 q% U7 `% Q, ~ 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
, [; M$ w3 z$ x2 v4 N$ _9 q/ S7 }2 U1 A$ `# l% ~8 x6 K8 H
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。" c+ @5 e# [& A1 J+ c! M! T1 h
0 r4 d+ d( Q( c* p Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
2 F6 w9 E# _- b% ?! Y4 C" e5 z0 s2 ?* G. [" g! y
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。# g; I2 R: Q+ F1 u
5 _7 `% H) d7 T; {4 l 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。8 i6 t6 e- ]- i& [" R
5 M ]% p: w- ~6 i+ T0 y
( V0 z0 Y5 S& H9 |
Reference，2 E& W+ q- k( J* Z4 ^
# ]2 ?6 _" C3 N& m. l# M7 B6 M/ K. x! h5 m
[0] Architectural Overview
/ i+ k7 v. R8 j2 t7 K2 D" f) D: K% Dhttp://www.mongodb.org/display/DOCS/Sharding+Introduction8 R4 c5 v A2 l$ D3 t
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
a, z8 |* R/ O- R