|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
1 C5 [ e3 m( m S+ X. a7 y/ H. S D2 N, e, B9 ~; p
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
" G4 Q) \' j7 m- ~
& v3 |* \$ A! a. B/ J 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。" [ g. ^$ D) P' K) Q
0 z0 K, }" `7 i/ v2 I
2 R* o9 {, L( K0 Z4 V# a& w; a$ a
8 C$ d9 t! X! c; L0 O0 U# Z' F图1-1 MongoDB架构图
- W2 \+ q% k" G* b8 e/ L4 Z9 {$ _5 t
; q- N9 t$ W& E9 g MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
/ L$ m' Q* S( I! f
$ W3 _' v* L% T+ ?4 w2 Y. HShards" u9 m3 C% {3 O% N2 B2 z
- N1 r: P$ }! \5 F8 J; D2 _
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
# s& a2 y. b% e% ~& \% {) d9 y( Y3 c n, ^0 e2 i% C8 {; B. U
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。' W+ ?/ F8 v% \) b9 G' A- _0 x
" ^+ r: U) s" n8 ]9 T: m; E
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
9 a U( F+ `1 J% M6 @9 \* @
8 O7 w/ e% P/ b9 ~ 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
& H. Y/ O/ k1 X9 ?
) W- Y: h' U& \( @; s: Q1 JShard keys" T0 ^7 g0 p& r. [( b2 ~
, |- j' {1 E/ i
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
% X" G0 K7 Y" P# M0 H. @6 T" A+ Z6 R. j+ k) ?* @4 m
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，0 W. ^: V l4 p; _- n2 u
3 @- V1 m2 T0 b{
. ^% T0 Q( z" |' A3 }/ Q6 p "ISBN": "987-30-3652-5130-82",2 ~" L& t4 c& m2 P) c9 S% }3 O. l/ ?% w
"Type": "CD",% s( V0 T6 Q9 C0 f$ w3 r$ i
"Author": "Nirvana",
. S* z l; X/ W- _6 ?, e7 K2 k% O$ h "Title": "Nevermind",7 U& U3 Z, e# W1 ]
"Genre": "Grunge"," M0 a* V4 O" `" e$ I; E( l) Q
"Releasedate": "1991.09.24",
$ L# p( B! z W, _ "Tracklist": [
" w4 P2 v0 H! w8 s {$ ~" i. x! D1 a/ \/ _5 b' i
"Track" : "1",' j4 _% m" a8 k, r
"Title" : "Smells like teen spirit", i' x9 w. _, x; J
"Length" : "5:02"
4 s- v( z R9 }0 R4 \+ k4 V8 p },
" r, E) A, f/ g* r {: |1 |8 ~- X5 ?: v+ z
"Track" : "2",
. N2 a& f' R% N; W "Title" : "In Bloom",
r- @; h7 y! n: Q, G' h a& N1 S9 q "Length" : "4:15"
* q/ L$ B+ J' L5 C0 a: G }
4 h6 p6 `) ?$ j ]& g$ G$ n6 e5 u; [" \% o
}
7 e9 c' O! K7 L# Y7 H0 y
3 B/ E: _; H( e/ [& Y( H$ M# e: ^{: P0 H- I- y, K
"ISBN": "987-1-4302-3051-9",
' |1 Q$ F, N) N& R: ] "Type": "Book",, ~/ v* {6 S% x! ~# a+ ]; s7 j
"Title": "Definite Guide to MongoDB: The NoSQL Database",
8 I3 }- J) h7 x* ]9 ?9 m0 D* ? "Publisher": "Apress",
* t5 P- q/ j; x$ s! s' r# d( g- L5 r "Author": " Eelco Plugge",9 T7 ^1 ~" U: F9 H" N) B0 K7 Y1 }3 t
"Releasedate": "2011.06.09"4 |* O! ]( H9 k6 `1 D; I
}
7 i. Z; d* F; l7 h! F
. |& i! c3 p( ~7 R, n( n 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。& C% N' e9 }4 t
9 Z3 S/ z% ^* h6 J/ v1 d3 J+ _' \
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。7 s+ e- Q: u, p( `- G* s
6 x1 n$ _# ~! l( g' s 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
3 M2 S* {2 X: j/ l) a1 I
2 F7 _5 G- c" q9 Y" `' P, G 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。9 E- J( p. L1 H, f! t
+ }7 w# Z$ L4 l% B4 v4 {
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
; z a9 I$ g) h$ y' E5 A! ^
% P* c/ G5 T$ y$ D. P$ EChunks
! M7 ]0 ]9 Q2 L5 C* U: E ) T7 R3 \! h/ ?5 ~6 w7 M) r
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
' ~3 d i Z/ A3 d! A! ~0 n! R# g' M# i9 m" n
3 C* \3 f) h2 ?9 J' Q' V2 a$ {( O
图1-2 chunk的三元组 4 s' `, _3 u" j3 I
( L0 Y3 R6 k* p5 |/ y/ {: ?
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
# n$ t2 s3 V. c/ s. y+ g/ |+ s6 m/ I$ ?
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。. {+ Z: Q( {8 M# u' [
6 T0 c! J! e$ d6 K Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
! m8 f% B2 A, U) \
$ P+ u% G3 H; d8 n0 M7 @ Z 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
5 U, l4 @/ N }. x. ?+ s* C5 h0 k# c/ B5 {0 G
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
4 W$ _1 N5 S% X7 T: I! t) q8 A! _( B3 ^" V) @
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
. C0 P% g- x( J
- w1 v7 s8 g; Z4 a0 mReplica set* q6 ~; w2 |0 N4 r# r$ @
1 z, s% E$ _3 I5 P* u* K5 i% i 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
5 S! S4 z- l2 t2 a( q% X2 U( g: V; n4 A, R* |
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
2 D# ~2 y; |& f8 O* X1 \4 [# E7 j0 F1 X \/ Q
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。+ S' C" L# D- m+ c, F1 d
( s! u/ {. |2 }6 B ~
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。+ f; v( ~8 y) C- Y H
) p0 c/ J9 D9 w
Config Server
% m1 e2 Y+ p# \1 \$ c) X/ {: ] Y( p* e% T0 Y1 T, |3 h
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
1 X! W" _2 S7 b4 Y
* N6 F( b' O2 w5 \; } 每一个config server都包括了MongoDB中所有chunk的信息。
9 P4 f) r8 s3 t7 Z$ A( ^) {& C. u) o) z0 C' l
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。. ^! q5 u( j4 o
7 v. ?6 P$ S& }
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。 ?, T6 t9 S$ Z% Q9 g# C
/ a. g5 M2 G0 [1 ] MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。* Q8 y3 q8 k& {5 }. T+ N
% m& ?2 Z" w- Y- ^" a6 A+ L
Mongos
4 w; r9 V8 \& b6 y$ y# N
( k8 a" |2 F; Z/ D+ v$ S; k 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
1 ~+ L' c6 g5 X. T \" W( O3 K; B* x* b P: }! n
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。' v O( @- C9 n$ s" M- c
- z0 V. Q% F3 \6 U' W8 n
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。# s9 Y/ w" G; U+ t* Y5 j1 {: t% y. w
/ d) W1 w2 }$ n+ {
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
$ J( g2 F( `% D D1 c: ]
* ]' t/ Z' _" O0 z2 Z& E2 ~ 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。' M9 ~3 W) y7 m6 U
3 ^. _ J/ W! @& p% }/ ]* b" d5 l3 z% j# E1 u, [, R/ q
Reference，
' o, T8 S) J9 U# j- c) g
1 c+ }+ U U: r! F) v[0] Architectural Overview# N2 E" i+ m# [+ `( c
http://www.mongodb.org/display/DOCS/Sharding+Introduction
4 {/ [( Z9 C4 a0 l* q; r5 s6 u |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
