|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
! F7 ~/ \* A g# ~9 w8 ]: J. S. \" O: ? Y' L( G
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？5 k7 B6 c% h% f+ ]
5 O& ~) _8 a# j. K9 Y3 A$ B) t 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
3 b, i% E- Y8 n0 n5 N' ]
1 j# Y3 k8 n: Q- ~
, w. m( B6 c9 a8 I% B L5 u
# Q* u. E9 }% G4 N% q9 x0 i图1-1 MongoDB架构图 6 |/ Q, F* c( p) h, y8 X- F
4 ~! [8 ~4 v) @& m& e& z
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。! x8 @9 ?: e. Y: E1 c
, C0 [; @% `& F8 w+ f7 F5 R. ~Shards0 }4 y9 f1 r$ j$ k0 z! X8 ^3 f1 I. v
g2 f# D$ s- X6 D0 B
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
" o# ]1 l6 V8 ^& Y6 M, k
: n, v( B# N9 p( p Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。7 P6 _' Q1 _; ?/ z. p6 c
& r! K& O; P% j( Z8 o
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
+ N* L, S/ f0 {$ [. f( o: m4 \# ^, U: h: I6 ]( {, g2 `! d( `
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
- S$ L- F+ w. y! z; w5 L
5 Z+ z7 @) {1 W3 B DShard keys
2 T) O3 X D; z! ?1 G# C / o( w) ^2 }# U; ]
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
2 q: A9 B: \# {7 p& b7 Z! a. H8 D# K; [* u' D9 L( e
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
, v+ k. C( e2 u3 Y7 l
( w D! \' ~$ U4 \{- h6 o ]* v; @3 l# L* h, L
"ISBN": "987-30-3652-5130-82",
& |' d2 B- n' G$ s+ |. S0 l2 B "Type": "CD",
% R' G2 m3 q+ n' i1 P "Author": "Nirvana",: Y2 \! ~4 H8 d5 B$ m; D0 n
"Title": "Nevermind",# K& u! n; d9 @; s* X
"Genre": "Grunge",3 y5 F& c8 g; m7 u. I& F
"Releasedate": "1991.09.24",
3 e" {6 |$ J+ m" {$ O "Tracklist": [7 O& M' y, J; z+ O% z: p+ q
{8 M7 U2 x: R9 z( |( n! {
"Track" : "1",
+ p/ \* [, e1 K! K "Title" : "Smells like teen spirit",
; a" a: q4 d" t) [9 @ b5 B "Length" : "5:02"
6 N; @2 ?% k2 s/ b7 {3 U }, _: ]* q6 Z+ T) _ |7 B7 v
{
2 O6 B0 n G7 [. w" p4 s "Track" : "2",% F) S" P" z$ T1 m1 U4 Q
"Title" : "In Bloom",$ c x; j8 p. s) F9 a5 J
"Length" : "4:15"
- |* w3 w0 g! W4 p( P) _ }
' o; t$ P4 R( u( x& s: C ]0 R9 y1 l4 j. W0 g. J
}% T, U. H$ K) a3 W3 _
: F: p+ A( L9 G2 s9 `: e2 }0 [( W
{
" u3 H' s& j0 z& P) n8 { "ISBN": "987-1-4302-3051-9",
$ ^. j4 o# ^, z7 \ "Type": "Book",) ~0 c s2 z+ I( N$ V8 w& Q& m+ ~
"Title": "Definite Guide to MongoDB: The NoSQL Database",
5 `" ~( w; f! d4 N: ]* Z0 A "Publisher": "Apress",
6 V: v& Z% d( Z: Q( R "Author": " Eelco Plugge",
% _ i. K. ^6 W( J "Releasedate": "2011.06.09"3 n. v* M' c; ~% i4 Y! ~5 Q
}2 Q4 S- ^ ~: H' n( |
# @% q; [- {9 i# @% ^5 a9 m: D0 m 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
9 V9 N, X- I; @" w- C- T# ^7 T( {/ `$ P% _8 Q
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
( [3 o' r" H5 F0 f% S& |
2 T9 F+ I. B) {2 B/ V 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。 ]! r2 ~- Z7 I |4 k0 R) N$ V. Q
0 A* u2 ^7 X2 C 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
, A6 u/ T. o4 x5 W) h. T" i# \; G" C* Q! h) e v
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
2 P( x6 q. n9 C, t* k5 n% }7 B$ N- b& L% V- A+ Z v
Chunks
) M: U4 W& v: K8 ]% e% L
' V( D$ n9 y) z5 x; \: j: u MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
. H; G+ j/ M. x. l7 ?" u3 M+ s% S0 D
) o) c- E8 ]( z0 Z- y! f2 ~( b
图1-2 chunk的三元组
2 b; F! B' Q: y! L |, N; @ S0 [. z; A- H f
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
2 |# ^& C* l3 L- ^5 @
5 {9 v7 X, z1 f" k1 i 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。5 q. ]/ ~' O" V6 I% k* O* D# H# w
5 f! i! H/ a5 b6 E
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。; |* |% |; L; d( f% F. G4 E) D i; \$ E
* R, ^5 J; n# c0 a3 C/ @" A 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
3 j& @) Y; N2 h* g% l# {
7 W: G, i( ~) j$ R 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。2 i7 r' N8 E2 u7 C1 J) v2 r
* |$ {# I3 n7 }7 h5 A# r V
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。" h# } u. s0 S1 T
. f7 d) B) y* {6 x6 x5 n% c3 bReplica set$ Y) V% D* J, }# Y! D# m2 G/ X9 _
, Z1 J8 U) u. D1 s; _ 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。1 O/ T3 e; n9 F& N4 T
9 {3 V% s7 o& y! [ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
! Q H' N" v: d
1 ?/ j9 x' @3 R% z& z4 r) K9 g Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
$ c- X0 K) @, V T/ x7 s) J
/ m+ b8 \7 Z Q6 d Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。7 B G' k2 W: n
( n) a# n( n- Y
Config Server
# h! m# ?- G) T, f* z0 F$ I & v s. y* S# U& F
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
2 B& ?: Z1 d" Z4 ^
' v- l& [0 d5 A [- [2 O9 } 每一个config server都包括了MongoDB中所有chunk的信息。. n) F H- }! t
8 | u9 W5 W! E1 O4 X; [& v+ ?/ ` o Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
& h4 a9 [) Q! [6 O. n% t4 b! L5 ^! D
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
6 s% V; G; S: O! l- l
% J, {+ Q0 O+ n! d$ ^& Q MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。) C" B; a7 L( h8 b7 U
8 H0 @" [; m, B5 }+ ~
Mongos
& e7 o$ D, S; H+ i% ~% K5 x
& j! n3 c3 E" l% U9 f 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。; {% w. @+ F$ a% |) ~% q# H
, \2 V2 k* Z2 @. T, S 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
5 z6 G1 [/ B, ~7 K+ A8 ~- F, j R: p2 y5 R
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
$ J' X5 J8 T0 z' [2 t* P2 T' Q* n; g! X1 A" A9 I# k7 E! k7 U
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
; M' |+ X5 [9 ~& Q3 m4 q. t5 O& T% Z
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
6 S. V; ~2 m- a# W
# k* ?' y- F3 c' d3 \4 w, C( f- g9 e: y
Reference，6 H! z3 i: _ V1 B8 P3 A
3 I* K/ L- f: {! R+ A( H
[0] Architectural Overview* ?# w M2 [1 H( I+ Q+ W0 t4 z c
http://www.mongodb.org/display/DOCS/Sharding+Introduction
/ q* u* @. E$ O |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
