|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。9 @0 T9 H' [. w& H' u1 \
, p$ s! j4 x4 u* ~6 d p! ^6 \ 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
$ f' k" A+ p; G: Q2 }, N* ^/ o3 p/ t8 @/ ~: }6 h9 A! P9 z
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。# K9 m) ?9 z! [* U5 q4 d2 K
$ J Z+ J# W+ _/ |7 N# U: f
8 t. D9 y: {: s4 y- T
) ^ m" X! n; l; {: p. O
图1-1 MongoDB架构图
! a# Z2 i0 c0 k5 L9 F/ l7 D6 w7 q% M
( ]. c1 H. @8 ^0 u) A MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
' C+ C8 ~0 v r9 w5 T& t3 B
% u9 N# j" U+ L7 c& {4 eShards+ U8 r5 O& ]; @
# r$ q! R) c; W
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。4 w& L( B- }; h3 F7 w; S( q
+ r5 P) C- d( t7 S2 T8 s0 |3 M! g
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
$ G' x4 I, m6 C7 k- K
" V' l; W( q/ S5 Y3 Y" D, U4 K' c% p 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。5 ]! o1 m) b+ o4 h1 k5 J- t
: V& w) \8 ?* A 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。! b! ?4 M1 Q! B2 u8 W9 v/ m) A
& w! @1 b$ T* I$ T. ^( iShard keys
8 i& {2 H5 N5 }7 M $ e) @% g, q6 S4 ~2 q) b5 Y' [
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
0 Z; ^" i" s+ o1 ~, x1 q/ f5 f3 r* g- U5 \6 F0 k- e
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，# r7 J1 p* Y3 ~" K0 N% P. W: X9 G
; a% c! S+ E2 V& n4 W+ [: M{
; y3 B1 |/ V" ?; P v2 `* v* H8 w+ {3 K "ISBN": "987-30-3652-5130-82",8 _. I' e) R/ x# {4 u
"Type": "CD",# c Z# Y& P# u7 B* o* t
"Author": "Nirvana",
6 p( w3 f# M3 t8 t) s) z "Title": "Nevermind",) c$ T: B8 B3 z1 |% z
"Genre": "Grunge",! m( Q: k- Q3 \" m# b& f0 S) h
"Releasedate": "1991.09.24",& {2 e& {! g8 x
"Tracklist": [
- y. s" ^/ W5 F% ], k9 q {
4 P7 J* `% t: E6 f "Track" : "1",
7 K X9 G% Q+ b' U q) q "Title" : "Smells like teen spirit",
/ ?9 ]! o7 ?: f; `( g; H2 Y; _% ? "Length" : "5:02"
- B, j) e5 p; E" ~4 F4 R+ c },
, j% ~" W" P* l: W {
" w6 f! S6 Q; n9 s7 O0 p "Track" : "2",4 R2 D% r8 i' T8 U$ Q% T0 @5 Z
"Title" : "In Bloom",
/ z, n7 J1 `+ Q) a "Length" : "4:15"+ k6 n2 d, P) ~" ]
}$ u# T! _- ~$ J3 Y$ Z
]
+ h! [3 D7 k* r" W}
p% \9 a! `) a
: Z) k- [* r. I! [- }{
: h1 G. _8 b$ M7 m2 _: i "ISBN": "987-1-4302-3051-9",
9 z6 \8 G$ Z1 H" } "Type": "Book",
5 J- e/ y- {. n1 _# Z3 K/ ~' a5 q "Title": "Definite Guide to MongoDB: The NoSQL Database",8 H+ C; d0 \: e
"Publisher": "Apress",: }. G" t: s% ^- R4 H
"Author": " Eelco Plugge",. [! j& F6 @6 T/ z. Y3 _" P
"Releasedate": "2011.06.09"3 R. M! v5 |/ v( D- X
}
: K' Y0 e7 ?6 g5 c8 z( _" @& l0 g! P' h0 r
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。! w4 _+ o7 [, {, z" y. `
3 e% k. M0 N) b% x( {
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。+ C1 m2 _' A) `" ~6 [4 R0 E
- M% Q; S' f! B$ I- }) ]8 M8 L" \
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。' z$ x+ ?2 _, Q% ^- n
; }. Y, e. l$ t$ n& B$ X 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。- a( \ d( {' O$ y. G0 [
" B# e, M- K% X* C8 Q7 B% J; I 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。, V$ z8 t% Y' J Q
/ t4 M/ P+ g- x$ f% kChunks2 i1 Y h# ~( q! L
* l+ f% t z* U) Q MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
4 B9 \" B1 T( L; G
6 @4 n7 \" q4 i' Y' L
/ u N1 {8 ~; v0 r3 e. c+ I7 ]' }图1-2 chunk的三元组 ' N5 x7 c& B/ F3 S3 d2 E8 p
4 j3 }! x8 ^; y- r: i! a! k
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。/ j; }1 H! d" ~5 o2 k: p
# D6 f) N4 V% G) U* f' F: s8 k
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。% t8 C& S a& ^0 x
4 `3 T: n6 |$ S! s( q/ K% t2 m Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
8 ^8 E. F, R: h# q5 c/ X: K! w. ]: W: ^: Q$ I" T$ u
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
# S2 N( r/ N: }" z! c4 H. o7 g5 k! y) u d9 o
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。0 s4 N! o& K4 ~+ B
1 X. j- Q O5 t 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。1 B% j9 q+ H5 }
# B$ ]+ {+ O: Q+ H' n1 V4 x2 u, UReplica set. X/ D! g$ U2 q" G% T% Z
4 l! S3 h* `+ C 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
* Z- E1 B# C; M) \4 E& Q
) B. I; i7 e0 \ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
6 D$ Q& `: ^( r6 _% ^6 \, p
9 ?# w9 ]+ C- O& L3 k Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
( T; A/ s# B2 t' _- K( t: M K; n! e5 k7 j; f! N' G$ b! z5 q1 S
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
4 A8 ~9 r, d6 w' i1 Z" y% z$ X8 P" s% o5 i8 t3 v5 @& B
Config Server$ @9 M* v5 B& d* ~* O% e6 i
# Z2 @) t% L; P# \, y; L Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。/ f& [0 ^7 [: J7 N% l) _, u
' F2 ^7 ^& h9 o7 T0 M& K, {5 O/ V9 w
每一个config server都包括了MongoDB中所有chunk的信息。& I3 v& J+ L- z' w- q( n7 B
! l5 a% L. H% m/ `" C
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。% P4 ? ^ Z+ M0 ^! A- [0 M+ S
5 N7 T1 T( u9 C' h) g 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。! M6 O+ o; C& v# I) m* W
# E+ I% e g) z5 u
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
5 H; Q" q- r! `0 `! r7 C! k/ I8 o5 O
) S4 p3 [5 J# t: V B aMongos
2 ]" I* Y* h6 z- H8 t8 q2 I- s C- [. e7 w3 S$ b
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
0 Y- w2 U. |9 W, x! y3 z. D9 Z+ k1 t) V
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
& ~; ?) d+ Z% \5 Y; K' d" c' W; I# D- q
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。' Y0 y% q; v0 \9 g3 G& v/ ^5 [- S
& u% A7 ^2 s7 L6 t1 x
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。$ `5 f& S7 h; X* {- v: X
. P# o9 Z/ z: L0 A. A! `6 f9 y3 r
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。) U2 i+ \( H- x& t1 d6 I( y- j
; ^0 x u0 b* Q+ g/ F
$ u, [/ | L% V& X9 V! CReference，
' N. t8 o; b& @# d; [9 z4 R/ w. e* I1 Y, @8 q. T
[0] Architectural Overview" I$ R& Z* i0 u% K% P% N# K
http://www.mongodb.org/display/DOCS/Sharding+Introduction
4 Q- E, x* K" M8 Q% i7 C |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
$ U6 k0 i* P1 a3 |" O9 }