|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
8 ]3 R P! S4 [0 q( L! z0 y8 I+ i1 U6 K9 [+ G$ {" G
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？1 u K% P5 x x J
! B2 f$ K* ^+ ]( R: N+ O* } 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
4 v) H; i$ ?; J! R7 ]
- P3 I$ Z' u2 |# t5 k) y
' |' o5 u# N4 C
5 d9 Q# S$ S8 T图1-1 MongoDB架构图
3 e% {% ?$ ]+ c
+ Q; h6 G" |7 Z3 K8 W MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。* a- Z6 V$ }/ G3 R
3 `) i6 y0 e0 C* _$ x1 x; G
Shards
. n5 K. `9 g0 }4 h( _" o- _: c: N9 A! C* {5 G9 z9 o
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
. T* _7 J9 c N' L, a) B& P
* e; [3 G; p* h7 A5 E" ] Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
4 |' K, ^" m% }" S- z9 a4 o( z, n0 [8 B/ s& P5 w
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。% L( m2 E# r) P; e' D+ c# }
; C" ?! `; Z6 e, y0 _8 i 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。% k; M$ e' `5 _* q
& m# B! _( v: G& C _Shard keys7 q+ P! H6 m' w! h0 I, b
: d6 b% c" o) y/ ~+ F* W 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。( C+ o8 h4 [" e1 G4 e# r8 |
8 W1 C( C: U; x0 _3 a) p3 w) ]
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
% H* l0 \3 }3 a
4 v. o; l( l, k& w{8 A+ C& D0 ~: ^
"ISBN": "987-30-3652-5130-82",
" t6 d2 A* a3 {# _3 U "Type": "CD",
7 d5 o& P6 m# \ "Author": "Nirvana",
4 d1 b6 |1 v8 C: `! ^& S "Title": "Nevermind",
' y% S9 [1 {% v) q "Genre": "Grunge",
/ g* ?- @6 F3 g N' c* ~& [ "Releasedate": "1991.09.24",' u5 M- y( o8 I
"Tracklist": [; [2 U/ G' Z( V7 N# f& Y T
{# u& i5 w& W1 @* ?) a& Q
"Track" : "1",
4 R6 y( B' x2 _( E3 C4 W9 `" _ "Title" : "Smells like teen spirit",
9 _+ ~: R8 n8 m "Length" : "5:02"
5 q5 {9 f- b7 h+ Q" o( C1 S },' M [" w3 q' Y2 F7 K& O3 [: h6 q
{
, [9 Q! S9 H+ A; q "Track" : "2",
! f- M* a) q/ r$ D) x/ c" c7 B% F "Title" : "In Bloom",
$ t* ?5 E4 Q# J2 E4 A3 j) ]: d2 x+ O "Length" : "4:15"
6 C- t H: E7 Q! r }' Q; N9 _2 X Q: Q, a, b* m( y
]* V* ^/ [+ H* E/ J/ R( z
}
+ V. J( R% K3 z) Q& s% N( I# E9 i- W" h) r! ^% F4 Z8 h
{7 a% Y6 p$ s; C8 f
"ISBN": "987-1-4302-3051-9",
0 u" f; D5 A5 d- w& q+ E8 E1 x "Type": "Book",/ g, o5 B" ^) Q* }% M) O; j
"Title": "Definite Guide to MongoDB: The NoSQL Database",
6 [* t& U8 h- _' }" Y "Publisher": "Apress",2 O$ n# f( K4 s+ ~; @
"Author": " Eelco Plugge",
7 {" S1 c# G; w& {* }* g "Releasedate": "2011.06.09"$ @+ t, a: f7 I! b% e1 c* y$ p. d
}
6 `. ?4 e2 v6 \( P5 d% m% D* v! H+ A* j
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
8 n; G5 h$ S; P6 P3 k _# l' w% d U$ t& P }
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
/ n8 o3 ~, S; a% T" V- W& a" K5 `- Q' R& u2 |! q
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。 d- U0 J( F/ P4 m# ~. ~; F
- {- d! S9 y. h" ]4 p
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。& n% ^8 `# {" X/ \
' T9 ^ X. M9 U; m. h 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
* p* w$ d4 f: R! @1 L% \4 Z7 }5 H- f% u3 F; {# @, G \, {% ?
Chunks
; M* g! E: t- ^4 a8 C% N
; X/ W a) m9 w, F6 o$ l- D: q MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
, K' J$ g/ g S: N3 i% A7 Y2 j5 f6 P7 A. n% y- ~* N5 ]# [# A, L
8 H. }% U% n$ O6 w图1-2 chunk的三元组
' h/ O0 ~% v8 E% M {: ^* B4 n5 X) U/ V) k# V5 y: A& G0 k3 A
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
8 g4 l8 G7 N) R1 E, E
% N$ @: Y6 L$ E) n( r0 R; N8 M, I 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。9 D( z% J* A- h; _6 [
0 v4 |" b, U* n! b* H Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
7 W: Z* [4 Y- v' b6 t0 ?7 `, A% r( ^9 w+ w& }1 S- \& X
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
D0 y- j$ a- ^$ A2 {. P0 i2 L7 m) x
5 ]& O. N' ?% |) h 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。! u" g) f5 ]$ t T) t0 u, [
! G2 ^6 i' j+ j 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
. \; Q+ W) ]8 t4 a* G. F! C
; C X3 A! d! Y. O' \9 |Replica set' [/ A& ]$ @% Y, R
3 S* e4 L1 x; y, n
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。! P0 `) w6 }9 g
& N, C, k# b9 f0 |
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。5 Y6 A i. ], Q8 M+ j6 f5 C* P( t5 V
! Z* R/ _9 T! z) _ Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
, b# m4 ^4 Z1 N3 y/ K F7 H, Y$ d9 H9 r: @; R3 e; ]
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。7 R' m: P l2 B6 u/ _! D
' Q6 \) m$ i$ P- a8 z; o7 [% f* p
Config Server
% W7 J% S8 e) J' g' w
. G# _1 r3 }) P! K7 ~ Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
N. T s6 K' N( k: A
, x3 S" H' H& e) ` 每一个config server都包括了MongoDB中所有chunk的信息。# n. Z, X0 D+ L F& t" W& f( p
5 P8 @# F7 g4 w. `# M Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
6 _) G- a3 X) C! [9 T- V; n7 u2 |7 L) Z, }
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
% a/ b1 ~+ H& q+ M" [7 `2 E1 g' ~7 u9 d( M$ M' G
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
% @, b# ~0 n- }4 o4 B5 B2 s! x0 K Y! l5 P! O! [$ ~9 k
Mongos
3 a0 ?8 s# N$ d) c! e+ a9 ~/ }* @4 Y2 q7 ~* x# b) x: G% h- _/ q
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
' i( u5 @2 ` t
: C. I; u/ a2 ` 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。( e6 ?% P( I% n) l b) j d
. r- B; `1 n- M; m; V
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。6 \; S: s. I! \1 M+ [6 H ^, h% F
- @- h3 \" C/ h$ t7 f, m& z" p8 I1 X) u
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。8 T! `: l$ |* i! H7 E$ B2 c5 B
+ _# K8 Y/ p. v 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。7 n/ S- U. ^: U) L) ?5 {
2 ]& a. y4 v d8 i& `" ?
) w1 n/ Y1 X2 wReference，
: }. I- m+ b3 v; t1 L+ K2 @. r# N* N8 F& s
[0] Architectural Overview% |6 B4 g* k8 X% H! M3 j( {
http://www.mongodb.org/display/DOCS/Sharding+Introduction; Q( p6 K3 j8 f, D6 H
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
