|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
! r& k0 {6 ~6 D6 v" i2 F3 e% [, R6 m) J ~
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
9 Y* ]6 f" z o. Z2 g5 T7 F8 [9 P) N/ e
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
( p! v5 V( o$ G; o/ ?, r$ Q6 \, D3 V4 o9 J O. t) g
8 H: @. N! p' D
$ K B9 W: d- h! e" s) ^8 S
图1-1 MongoDB架构图
+ N) X) }5 }) G$ }* M8 I( l- m7 V& f. f' i; w9 u2 @8 V/ F; y. `9 _2 Z
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。7 w! w1 v; Q1 Y1 J1 c5 C
1 ^3 e* J% k9 S8 w/ N3 X/ tShards1 e: O) p0 {& s) S# t. }& l, ?% C
& v( n% c2 O/ `; c) B' {
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
+ B, @( @8 z% o9 l2 \, Z" [/ t2 T6 J4 _2 }. m3 N; p
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
3 o: H/ N- d! r/ W/ _/ \+ g* J! o3 e6 h0 j8 ` y# R+ g
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
; b. z# a( X* r5 ?) L) k& |
E4 Y( H* s& x, L9 |+ a" {7 @! y 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
/ e8 Y% u3 _7 M6 ~6 F3 `2 ?. L0 U7 B; b! S8 h& E
Shard keys
0 z/ E+ d. V8 d- t6 j
7 |% ]3 R& G2 x- g0 j 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。! J" G6 E7 K8 G4 Z
: N+ s/ w9 I2 E( e f X' s 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
. S {+ U X0 X- z l: T; N
0 y; ^+ d3 ~2 I; x7 |/ C{
1 v6 V% e9 o& _' e! Y "ISBN": "987-30-3652-5130-82",
, U8 H' k/ B7 ~; u "Type": "CD",
, [" K0 q# U6 P; Z# } "Author": "Nirvana",+ p' l3 x5 X7 m7 T1 n+ F0 ]0 f
"Title": "Nevermind",' t1 g* s5 B+ h1 {) B
"Genre": "Grunge",1 ^) t" U0 i$ |' F' G4 D5 U! b
"Releasedate": "1991.09.24",9 B) g5 V2 k! ]; [, y
"Tracklist": [2 F7 f4 a, w% v. ^) J
{1 l- p3 A7 y, @; ?& d6 \; x
"Track" : "1",
* y" b0 |3 A2 l/ g' e2 Z( O "Title" : "Smells like teen spirit",! ]' h0 |# {+ ^9 ~
"Length" : "5:02"8 z5 ^1 U5 [6 F' {: m
},
d3 K/ n! G$ R {! L* D( n. R6 e* T- `6 k5 u& m
"Track" : "2",
* g( P/ F2 a% k% H0 Y4 M "Title" : "In Bloom"," o- G5 ^6 }+ L; K% b* I% ?" d( P
"Length" : "4:15"
1 e2 D+ U: d: v0 g/ E; J/ Z }
8 I5 m+ [) a P c4 b ]
' x. `. y$ `0 Z$ l% \}
- w4 u4 S$ K4 W8 x- @5 Z
- i- b$ f8 n* M/ \- \4 v{1 e0 W( g! E: A0 q
"ISBN": "987-1-4302-3051-9",
9 Y4 k& r0 o8 R1 ?- {% [; \ "Type": "Book",
% v- k4 b) ~- u# P "Title": "Definite Guide to MongoDB: The NoSQL Database",
% \1 r+ Q$ K6 w4 C "Publisher": "Apress",, C2 ~5 Y5 }9 ]- C4 Y2 s- `/ K5 S4 \4 r
"Author": " Eelco Plugge",
# p0 q4 n; y, K" ], W+ b "Releasedate": "2011.06.09"
) _) h+ v! i) @, O" |6 M" B, ~}
/ Y! R5 F. h+ l1 {+ y1 B' \( V) b, a# m) T) R! U
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
# @) f. Z D) [+ G2 J4 H$ a9 k
8 H: v: o3 f8 ?0 A C 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。1 g6 U \% H3 n
, F% P7 m1 T1 E' N \5 H 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。: J* X5 U1 N* ~
1 q g9 g5 |( o/ f
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
$ D2 ~8 V: {9 V7 {* P" U: u' \/ M" O; y) L7 b; k" f
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。( f) U+ ]8 f. d+ O& {& |
; U; B9 N* e6 ~% V3 I
Chunks0 M' O. E2 l9 p
* L4 S* E0 m# N( e! N0 Q8 t MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
: ~, D. [% W: q* O5 T
5 T' O$ g7 @" ?* T; v t7 t
: W! ]6 A, O w7 o" c图1-2 chunk的三元组
) d4 N) q+ X" W$ A$ b( K, v B" a+ L& j+ j/ A
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
y! V' h9 R, T2 P( }: M/ s. b, ?
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。) L, {6 ?; S- S8 x; y U2 L2 L
5 {4 c6 p" x5 z6 m- G Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。. X* R2 u( H4 Q$ K
1 I/ n; R& q8 {, H) X+ t3 q l, c
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。. R$ X- X& x, ?. d8 m7 U, O& _7 t
9 h4 i7 V$ A4 l$ d7 S( j3 |
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。( ]' h, D" F" G; P/ V- F4 k
1 Z c2 O: j" h+ r6 |- X/ `
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
$ e( P9 S! e3 x0 d( t+ ]0 z6 @- k3 j! O6 M: E" ]
Replica set
+ ~- ]% \2 u) F h * d. L# W% j) v+ o' X* W. t
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
1 i+ Q- _( q [* [' T
, {: g0 i) X/ t+ f 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
! h4 q, L* M/ r$ y2 W$ x: O* {/ {) S) N! L+ A4 d# i
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
& z4 ]5 d' d/ [# @7 g; u
* Q: e6 S1 L5 }: E$ O6 ?5 z7 z Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
" N: A5 `: F0 z! z1 ~
) B$ N/ I* F% ]# N+ RConfig Server5 j9 e/ f$ M+ {+ X4 J8 ]5 e
, G% g/ o3 s, J# X' ?/ T
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
& N7 ]% S7 e% O5 I1 X2 ~5 O0 V& U" n- W
每一个config server都包括了MongoDB中所有chunk的信息。. x- E! q6 P% q2 z- d3 f
" Z" C& B8 d3 D4 B1 d& m# _ Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
# r2 {8 {$ e+ g. B3 R! P0 R, a+ }/ S8 ^' @) Y+ W. a6 j2 J
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
# \& l) Y) b- [% `
% j Q1 L, U' N% j0 r) y MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
" J3 G+ G7 V O) F: P6 o& }) P
$ i6 d3 V- F% f1 zMongos
6 ^) s$ i" c# N! N3 I" S/ T
3 h7 A% p6 j$ d/ T r 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。# r% D1 Y; F6 e2 K
" B" }5 F0 i, f5 K
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。/ @- v3 S: x2 h, y) o$ f t
3 `1 n$ _' S( C9 f! y! J8 w
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
: P/ I% o: G4 A0 m+ Q9 U
! t$ M0 @3 O+ o8 K4 k! \3 L" V# _ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
+ w. x' Z$ Z( J( `0 K" x& Y% F2 d9 a C5 J- ?
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。7 k( D* L+ h4 R( h9 j
, r4 _; p2 h9 i/ e3 _1 ~
5 w3 I m# u' u# g w
Reference，5 F6 |: z6 I9 I8 A
! l) n" z6 X$ R2 U2 C/ q
[0] Architectural Overview
+ z$ g! T! |9 ]http://www.mongodb.org/display/DOCS/Sharding+Introduction
3 x l& h- T2 _' z( z' R0 l9 s3 c |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
! q5 U2 A# c8 q5 N9 v