|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
) ~2 S( h; Q, Z' \& c8 }, ^" J U" N! i3 M3 d6 [- i$ {2 ^3 w' h
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
, F% _7 m) R+ j4 ^7 U& P1 a9 n% I' C# b$ C T8 C
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
7 u: L5 e$ g3 m; z: O( W- F, f. f7 m' r# O* _0 y1 E8 Q; v
9 L- c5 R* c$ B5 W* o+ T& R0 N6 E/ e& T5 P# l3 Z. M* F& h
图1-1 MongoDB架构图 ( q8 q& u3 @6 v" Z3 }; E
6 H' O' y5 ~- i; ?8 z D% k/ s( ]# T1 m5 ~
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
0 E. U0 D+ z8 K/ S3 z1 K4 }
' m7 x6 D0 v8 z6 P" PShards) d& [# a/ }# X1 N/ \2 x) w: ?
* y) W2 s* R: E0 U5 O* Z
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。" L7 K9 [, b' G. b" A6 t
% h, V: c8 t- D! {( F Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。9 m+ h. C$ g3 f+ B6 I6 R4 K. |
4 @1 S7 l$ p9 m/ V! C+ D 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。, Q3 g! ]5 R0 E7 `2 y/ G& v# `
" U$ q. s+ I- N
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
* K+ p4 Z# g( r& z' ~
* G0 R3 n1 E: s! C# jShard keys
0 d, Q0 F( h; V / } C" U& s- o& Z9 B* m
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。6 I, Y/ [0 T e5 P. }3 J( x% _
n- k# A+ \6 J+ w. f
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
& I* j5 }) Y8 Q+ l9 s. M
; v% U% {6 y) u: X{
: ~8 U: F: o- ?0 k' |3 `" u "ISBN": "987-30-3652-5130-82",
( i/ i2 O/ ^( c" N P4 r "Type": "CD",
" V8 |) q/ K$ b3 p "Author": "Nirvana",& b/ a- U7 @/ Z& q1 W
"Title": "Nevermind",- X' S0 i# z7 r0 o; ~7 Y
"Genre": "Grunge",
/ k$ _4 W, w* Z* ?4 h) H- O9 ]' P "Releasedate": "1991.09.24",
$ U# u; |6 c7 g B0 t' w "Tracklist": [: C' {: N" |# G, v( B3 p: r4 d
{
D( T! O8 V. K8 y "Track" : "1",
* W, x1 C* C( c- A- w4 C "Title" : "Smells like teen spirit",
+ a5 e+ z- j$ r. l4 V# S( ? "Length" : "5:02"
) K a) B- e3 H$ q1 S; Y+ i },, A$ B) U7 G$ J% ~+ ^
{
- s9 \6 k+ V+ }* I& x "Track" : "2",
+ J4 [) |/ ~" g$ ` "Title" : "In Bloom",6 I( n$ L. x; e# F: Y
"Length" : "4:15"
% V. n U. Q1 a4 b$ Q2 s }
* J( M5 O5 l+ A+ q8 P1 J/ m7 x9 [ ]# J# H* a: `! X
}
0 S- o4 [8 Z. ]
2 T$ l/ ~; N* v, V$ j: b6 K7 ^{) e& `# l1 h" e0 `
"ISBN": "987-1-4302-3051-9",% E4 g- v+ O1 T, K
"Type": "Book",
: `9 P) y6 a. }1 S) j* V. b% U "Title": "Definite Guide to MongoDB: The NoSQL Database",' `/ w) a# D( N I1 t ?- O
"Publisher": "Apress",
" E5 S; s1 G- c4 H+ A- I "Author": " Eelco Plugge",' @. r5 D% ~9 L! v( V
"Releasedate": "2011.06.09"8 M. r; O; v1 E/ s( M' v* q( p
}$ q( \, r' q0 [7 @
H3 T4 c: C& d* [& { 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。( t7 S8 d2 Q" b. k! p0 ~% M/ O6 a
' E/ W# I5 I0 ]( }
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
6 p. C! v K" B) U3 @0 D/ `8 P# c2 l% Y. H j) J9 ]+ `8 x9 S5 a
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。! }$ k9 l+ R" x; [' n" O) O. P
/ r) G5 ~) c4 {6 J
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
2 X4 f2 c. B5 s& x' y
' ]5 C2 L/ X D+ c 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
' u# h3 x R4 E5 P* I( `
& {0 e" @$ r5 b4 HChunks5 F5 g2 x$ k9 d) x9 @& z0 e
% J2 h* _. H% @# a' i
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
# {$ o- {& i7 m1 `! l: K3 f
' t! n" P" F& D/ R K+ j6 _
7 Y: a$ W9 I1 I9 q. P
图1-2 chunk的三元组 - q: P! F& X2 `# e
3 d) u- j0 l8 | 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
! T$ V R/ c0 T, f
; h' C! M+ X' m' `/ d" @ 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。+ k& M5 n0 f! A$ r2 @% O7 @, n
& A$ }2 b2 | j3 F. f* \ Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
- I e3 B: ^9 j! E; s/ h' [( A# y T, X* T) ~1 W3 u
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
/ L% F5 B3 |+ J* r4 M; f2 d) D A6 F: X1 H- v4 Z* ^9 X8 U! P
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。# i& d g2 U) z2 m" x2 H( F. X
0 O T/ h# M, X9 i/ U 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
, z9 k* c. K" B# f+ C' T& h. v K1 A$ m% g* Z4 W& q: e2 Q n
Replica set, Z% a, q. T7 t; \: }" [5 S* y4 R
9 o: M: \1 h3 s6 F7 p
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
: |% v) e# x0 |+ D6 ]. ^- j! m! f! n/ _ z5 x' J$ y' v
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。* @+ {# W0 b8 e6 D' x" S; O
' P' v- V8 A4 F2 s* T8 ^
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。( _% F( q" Z' c
4 K9 P( T8 L1 s; P) B Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
$ x+ W1 |& F2 v: D, R4 p; ]3 W, N7 c( n/ F6 k# P# m" U
Config Server
4 k$ j0 m( H* h* X- _/ O 3 T" R6 c& S+ ~1 g
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
1 ^, L v/ W, E! l+ j. f
4 ^8 Y: P6 V; N" ?+ \ 每一个config server都包括了MongoDB中所有chunk的信息。/ o- R# i* m$ M
5 Y. m+ x" j8 Z8 l2 O$ J/ l4 d Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
+ C' \- u2 \) _. _2 i( ]( R. M# ?6 d8 e5 z7 W
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
* }. P' P% N7 `4 g4 c/ t; c* e* M7 ?- Y4 f6 P A0 c: E
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
" j& b$ t' o4 A* V' ~6 E+ _( O( J \8 V
Mongos6 G* u3 M4 Y/ d
0 i6 P+ u5 u6 y5 y$ y; _ 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。+ A. a' }! h2 n
1 V/ w) i2 W' \, d 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
: Z4 e+ y( I$ R+ l! b+ G; l/ \6 Z w( t( X( D/ e; ?% g
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
. j! E1 T/ l4 b1 a2 q9 L0 H, p
$ z T0 b6 Y3 [5 M1 i8 s5 a Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。" [8 z- ^3 x0 g/ _9 g
. {3 Y7 u7 v* ^5 x: @3 L+ R
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。$ r3 w! K9 D, h5 C
8 k; _7 Q' x5 E! @4 v
; t- t o2 t1 X5 |$ pReference，
6 d+ E2 F2 K; X2 o$ [. S' o) V. l# U8 q) Q% G
[0] Architectural Overview0 i0 F# I6 b; Z. W4 K' V
http://www.mongodb.org/display/DOCS/Sharding+Introduction
; H, R% ]7 b0 F3 e/ z |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
* l; G: r7 Z+ i, O8 z. { e