|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。8 D* n; c7 a! g Y. L
0 M- P' }1 Q0 I: \- l. D+ V1 ?
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？- g {# z, X7 x
! t" c$ h4 M- ?& w9 X8 ?! w& G
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。5 j$ C# e D2 K, F* S
$ V C$ i- {) I9 |
+ W( G# |3 j2 }. S9 x Q3 z n4 j
) m7 ]1 N0 c/ b; T& m2 I图1-1 MongoDB架构图
8 H" Z3 T$ `0 J% C
0 j5 A* U1 E, T MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。2 V6 t' R: X' K9 T
" [. I* A6 J- \' _
Shards5 e& K( m. j) |4 p6 {5 }
4 ~1 D- U9 l, V% ^* L$ A( O6 O | MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
4 }! y& S3 G4 D% |( i; V" g b
7 }8 u6 P4 C, u) u' B/ U D Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
" Y9 ^( p9 {' @& @, h3 J) p
1 ? W& O* h. X6 v 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。& I* A W' b% T7 Z" _2 ?% ?* N
7 s& s, ~, L/ t9 d9 C 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
' |1 K1 b" K( V O+ b1 }1 X. k# s9 q1 g5 Y# s5 V4 ]7 R9 W
Shard keys
2 W! i) @: h6 V- ^4 F( M
4 L8 x3 o' g2 H 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
- Q: O+ @$ V* O D
) {4 V v2 n+ \, M8 C 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，# V5 @& _, n0 f1 x0 t
* J7 r5 a3 C+ G9 X; Y" T5 X
{
1 R3 L: z! |9 } W5 _% R0 L "ISBN": "987-30-3652-5130-82",
. J; P* }4 M- h% f) J9 `( } "Type": "CD",
: h! a' y: T" s; a/ O "Author": "Nirvana",: u1 @9 b& b- L2 t' l. L3 w
"Title": "Nevermind",8 t: v$ G# x: n; }9 J$ B
"Genre": "Grunge",
8 g" M, c# X! q B "Releasedate": "1991.09.24",
! a3 N4 G- {. L9 d4 A! P2 A! m "Tracklist": [
2 s2 e2 n8 b' p7 p; @4 d5 h& N+ k {# ?% w+ J. ]5 A* Q, j) e. r% C
"Track" : "1",
3 v4 h0 d: n7 O3 ^ "Title" : "Smells like teen spirit",
( U4 h& [" M$ D; [ "Length" : "5:02"$ K( |- j4 F4 y* @ ]- H
},
' ^# A! e' T. U" Y9 u {% x r7 h. c' q) Q- T+ c
"Track" : "2",) \9 J4 f1 M7 h. }
"Title" : "In Bloom",9 ]* T/ q, r/ I7 N0 Q% ~8 O
"Length" : "4:15"2 ]: N( j, b0 u$ j0 p
}
. `$ U# I! I' p; X+ M ]1 u- u0 l ]+ C1 o! E
}
/ |! Q6 |+ z' h6 A" p: t' N5 U! T) g+ j: e1 g" _. N2 y4 v
{7 Q1 }2 B ], ?" n' K
"ISBN": "987-1-4302-3051-9",
* t9 c; f1 d/ s: U Z "Type": "Book",
" L+ P1 @: U9 Z% M "Title": "Definite Guide to MongoDB: The NoSQL Database",0 d; Q" }, ^- U
"Publisher": "Apress",
8 {# g+ I2 {. R# |9 G "Author": " Eelco Plugge",4 z8 E n& h5 g! e) o% J3 L
"Releasedate": "2011.06.09"0 J! H, m! W- O$ Q5 }$ R
}
# V/ M! G# o1 m/ y0 P- B7 j7 d7 L8 i9 s6 L$ M7 l
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。; U9 B: f1 \0 \+ h& t- Y# A+ s0 F/ X
* S$ p* I6 U" ]5 O 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
* P' r/ D; c) I' R, l$ ~: i' O* p. d
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
. R7 I( s4 I. c6 o% ^: l1 _% @, [3 D R5 d( y9 f9 z
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
! W3 Y' E: A; C. H8 r, a0 ?' `! I: j) ]9 q' F3 M
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。' `: j1 I, ~/ }0 Q* D7 i+ [& ]$ S: \
3 W5 I8 {0 D! x- ?( R
Chunks
' c0 |0 [; ^" h& q, R
2 V# o! K3 G' l0 v/ ~3 ~2 x* Q MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。" f" C% E2 [ @) x8 s4 k5 V
: f0 e( f1 [; h/ R" W5 g
$ | \8 Q8 n. D
图1-2 chunk的三元组 9 C6 a. L, c9 g( b% ^! p
5 |1 P/ `, K+ }$ o5 E
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。4 a+ S2 Q2 h9 _* G( X7 J( ?
' j) L- _$ w; ]# H' q
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
' R" k! m- f( s: ]
2 u& N5 M( ^* j8 n# I Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。 M7 X$ b I4 U
' a) j( N/ ?1 z- S6 H8 V0 W 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
# B$ q, Z" X7 v7 _$ E
3 L4 A% v& @2 y 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。7 k% Q, E: \: e+ Z8 _% Q
8 `$ U4 H4 u# O$ `, J 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
. ^3 X8 Y! J( I( k, V& T. e
5 _! @* x' K PReplica set
2 s8 w* I) H; f0 ]! h& m
: J! T- X: j8 n2 D$ a" i9 @ 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
& a/ r2 V" k* V/ B( F0 l* |0 m( E- p
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
, _. ?' T( I1 t. c2 v' O" Y1 W% ]: A- O; `
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
6 A7 ?9 J, x0 Y" a! y u$ Y. d9 z; d2 L+ V- L# `
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。3 J, Z# [* Z2 C
$ W) S3 n% F. D7 v% m. S
Config Server
2 z& o& x0 o w" _5 y# ?
2 S F$ E4 G$ u Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
- J m8 [# y" E3 D. x$ f4 ~* P3 ^+ p/ W2 q' V4 l
每一个config server都包括了MongoDB中所有chunk的信息。+ t8 n+ k+ R% e: R6 O( x2 `9 ?& k
{) W- k( z& v7 v
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
5 |7 {" J$ |. } F/ q+ m% a4 O$ P/ g1 ?% |: N e$ V
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
& w6 ]4 S# J1 J; I- ^9 l! B7 U6 C0 @
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。 H% b5 d1 x H4 |! Q. k
$ |4 y8 L! ^& j3 jMongos. M( @0 T: _$ b0 n
6 k! M: z' z x) t) l2 s0 E- g" {
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
' P! l6 G& c$ E$ m* L
* n$ V2 G5 x1 y4 C$ G 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
8 h2 G. B- y6 S
, `, F5 J& ^$ v$ \ Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。0 W9 ^8 U9 I2 [2 l6 X" P5 J
; O; u& i2 D) C! O. ^ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。' X/ |1 g( p: s# `: f+ ^4 h' V
z1 S) M& M! Y. q8 z$ ?& d( M 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
& H! o0 _& {- K$ j
, @0 m- ?$ X# \ [% F% u! c( A* m; g6 x& r2 f5 C* ^7 D
Reference，
& E: [& e, X: |4 t$ Z- G( s: \, U5 {! _6 @+ u1 Q" l" w
[0] Architectural Overview
5 O# @2 h8 x$ c, b/ K4 F5 G& Thttp://www.mongodb.org/display/DOCS/Sharding+Introduction( L" d1 P: X' w$ v
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
) h7 h N& y& d; y& K- j1 k