|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
4 n) M3 M9 D( P: G2 ^3 ?9 Q+ W |. R$ }. O2 e! x+ d" }4 c
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？5 t6 [6 {$ n6 g! n" X1 O2 n/ s
9 p7 O. s! h4 ?3 \ 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。' V' f) Q1 V8 U& f$ m6 F: _: j
7 c, ?$ u ~( g0 V* o @
/ G& H" N6 X6 |4 k# @; {4 K" g% w" d
图1-1 MongoDB架构图 3 ?% i1 u3 W& v. c! a; p
2 T9 e% j' L' e. Q* i
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。9 Z8 `' x+ {! R% T+ B
! u$ R, e4 O5 T4 n6 HShards8 W+ u1 w* D8 g" B# c+ a
* u1 M) A* z% d3 ]
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。% B+ R. j- F, ]
0 q: |- R4 T0 e
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
, p. ?$ t; n& Z+ y+ x. p& Y
& y8 e' o' V! v; f 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
9 l( \4 c% M: t: K0 G6 D$ J
- V" ^/ U/ G# `1 U f+ W8 G; q 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。/ N: s' b7 u* G5 j- o( u
! C+ e+ K E) m/ q
Shard keys
5 H; g$ \ m, p2 f. \ 1 r: ?1 I8 O) s: b$ U& ], V
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
; F O! i* O: c( C5 `" R7 g* y8 J" Z* u; }
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，$ f+ r& `& a( T; e6 v- u; G0 ^
! K& z* u0 l( X, c0 P2 I{3 N' K* r Z2 j/ {" T F. N4 A) \
"ISBN": "987-30-3652-5130-82",2 A1 y+ ]7 b4 D0 N3 x: x( M* }# y6 ?
"Type": "CD",/ J" N( |/ ?% ?* F/ }, n
"Author": "Nirvana",1 K2 X# @+ l# J$ |5 l2 L: V
"Title": "Nevermind",8 k( x* J5 w! G2 ^ N
"Genre": "Grunge",
2 |' O3 p( C2 T/ V5 V "Releasedate": "1991.09.24",* Q3 t$ H; c! A) G1 }0 T- I$ s& e1 @
"Tracklist": [1 [4 Z5 ]# b" Q7 V8 t
{
" ?5 P2 O5 x; P2 v- {1 e$ l! ^ "Track" : "1",
1 I, u: y+ C5 D+ c7 d "Title" : "Smells like teen spirit",
5 p+ }4 V6 ~8 E0 l "Length" : "5:02"$ O, z$ T9 o% T/ d) v$ |7 w
},
% c# z+ M6 N1 C) c {
) o z+ ?3 W0 B0 o1 f "Track" : "2",2 }! S7 U0 t! j4 r, J, Q9 n8 V4 J
"Title" : "In Bloom",, l* N5 t$ A0 k% U6 D
"Length" : "4:15"
8 H' O- \6 o$ ] }8 W4 B6 B# l% }7 p7 t y) X1 z5 ~9 e
]/ V3 m! Y& f5 q2 c8 J
}7 T9 m. ]- _$ ]$ s
. y* f u+ R# m9 u8 H2 j{
# D" W' X3 W; l! }! X" z "ISBN": "987-1-4302-3051-9",% F5 S- @" @: Q. O$ T) K% \
"Type": "Book",) r$ h1 _. J9 ]' _; Z
"Title": "Definite Guide to MongoDB: The NoSQL Database",
. w1 G6 g0 P5 T" h0 k9 c3 y; C "Publisher": "Apress",
3 P, b, z- h1 T- X "Author": " Eelco Plugge",
, z( y2 p2 c3 d% e3 ] "Releasedate": "2011.06.09"
. s- |, i7 X! |* f! i}
8 }4 O4 x9 i* W
' C' ^. g' \8 W 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
9 J! t6 L- t7 M' b& E+ |# \. z* a5 L: F
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。6 a: P/ g* C) r) A
. B& E! E% Z3 R6 {3 N z H: l 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。2 L& c5 o9 Y4 q2 R& }
9 Z3 A0 h; g+ r Y
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。2 b% T4 J7 ~; o4 d
0 D4 g8 I; k6 ?: d7 R) R# Z0 A9 b& _* W 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。7 g, l* r y, l& e& v3 w6 a
5 h7 N# _8 e( W- I
Chunks N$ C( V7 \( K5 r, C
* b) `- u4 Q) h# `6 D' k* n. P3 H
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。3 u& l/ b. Y% U, N
f+ ` X1 x+ R, A5 c! ^9 {+ V. v
/ ~3 P) v3 F4 ^; P$ w( r. n# Q" f图1-2 chunk的三元组
4 A& r9 Z2 p+ F0 z% p/ e2 t
6 D- C" W, |0 B; [7 j 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
! b3 U3 a* l: C6 m i4 f, N) N& g! k
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
: f2 i- h2 z3 R" B; d( ^* M* ^! A) B/ U1 N- M
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。9 R0 M, B. z; T* f" I
7 N3 m' k; \# r- W! ^- a
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
. y: J! i! T! t5 e" @( ?" J- ?, j( V$ I# O: h! s1 M' B
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
) p$ H4 i$ y X" G1 T: N, E$ \+ B1 d( u) c) \1 [ g5 e0 `) m L
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。: Y5 d8 Z0 A J% s7 ~3 P5 h
) L6 v3 g/ n4 x. O% H9 R- L, m" `4 gReplica set
3 B3 M4 J$ i7 L0 H9 \" ]) m
! G" W5 r0 Z. Q g5 T2 N 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
$ ]' p- C2 a) x1 P* B7 U' B# H
0 \! ?4 t6 B8 g% e {' ` 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。6 e T; g+ k4 b ]: g5 Y4 A
. B7 Q0 V( e6 v: ^' i! y& [
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
# k% b6 Y+ \; |& O; V1 p7 F+ E3 p9 E0 V; l! O
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
9 f$ d# u& k" V9 a: T6 e% W! @, L: \) j( {2 D K( H
Config Server
: z z7 k- m G# @2 s, ]4 m
7 x6 u+ t. i1 ~4 a3 w Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
8 n z, d6 O) U: b2 N: T7 @
% ~# h" E( v. S+ o' }( T# o 每一个config server都包括了MongoDB中所有chunk的信息。
% b2 U$ X0 l" c* k' I5 y0 E) j2 d- C1 S1 P8 J
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
: G. j! r+ Z. O* w$ ~1 j7 \. U0 i8 R) z
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。9 x- }! a; g" j7 ?% B; E) ~
" _1 k) g8 M9 Y MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
, B( \0 M8 s% @ G$ B
: j2 k U! p' j- K0 D# O) dMongos
& ?( F+ }5 D2 l% V: Q6 r- O0 b8 E1 e% S5 ~0 s5 @
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
+ [2 i( W4 Y: W4 t3 w5 k" q( m+ f& F
% |# K; }0 ]( S8 Q; L' E 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。+ K0 s" a/ H) J1 A* d5 J. }( L
. P5 W' J7 M& a9 v, W$ G2 x Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
* _. @; i- a) c* r! i# K8 A3 f- x, \' E7 U! E3 g) f
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。7 { V9 A$ K$ |' A# v
- V5 N p6 H" e \$ z, J6 T! F
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
, B: g6 |- j F/ B7 x- @- m9 Y& E% C1 x3 o8 L
+ S( x0 k* g0 u" t" n
Reference，
) y( }- |) [+ ^
! r/ j, M& ]1 e5 k4 g7 \- Q[0] Architectural Overview. ]$ c/ H& _. P0 c4 _1 O9 d
http://www.mongodb.org/display/DOCS/Sharding+Introduction
+ R( x( H" w( J; \1 ~8 t1 D |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
