|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。; Z% C1 f( h7 r* M d
$ U) P5 y A3 F0 d 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？# w% n, |/ n0 ~6 j
2 H$ D7 N3 m/ R: I/ W _* h
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。, S8 J% F& ~+ t2 z h
& Y( g |/ a7 l, n
' A; v( O9 A; e1 F$ }
; l& ~9 Q5 p$ F% O, ]$ _% X) R+ K
图1-1 MongoDB架构图
' J6 u1 ?. \2 T/ [, n
3 v8 P# F) i4 r6 h3 t, y MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。: G) O* u$ s; R N0 P# Y0 J
) S: t/ }- @6 U* f* b
Shards
# j8 t3 v# U7 S9 u# {
+ p% [+ t3 T! P3 T3 I$ w& X8 x MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。; _4 m$ W I j3 O8 ?
2 F$ }+ P' R- I6 d+ ]1 |; r2 b Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
) Q+ [* C4 M- ] Q
# i- n1 K5 |' B7 i; X* A v 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
1 o* S4 r( N7 `; m6 k+ _$ W8 U' [# q6 f. o8 |
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
, Q l( M: }& [; k# c t+ n# a& e1 o
Shard keys" Z* ~' l* C+ ^2 U; ~' ^
* n5 @2 s% R6 A$ o
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。9 Y3 o& E% H+ i/ U8 S1 L
8 x' I9 h( q' p
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，/ G# R9 y; e1 @5 ^6 C
5 S; y; f1 ?1 ?$ }9 d- e{3 ], _6 a. n Y$ [" @) a5 Z+ z
"ISBN": "987-30-3652-5130-82",! T! A6 ?: T7 a2 F
"Type": "CD",
5 f6 U+ n9 C& M/ k: z. \6 O" \5 E "Author": "Nirvana",
2 K6 f, j% r5 z/ ]0 k; v "Title": "Nevermind",
/ S+ l3 C" X, [2 e "Genre": "Grunge",
1 s: P l" k) E+ `$ e. h8 x6 V% ^ "Releasedate": "1991.09.24",
7 G" B8 i% C( U( i! ^8 y "Tracklist": [0 T& G8 |9 Y" T; }: Z2 U' H! Y8 f1 S
{ n) t% C) R$ F
"Track" : "1",
7 n1 m' k! p4 }9 @3 g0 V "Title" : "Smells like teen spirit",
- R9 _3 \& {6 N( c$ V+ E "Length" : "5:02"% [! A9 w! F O; l. ?/ C
}, \0 T# @3 P3 G5 i
{2 D& m: e5 W8 X5 f2 n
"Track" : "2",
% j! g3 @* M ]( U "Title" : "In Bloom",
- D6 Q, V# G+ y- q: W "Length" : "4:15"2 E L' j: m5 f* b& \/ R- h7 }
}1 `8 O3 T5 d# Q- r
]
; E/ b: z0 g6 r8 @2 V* ^" v4 r}- j( `) B$ ~3 K- g" ]: [9 D. |
$ p. g6 y7 {3 v6 {
{* |8 e- y3 L1 G m
"ISBN": "987-1-4302-3051-9",
3 a6 E* ~$ ^7 a) H2 X; G "Type": "Book",
1 g: T6 C' W! E7 S8 b1 E "Title": "Definite Guide to MongoDB: The NoSQL Database"," n3 K3 g4 K9 [/ e
"Publisher": "Apress",+ ~" i+ t& c2 D) v) e; Y
"Author": " Eelco Plugge",- E; e0 |+ n% n) l/ S0 u
"Releasedate": "2011.06.09"
* B% f! q _' b% U}
: n& p }! {1 Q2 P
9 b+ |2 ?9 g7 m- M 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
& R( M6 t" N; f5 d. s8 _4 X" i3 t, P b' x! p1 N; j6 K
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
( V, d. z9 ~7 L3 w0 B
% x t W" ?; O' x( [! l* c3 i 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
6 g& n9 u; m9 w( w. v' _9 H! T% [' b. r" o, {% m7 y1 s- V
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
& b% ?% {5 U2 |8 w) M: ^0 ]$ ^, T
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。/ G' ?# n; ]1 Q! W5 k. v
8 o/ w; y! u2 w! h0 BChunks
7 r7 ?3 x3 Z# V5 x# j% x4 Y4 b1 W
9 f; h. k6 \5 ?6 v5 f6 c( U1 a MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。; o4 o, L/ @ n' q1 {7 ] `# P
1 C7 `( ?) Z& N+ D% F
; U$ l) N- t; f1 o S2 O& s
图1-2 chunk的三元组 # ~2 C: \' h0 W( F/ B" h
2 D# O' _% ~# a; f0 X. q3 y' t
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。, e- t# {$ [; c% x$ @) Z6 J
1 t+ u3 g) R- L2 z
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
6 U4 J7 V0 [) g7 m: K. n+ U( l0 h' C" t! J! S5 l
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。! I: s+ ^/ Y% x
T; J/ l! B" A7 X0 h: o# r 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。3 P8 \ f6 {5 v3 }" f& N6 N$ Q
1 Z5 O1 A2 A* d4 @' v) z! P6 f 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。. I8 \$ Y4 W: D1 B
! n0 M" d: @ `" u; _3 }, c+ R 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
9 U, _( e: e: [2 }" \! R/ S9 X0 M2 A9 m; C
Replica set4 I Z4 E, p6 t( @ t9 G, ~
4 p: A" B6 e) c: }% Q) i7 F3 S
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。5 O9 O. f6 b' [& [) s% |
( o& p1 k6 s* l+ r' e 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
: C: D' E" V% V" ~; ]9 O2 \3 ]) ?2 U) U7 V! p
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
p5 M# i2 p2 F) F' j- y
$ R4 N' `4 y. ~ z4 D4 n Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
1 F. s& a C$ S3 y& s2 u; W: t( H; D9 e! a
Config Server1 O9 q6 F, p; `
" I7 `# g1 x0 z, n! I, \
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
% G' W- U5 s$ @( D7 e9 H; T! _$ J+ b
每一个config server都包括了MongoDB中所有chunk的信息。, d! C, M4 t* j% T3 r. v
$ a7 \% C d, a/ N% x# t4 B
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
* \1 r# v9 h- e: b# t( Q( T+ ~2 n- e
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
5 K" P4 A7 h b% W; h1 [! q( H \6 p$ P# C7 Y& J
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。& B* m& S2 M8 v0 b. Q! a
- ^" h' _5 D9 O/ m, U1 @; Z
Mongos* }6 b! Y3 \ u" G/ w! d; ~, A
3 a1 z) ]$ J4 U
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
0 ]3 T) b4 Q0 S6 f7 Q3 d c
! v' U) |, H# X6 c( a5 X 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
; E% O0 U- }# x3 j5 h* x# j3 K! f8 A$ ]0 M0 C
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。5 u6 X3 C3 o5 Z! A) I
+ Z- D2 c8 Q# S" s
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
' y( A4 a* u, p# T6 t7 ^% T& j
5 u" a! u4 W) w! i# n: _ 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
" U1 p1 u: n8 g' G1 W/ X. r5 n
; U# H' n, { d; Z, A
1 F6 r3 s- p6 k! {' [. _Reference，: T# l* M$ F5 q* Z9 |* z
7 t* Y4 v6 A1 Q& [8 P9 ?5 \[0] Architectural Overview
4 l4 K+ U/ Z! `$ ~# ~, Qhttp://www.mongodb.org/display/DOCS/Sharding+Introduction5 b$ L" }$ N6 @# v$ L
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
