|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。# v- r& T. B0 p; D' }$ @
3 j1 i. I6 q4 u$ l7 y/ C 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？- q- G. ^, d) e& j
2 k7 x9 A- w" l+ P! |6 U 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。$ w4 l+ u* f3 S1 n. W& Q+ u7 b+ f
' f, f5 l6 f% @0 g
+ s6 r+ z- n/ W- Z5 m) i
' T2 T$ {& {( S图1-1 MongoDB架构图 4 \ G# C. R, g5 j/ S1 y U2 z' h
7 B3 G) Y& l6 L' |
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。( v# A7 B; ~; _+ Y4 s+ {
* I: G6 n: t7 ` i8 o# lShards
6 Y8 ~8 I$ t, S" }9 @! {) X4 V* I$ _9 \9 U5 q6 [% v; |
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。# i6 S L! p/ c1 I# r
% Q, N6 b% E( ^/ ]+ k5 P
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。& V9 E/ Z! ^9 b' b$ O l
( K2 c( H* U# g$ E" w }
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
, {& D% M& k6 R$ b9 s2 W
# r) D+ H# q, W 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。5 X" I0 K _5 p" c2 J
' E, l g. P0 {2 }( w
Shard keys
- I- b( o E0 m9 s
. ?/ o: `( m/ m+ w# T1 D0 D+ [5 p1 T 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
4 {2 e/ |9 k( ^* `- g7 U
$ N, J4 ^4 S1 b% |% b1 [ 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
, b( k9 e ]3 \; W8 a. ?
* d+ D! D$ l$ A1 b* Z1 c) @5 }9 c{. e, E; n0 ]7 \; M' T
"ISBN": "987-30-3652-5130-82",4 L) O( R" [! p- @/ Q4 Z
"Type": "CD",
' k& z! ]2 c* l) c, ~7 J1 S4 ^ "Author": "Nirvana",
; ]* z3 G2 Z7 A0 j8 G7 n "Title": "Nevermind",# p+ _" @5 g9 ~
"Genre": "Grunge",
" ^8 y# X& h! h# I3 s) A "Releasedate": "1991.09.24",: M4 R7 t3 R* W/ l, [" ]5 _
"Tracklist": [
- K6 i8 R; ?; U3 w0 V1 {7 x {" n( { v& t: L
"Track" : "1",
" N! C& C o+ n "Title" : "Smells like teen spirit",
0 I6 O: K8 F8 V" d& e "Length" : "5:02"
# i8 e5 M0 w& [/ p( b },
9 X6 u7 k4 L$ {7 T, i6 q {
5 k: O; d* s! l "Track" : "2",
+ X4 ]( g. J- q6 }6 Y7 @3 T "Title" : "In Bloom",
; ^* m/ Y5 @ w9 U "Length" : "4:15"1 d' e6 i; {& _, }
}
( @8 ~) u' P% H, g4 O6 F$ G ]6 v7 x3 j; f0 I( y0 @0 |
}
# f" k8 W0 z6 v N) V$ G+ `2 i) m1 ~+ \) l
{# W* H( C% Z% Q9 a+ E
"ISBN": "987-1-4302-3051-9",' p1 `5 F9 c3 R/ p# o
"Type": "Book",1 N u" G+ I2 J. U7 @4 _' E2 _
"Title": "Definite Guide to MongoDB: The NoSQL Database",
; m9 M+ r# b% B) i- m- O# T "Publisher": "Apress",
: Q; S7 m1 T7 E% h: ` "Author": " Eelco Plugge",
# W; v; j0 O- ~$ S F, I a' q) E "Releasedate": "2011.06.09"
' q% G, a; _5 T' X: |}5 x, j4 s; Z7 y$ T5 _ M2 x
1 z b; m% C1 f1 C) H, w" x 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
. R3 N* [' ]# N- z9 S) }
: b }% f2 H% A' t, P 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
9 {9 q5 }8 z/ h! v, l2 E* ?5 ]1 A/ _5 y' @, C: [# C# V! k
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
$ c0 U& k5 c) E5 k, h" z* P7 j8 e, B O* `/ Q: c c8 Y9 B1 x$ [0 d I
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。2 N) W4 J1 z! v0 G
) I8 t6 v) I2 I) H
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。# N! P7 I& c# X: H$ w) n
6 F7 w; ?* v4 t4 \& y8 DChunks
$ v5 x* Q3 v/ `3 K6 e t' P ) W1 h6 f, b6 j
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
`; L; q6 l, ]
& P! | d! V; |1 i% R* h, v+ r2 n
2 H' J: i) g( J' _8 p9 l图1-2 chunk的三元组 1 i3 }, q) s4 z
Z3 y3 u$ |- Q) G1 _$ r 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
; Q( e% E. A A) m9 A! m( ?4 q
" r* b, y6 R# Y$ \0 _ 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
7 f4 j6 A5 Y6 d; T( i! X0 ~
3 z, b6 b' z1 D* S; y( J$ d& t Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。* A! ^6 k! [6 ~7 y
) I( X; O4 W- y2 v! I* K' l 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
. h0 ~$ Z3 _4 R% m9 x) ~1 x! u( C" Z
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
5 j, P" o. o- }$ U9 Y$ _1 T m% O$ M3 t
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。; {4 p3 d8 v7 e7 G- P. m( i* s
$ f) x5 {$ G7 w4 \6 O0 S- {* LReplica set
1 s6 j" P8 U: h( g , S9 X4 a! Y- @: X' c; B
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
1 S0 h7 t. D4 ]6 i# T8 v% d9 q( G% b8 X1 L. {8 ^$ @
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。$ m; K4 S N+ Z; p5 K. D
* d0 u- y& r* _" w* v5 x3 C
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
. e1 d0 ^9 G7 J6 G
9 p: r$ s: D# r$ L8 G Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。' B1 K6 A, x& o
, I- |/ j1 L* _$ [4 g
Config Server
8 Q7 \$ c' a% d/ v. J
. \) r- l5 c8 S& X9 I9 ^* W Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
) |3 {9 E6 W! X, t: ]5 P3 B. e' Z7 b, A+ i$ e* C# J2 s) ^: a
每一个config server都包括了MongoDB中所有chunk的信息。% h R+ X8 U1 S+ _% e% A% ~
7 j5 z6 z7 q* J- A: Y& l
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。! H+ D( q8 i3 y* P2 @
# f% f. e- _3 s$ ]. ~% |( u- u3 ` 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。! n+ D$ ]& d$ U
! i9 _; @& O P" y MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。! V! Q8 K: [; S+ [4 G
+ j1 m" `- q7 L: x
Mongos4 v8 c: F1 K+ ^0 x; f* s( z, ?2 B% B
1 q6 X; `9 P. S2 @
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
# M, L; g4 R" B+ t6 M0 O3 j" L( c
0 t! c; J- K. I0 w4 \3 {# [ 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
1 T) \+ I) _$ b/ l4 g$ Z( u, R! h! c+ o7 G
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。; B n* n9 \7 Y
- w( _& Y5 b$ O* {3 V, _ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
( ~9 b/ ]& E6 q! t; k: {$ j# n) h0 k" V" B% ^) E$ Z) X
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。; m" U6 k# R% `8 \
* `8 r' F; r, R. w1 U$ ~! l6 _( m7 S9 u6 {! L$ m0 `% s
Reference，. ~. }& O2 G- z2 `# K
6 o% t1 L& s* ?6 P% r* T3 o[0] Architectural Overview
& g( N& }0 p1 q7 E3 I" l, P- |http://www.mongodb.org/display/DOCS/Sharding+Introduction% R0 Z3 d* F5 y/ L) v, A7 u
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
3 E+ y8 V- c2 o; D+ F$ y