|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
* z- W$ P7 x* A
. o; ?+ _: o$ l. ]$ H 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
# x& N+ a: j) C* ]
) E+ c6 r' h5 {8 x# g: K- | 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
. Q& @0 {* _( T, a- t0 U4 K' _- C% [3 l0 a
8 x. R& r5 N r" H3 M
?, z3 P2 V% M- B5 `图1-1 MongoDB架构图 7 J2 L7 n, ?9 J# E
" G7 M2 z, n1 ?* q MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
; m: ]( k7 i; x+ I2 t n" Q& x' n) v: X* A
Shards
1 A# A% p# E3 B7 _7 ^8 J6 g/ j/ q1 L5 o
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
$ T. y, c K/ J) k- a# e
7 V5 O9 j0 M9 I/ q Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。4 d) g+ W3 |1 |
7 ]. X2 d) g% L' j 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
7 S" p- B, s4 `3 [! x6 x+ y& l' j/ [/ X
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
7 q8 f& t. @% s# `$ p3 Q
4 |9 y! K. e7 n% j9 \. g2 HShard keys4 h8 J1 ~5 a: B) C5 [
) j' L5 V% e, e- ]
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
1 s- Y1 `& k9 {
2 ?* }0 l: w, F7 u3 u& [ 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，7 {" w6 [$ H# a" o: y! Q* C
- ~. m7 I& `* d4 Z0 H, v9 F{7 D0 B7 H, e8 Q X
"ISBN": "987-30-3652-5130-82",
7 v) l5 I( ^& D' A( H2 B5 D "Type": "CD",0 m2 J. N8 {" A% k
"Author": "Nirvana",
& a2 c# h1 r4 C4 X" R5 ?+ k3 L8 Z "Title": "Nevermind",
/ j7 w ^ f1 @$ b% C+ a8 l& T6 o "Genre": "Grunge",& m$ |4 K0 K) Q/ D9 n( S1 N
"Releasedate": "1991.09.24",
2 u7 C1 Q; w. q7 j "Tracklist": [; \, q/ A' `9 u. g6 Z D' y
{
5 K: X8 u+ m% b$ i' L, ] "Track" : "1",
2 i! ?: x- j/ s( E/ W- t "Title" : "Smells like teen spirit",
9 [; P$ R) N7 Q) o2 ^5 X# D "Length" : "5:02"; [$ r' y: N2 l# ^
},' t2 @, S$ q, G+ U
{
! h0 S4 ~; _/ A: t Y* l "Track" : "2",
) v8 p' ^2 l/ Z2 \* j' L "Title" : "In Bloom",
% E6 f8 K! u% z2 | "Length" : "4:15"
' c% Y! ~4 R% O9 \9 S }
0 _! M6 E: c# ^& _- ?& N& c$ V ]) p7 g6 C( G7 J1 Z- f0 f& y
}
9 v! m ^+ v# v
( d- ^& D' {7 ?7 C$ D1 j{
7 Z7 T& g* r- a+ w6 F: f "ISBN": "987-1-4302-3051-9",
" i! F2 N% j. {, C- r "Type": "Book",, z9 ^. h- m( f+ m! Z k( Y
"Title": "Definite Guide to MongoDB: The NoSQL Database",. Y0 ^0 u" k3 _
"Publisher": "Apress",4 Q$ z. T; S9 r! x9 {
"Author": " Eelco Plugge",( Q9 R. R! \6 o2 K% i+ K
"Releasedate": "2011.06.09"
X8 I: l0 `0 b" h% E}
; t, p( d4 M2 m) k
% E5 v! I6 t h. O# P 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
; D4 b& B) f7 s! s. |. R, A9 X
' p4 L6 |9 y( G: x: B+ U 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
* y; x5 r0 F4 K3 h' m6 f0 \7 L1 R( j9 x! |" ]2 _& E6 h* k
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
; q- d+ ]0 `5 m3 a( M3 w
# X9 A2 d) |2 }9 q1 ] 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
3 o* P7 \0 g% v ]! M0 a" w- [
2 U! [' l% L8 {2 N: } 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
3 }: {- ^6 v8 x$ A5 c4 t# n; f% j2 F0 s
Chunks
' V0 U% s7 |+ Y1 h! c' _5 u $ `) d$ S" g2 `
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。4 B# [* P! k# m) X* s9 D. i
2 J, o8 S9 }/ t; N/ k1 E
; Z6 S: Q# {5 q3 \7 w" P
图1-2 chunk的三元组
. ] {' F! ?& R' m4 t
0 g0 S) x1 Z! S" c: z+ T( o 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
. d* Y6 S8 ]" p. ]! b1 l8 W
" k# K- ?1 s6 `2 f# s* D 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。* T# b, E( F1 H d% k/ ]
~8 e. }# ^7 M9 |) ]! n A- H' a' J: { Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
4 B2 H, y6 H$ W& C5 s _* \- C: @
0 Y$ W2 L5 j- Z9 I4 Z- y, M B: V 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。. Y* z; r9 {' T @4 w H
5 `0 a+ l: ~! s, ? L- }3 S 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。. L* h9 h* d1 p, @' J+ z: I; G
% @5 q* z# P/ q( J) a) q
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
/ c) g2 g1 Q' _/ Y' o
1 E# ?/ v2 r) N1 iReplica set
- x3 A( c2 \- U- ~0 n: h 8 h0 ?8 r' z3 U+ i
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
* `, u7 D7 U; e1 \/ b2 U9 L/ G7 e* P! b
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
0 V z9 u9 X$ f5 U H
/ M7 c* F2 t3 t) c% Y6 h: C Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
/ p; W+ A8 { q; J6 s; u, |
$ |2 {/ e6 V d. y Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。. d- u0 B# `* G P3 g' E, s
- S: Q! s6 G$ q5 y+ |Config Server$ e: e: }/ l* @+ Q
+ m8 B5 u' |$ `, i# |/ e" u
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。% ] n6 N0 h- T4 b! G6 i$ C" i
+ O; E3 Y4 w9 Y
每一个config server都包括了MongoDB中所有chunk的信息。3 |7 b% R! ]! R9 O
U2 d" ^9 M/ U$ [' X% s4 j, O Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。, N3 H& X9 v" i1 m H0 c8 d
! _; k& `" P- v0 Y; l4 n 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
$ K6 L$ |9 w. ^$ S! Z: X2 o
/ Q3 ]! ^1 r r. s MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
4 ^$ Q, o3 d1 \. ]* V6 V* h8 y7 o: W) {9 }+ x( n, C& q* V$ h
Mongos6 [' B$ w, |9 M& Q# V# P* B
; \1 p9 h' m4 ^8 a" f5 \& Y! i
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。/ M: O7 u8 e1 P1 O$ B* Q
9 M2 h% S* ~& P 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
. `. f0 H/ s8 S3 _9 c# N* P# E( }0 h1 D- s( L
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。$ |/ q1 d, C& u) L5 x3 V: q
% b% z' V0 O& g1 ^# o6 i$ r) s$ }
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
* n! R; E. t& K. ?* v2 x+ d# ~$ i
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
$ m+ J- x3 j: u; C, G8 w2 `; R
b: A: z9 u" G6 g9 ]2 P; ?$ V' k# E; s4 r2 ?+ S; M# ?
Reference，
; X, t) r. n* |& ] j p) n5 G1 q6 L% T* d% D$ t, z4 t% }$ j$ Q
[0] Architectural Overview
' A. N, A) c- A8 t9 u3 ]: Ihttp://www.mongodb.org/display/DOCS/Sharding+Introduction
6 w, V1 y9 G/ W: I, }) ~8 D. O |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
+ N# e! P! Y {: V$ |( U