|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
4 k6 d/ R6 ?) ]) B; z
, P5 V3 B- | K9 A 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
" q" o: U5 U+ a0 Y/ b% `' t
! N. P( U( h5 k% U 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。0 `3 ^9 J$ |7 ?+ S; y9 S
7 y. ` y, }4 q( C+ y& c+ p/ j
9 h3 h2 ]4 W3 i6 [
5 r2 u/ ^7 r6 M6 d图1-1 MongoDB架构图
6 ?5 n0 W9 Q5 r4 `4 B+ v6 ?
# \9 M$ C8 t, Q) j& G# [ MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
, E7 n0 v5 Y4 Q) R& ]- s
) H7 G3 e9 j/ X9 E3 R+ nShards
0 z" m" F# E! _! d4 s# _: K6 _3 e
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。# x/ F* c8 l5 p1 W
% |4 r( t# R: e `" w Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。5 j; o! [. e- ?" S
( H; s/ z. R, | 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
! z+ ?5 ^' I7 e) K7 b8 F1 u8 | Q1 _( ]9 X- h; Q
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
7 z; W" c4 y6 \- f' _# L- t# y8 p# |$ a* j
Shard keys
& d& r3 E. ^+ U9 g! A* ` ( y+ O$ t' [$ @; V* i' I7 m* C+ z' J
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
- Q0 _# C4 E2 \: b5 b/ X
y! |5 Z3 M6 e% i 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，" _; u: L+ Y3 I# z6 ^
4 A: v: c7 p# v- M' C3 R
{
* C+ ~! h8 p) u( B) X4 R, K "ISBN": "987-30-3652-5130-82",
6 E: p* ~" j* R& p/ h' B "Type": "CD",4 B, I5 Z [6 H0 A7 E L2 `" O
"Author": "Nirvana",
) q/ B! e% \: H: k- ~8 Y+ J' H4 Q "Title": "Nevermind",3 B, Y( E' ~1 U9 _
"Genre": "Grunge",0 _' {, _) w# h/ }* M( D
"Releasedate": "1991.09.24",7 c' @+ U% q7 |& H
"Tracklist": [$ u6 C0 a/ D7 [: F% j; h
{
% F: r! E. Z4 o7 C( _6 ^ "Track" : "1", f9 F. Q5 x" A3 K8 d1 _8 p
"Title" : "Smells like teen spirit",2 W4 H( d3 L7 I# V7 ~
"Length" : "5:02"4 Q0 w* j6 J( d+ w' V% ]
},
! N, A @; X H( H; Z3 ^7 {3 e {
0 K0 }/ j: S7 ~: o5 W0 z& T# ~$ I "Track" : "2", z$ N9 ?+ @+ M3 y4 V. `
"Title" : "In Bloom", s% H: _& j2 |% F; S# y# s' {
"Length" : "4:15"' S. @6 Y. O: C& g) X. M3 U* M5 m
}
. t0 o8 X) `( a( x9 u2 H' v ]
! u9 }3 v1 O F}
; G1 R: ~, c1 o# Y( j9 B7 `. v8 \
' M) \$ h- X7 h: L! ` K{0 W% i3 `: |: {
"ISBN": "987-1-4302-3051-9",7 N3 N" k* @/ L& Y! A
"Type": "Book",3 A% F5 r; S# R) D E
"Title": "Definite Guide to MongoDB: The NoSQL Database",8 S/ Z! @: I3 f0 y
"Publisher": "Apress",4 @/ X1 l5 W! T" H9 J; N9 C
"Author": " Eelco Plugge",2 F" D+ x6 U- _
"Releasedate": "2011.06.09". f( z& L4 ~( Q6 I7 r- c8 Y) K" v$ C
}
4 p5 X: \" _8 r( H3 P& g! x
\8 w, ~5 {1 f8 J 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
$ U* @5 v8 c- K4 j, b6 `/ g/ l# A! m- L; f6 j6 c4 _. j
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。2 F2 s7 m* P& E' f4 `: \1 r9 y
1 E4 E1 Q# z8 L4 k) _. ]3 R2 V 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。1 V( p0 L# d& P n& C% Q( U
- z2 ]. S# K& e* Z# D
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。8 e7 v. {. E3 w2 i; I6 o
) ~ x5 p7 E$ P5 j 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。' r: ~4 W# k$ u, G
) F% H- \1 [( H+ }& F* EChunks
- W4 Y1 D; U$ f& f- \3 G6 n$ k
& P9 h1 ]5 f# n( ^( h/ \$ u MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。' s2 j& }& D$ y% D# \+ }
% B) r" B: g( `# \
/ A7 n1 N% |4 w, I/ T* `图1-2 chunk的三元组 + v3 L. E$ E! O- H4 r
$ T3 A8 h6 F8 S( ~
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。; q. ]' {: [. ~% T
r: V9 m' o) [% }, q, r3 W
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。" z1 Q3 g% t9 i) `
: S c8 v, |0 j1 W, m% p% z Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。/ J# r1 T7 M+ a8 k
$ @/ C8 Q0 a! b0 _9 {4 j
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
: P. E( j7 [) M7 Z( \6 ]# y
/ t& S3 r; U. P, H" w7 m 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。% L5 `' g) n$ R) q. n
! S6 I! x. e$ ?; l
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
$ j! \( T9 F1 f, O( C: a) _& S8 g4 C+ x4 C
Replica set
' ^# k- a6 _& D7 r
& i+ u6 F6 {$ Z$ i7 a! p+ y. @( n 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。, ~6 O# l1 a# ^' E$ v3 t
2 v8 M) u. B3 S
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
3 F) W. K9 z$ `& Z1 Z+ [# O8 o8 J) {8 J' y
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
; x# E5 ]/ J7 G9 _2 I: O" L$ p! N6 ]+ E! p# Z
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
& M! k% s+ N, M0 i; }4 }. g' ]+ b/ `! k+ a, k7 x; k
Config Server F% s0 E3 Y, U
! b3 P" g3 O1 n. S
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。9 ~" w# D' _! T# h
$ Y0 m2 e' q; i& U: b/ [ 每一个config server都包括了MongoDB中所有chunk的信息。: K* f- W( j& l$ L; j! N+ Z
3 m X' Q! P' x0 t F Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
/ s/ V( q& x# L- ?- r( |+ C5 W7 F
( ^; K9 ~% p i. M 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。2 p, J: n8 m- S8 I1 i0 l
y2 |. _/ x4 M) H3 Y MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
$ m* v* I' l- X: _1 D! l1 q+ T! i- v7 w9 Q% r. j% v
Mongos
+ n0 [7 U/ x( ~ {9 O7 {# o" q9 v$ `
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
" H) v5 m' q1 N. Y6 j- l6 B7 e2 v7 ]- |6 d$ I
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
- r+ [5 Y& F. M+ ^, w9 a6 _" C8 y" N1 @5 G
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。4 E2 S; M0 r3 ^$ H4 Y: b8 q9 z
- O' |& R' ?. f2 U Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。+ _0 D7 G6 M8 @7 |* w3 ~
& x$ s* `7 I/ S& Q* F" P2 b
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。, G7 a7 j7 s5 Y0 ^+ \' P$ g: b
, X; Y9 e- q: b! e
5 O( G7 J1 [6 u% L/ F# RReference，2 a+ v( Y1 @. V# z7 Z: y
- @1 X2 n9 t W ^/ D2 s[0] Architectural Overview! q* Q3 Z9 G! X- B! K6 Z9 P5 E5 t; u
http://www.mongodb.org/display/DOCS/Sharding+Introduction5 Y' w8 d5 ^% i) @4 p
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
$ r! g" j0 p2 ]0 v! q