|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。# W4 [8 V5 G; {3 }, x
! z$ U6 n! j* p7 q1 O( v0 x6 _ 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？9 U2 R8 E) g$ D, i1 s
, m0 D2 h) t- H0 K0 _ 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
. Y: Q& Q& q* q- m3 @
+ s! E R# x/ ]
/ ^* x+ V6 L* `, A$ S
9 j, j' L, y# Z图1-1 MongoDB架构图
& H- @9 t& R. L: Y+ @; Q, U/ b6 l& g
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。" {, b1 }' T4 x t
' t6 i' H* D0 e( Q [Shards( h9 u0 Z; Z& v9 R$ S6 c: u
' M" i2 M& H& \) q MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。* _' ?% b2 \, O) q- D1 E
I6 V2 a) w) F& c4 ~ Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。, |% k3 ?1 Y, M5 c* y5 u3 [
, ?# J) Q+ ~* E0 S5 L
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。1 Y& }# r. F/ ~& t* k
- C) p2 N0 w a 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
' R: U: P" k% E% i
; S! Y6 Q% T$ Z. E2 p/ t8 AShard keys
- a. A$ j; w: n5 Q" Q6 k + w6 j3 j1 X/ n; t! |
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。" s# A5 S% C3 j% G' |
1 {1 Q' L% q( _$ L% H8 y9 }4 D+ c% o
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，) E. Z3 |* ?8 W, |1 q
0 P9 t% k' G) L3 x2 V1 M) d" b{
3 a; f) i* W; O. } "ISBN": "987-30-3652-5130-82",& W/ @3 M# d3 `% {! _" o
"Type": "CD",& B" x$ t' y. R% W+ ^5 t' b
"Author": "Nirvana",- [' a) l8 ~- C% I4 J5 Q9 I( W5 D
"Title": "Nevermind",
* l6 T% l W+ X0 S) R "Genre": "Grunge"," ^) h- c( ~4 l1 }" v$ j0 k: V- k7 `
"Releasedate": "1991.09.24",; b0 q8 P4 V' M/ Y& D- ^
"Tracklist": [1 T' B) _/ O$ }; x: U, [
{% l7 r$ {" q) ^8 `* j% O& d
"Track" : "1",: K- h3 w, ]2 |& |
"Title" : "Smells like teen spirit",) ]' ?5 `" `4 S3 T
"Length" : "5:02"
; i3 w2 i& m2 W* q6 I9 U },
% L; x V0 ]' c% E* S {7 f, S# @$ P& C/ l) ~$ }
"Track" : "2",
0 M3 C4 l# `+ F* U "Title" : "In Bloom",$ j6 Y, Q. p6 t3 @" {
"Length" : "4:15"9 I# S$ a* `. S% P$ f6 s8 Q
}
- |* W5 v* w Y& [6 ^! H ]" Y3 u) ]8 l' o1 D& g' w2 }5 G' Y; H
}
: d' Y2 q8 y0 r7 `, A1 }
1 P+ H0 O5 q* w" a{% P* I7 [" V/ u
"ISBN": "987-1-4302-3051-9",
1 D" z! N% v$ s6 k9 M; g* u "Type": "Book",
! q8 o8 I @- \. z5 m' y "Title": "Definite Guide to MongoDB: The NoSQL Database",
; Z" o* g( N1 j2 |- D* { "Publisher": "Apress",8 L# t# ~4 J# x; ]) W1 c1 r B
"Author": " Eelco Plugge",( v! E0 S, u! S9 {9 {+ F% P
"Releasedate": "2011.06.09"" m* D2 a, V2 z1 g$ T# r: y/ R8 ^
}
) L1 z# s: I( B- N U" x8 S, X, [9 A$ ^" @8 q+ h% m1 a2 Z# [
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。+ ]# J3 D" T* m1 ^ g
3 u1 Y: X1 K- b+ ?: ~ 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
! c, h3 i3 J( \
. R! Y' A2 o, @0 J% V' N; x* t2 } 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
" [/ F- C2 R7 Q0 z0 z2 F: O: I- I$ [( ]4 m u& G' L( B
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。% K& _8 g: B3 e+ k6 H, d( i# O- ^" A2 L
; X0 L5 ^% c3 f0 j 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。0 L9 s9 ]% C) Y5 m* p
. O1 z) g5 `4 O7 l! t0 H+ R1 C( ^Chunks
1 C7 h C+ a, D5 k$ t
# ~, o' R) t* A Y MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
+ `# G" X7 `! S* ~$ c! J: D
/ Y5 Q W7 n; P" A
1 N2 }+ a* C+ ^! w+ t* o) u$ w图1-2 chunk的三元组 9 i2 s6 {, j9 x+ t
0 x" I X# N4 U7 _* Y C 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
# B4 k2 ]* H" J C, ~' Z3 X/ U- v/ k+ q$ [3 W) c1 }
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。1 h7 i" m# |( x/ f* y+ s z
. v0 L$ j3 O' X \ Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
" h6 X1 `* `0 O- u$ C1 O2 M6 v( l4 ?; l F9 B5 E: @: l
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
% V+ j2 _6 X& I( y7 c: m
2 o s6 ?- R, r5 ~9 V2 i, c* f 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。2 q" K0 d1 `- `# A2 x& Z
0 C# g; D& ]+ U4 V 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
/ N7 u; D! [4 T$ \
' i8 x0 |, R7 D' NReplica set
3 N8 J+ F2 q) Y: T5 f
8 L2 K) u( |7 x* T8 I 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。6 y: s& p& B$ f; A
+ m L2 q/ K3 f* j6 A6 r 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
$ u% i$ M. A$ S/ w
: _. o6 a; Q6 B, y W7 T2 w d Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。7 w4 I* N( x# s0 F/ `
1 R. o+ W0 |% y* \5 p. u5 U$ ^& x9 n
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
* i/ D2 [; u ?! Y: \# G" W, D) u# r5 ?' a& V. a
Config Server9 U& S0 L( y) _, J
5 i8 E" Q/ f1 O1 J5 O( |5 b: C [ Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。8 p5 b! V9 U1 g4 q
. ?7 s' |$ K. `: {
每一个config server都包括了MongoDB中所有chunk的信息。
; z8 Z5 f N& K' O% y& q- e# a' B7 s
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。- x7 Q( c: v4 X' s
& \) n7 `# t: e1 z5 w4 \
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。% a. f" P+ a2 p x
0 U3 e7 M+ g) S1 ^+ K MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。; {" U- ]( \, z( R, X& k7 S
/ K* G8 D8 x- M+ o( q6 y, g B' G2 dMongos0 C. A! j( w P# f/ j; x
* T3 F0 ~8 T2 d7 S7 B 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
% j$ W9 x' A: }, Q$ C5 s( `- U: f# r3 H/ _* W
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。, h) [- X+ A1 ?2 _4 ?+ G( w
, E; {: m* W- Z' c Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。" n1 P' F( n6 z: l9 D" _* h5 E" b
6 D: O1 s, k/ K6 r% [7 o
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。6 ?, n, p- l* V+ M+ `
" @4 y) ~) X: f7 a. c 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。& n/ H' g0 [% i6 X
& y4 F* p. j1 n7 @
7 w( @$ T* @3 q. K% \
Reference，: ?$ Q M+ j* K
* z' ~' F) A. ^- k; K[0] Architectural Overview; e+ \; A) f R# j: V' M Q8 c) }0 J
http://www.mongodb.org/display/DOCS/Sharding+Introduction
( `; f$ K Y& J; b2 A$ j |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
