|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。6 Y F' X: p, E: o1 I' x
0 i7 S' z( K" e6 t5 E+ |% l
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
; e5 ?2 d' Z5 T6 x0 D% |
! ^# A3 B5 I2 w |6 r4 S4 ^ 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
6 D |3 X' y: X5 R W2 C; ?, r6 ]7 v: Q
7 S' [) C/ ~& `1 @
9 g0 ~- Y# B6 B# {4 O* e图1-1 MongoDB架构图
8 {3 A( l( E6 }. M0 l" t- }9 c) G, Y/ ]1 \! k0 z9 b3 w- j
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
- Z2 Q/ F, }) T1 E7 ]4 W1 K# r. a
$ g9 m( g) z$ M3 y B' ^Shards7 S1 z3 U. x. j: f; j
0 F" n2 E2 [% L! @- ^9 E- t9 t
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
" j. V7 n/ L; r" z7 ?
6 l* A- |) M3 g5 X$ L' B* @5 E/ J' I" o4 a Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。2 p& U3 }% t$ R/ f6 [1 ^
0 i$ ^0 Z3 x* r$ S 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。& ^( [. n4 r0 V% t8 |) @* I7 h
0 m& S% A' {% t. F* J R
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。& k! Y0 H( b, J8 n: Y, `4 {
& b9 @$ Z& r, D6 G2 E! ^; x9 JShard keys- G% i( `" Z* P' i$ P
; c. C4 s! g8 [5 `) `
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
: w3 M: Y0 Z9 q" b. q6 p
* X, l: Q0 T* T$ L# V 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
$ ~1 b, [1 B+ h) \$ L, k
: T0 C& d9 Q. a9 F{
2 j' r" F7 R, d) X7 D$ g% l( E4 J "ISBN": "987-30-3652-5130-82",2 c! U( c; y: N" L% _$ y0 A, O; I
"Type": "CD",4 a2 i4 T6 `$ V- Y' M2 L, I4 C
"Author": "Nirvana",
) U1 F b4 D( y2 X$ w# I "Title": "Nevermind",1 v- n1 ~/ b: V8 `3 ~- l3 N! H; r( o
"Genre": "Grunge",6 J6 E/ f0 Z* o& P. ]' m
"Releasedate": "1991.09.24",) ?- t; v0 P' M& ]- }
"Tracklist": [
4 M' E7 D. I) @% Z0 C% Y {4 U o6 T! x( i* o2 Z- @% J3 u1 p
"Track" : "1",
- W$ ^ {% x2 g0 {9 F "Title" : "Smells like teen spirit",1 J% T3 p1 \1 O
"Length" : "5:02"
2 w; E4 N% Y: ?1 e },
, Z) i' \1 l& u1 @' S* O [ {7 p3 n+ \% Z% ~- W
"Track" : "2",: ~: {9 W/ Q6 H. c: x$ x
"Title" : "In Bloom",( K* X5 P6 V$ \" ?) e% |; {) f5 N
"Length" : "4:15"
- |' F z, B* X B }
; y8 ?' ]: q) i7 ~ ]: @, Z& ]5 K* B& `4 R% L$ `! U! Q4 n
}* e6 Q& P3 O' h
- f$ |: d: g7 i. [4 `
{
) N: Y7 ~5 p" y& r" } "ISBN": "987-1-4302-3051-9",
; ?/ t' ~+ j9 I5 w: O" i* d) V "Type": "Book",
. Z% E' @1 \# H3 Q0 [! R "Title": "Definite Guide to MongoDB: The NoSQL Database",
! Z* q: a+ t% F3 a( e "Publisher": "Apress",
4 X. h/ f4 l, F, C4 J "Author": " Eelco Plugge",* B& m/ p3 Q7 ]$ S$ S, I
"Releasedate": "2011.06.09"
& O; B. t" L4 K2 J f4 @}/ @7 ^+ o: n1 U( \
1 R$ J5 @6 W/ t9 \2 H0 w6 R8 [
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。) O- ?& g7 \ u8 V b. E, U+ `
3 ~$ L$ S1 }4 K0 Q 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。% H, O- p) k+ n* j
- b# W$ D. B# E* H& G0 r, ~ 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
. m$ R% J0 P5 f: c
4 h0 x/ y( J' C 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。5 c% V1 M8 T* f# u- f3 O* L y
' s. O+ U$ g2 z _
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。 }8 P4 T" a' {. F6 x/ ]2 V& Y
9 Z1 `( {' M9 g* n' ?Chunks# r9 k8 M/ b4 y0 ^/ ~! P7 m# h, r
2 i- j- [4 g4 K) b# X4 v* G MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
& e3 d$ u) } g* ~# p2 }# r/ t) m1 x. l9 Y
8 ]7 `! ^; r6 l2 M5 F/ l' m图1-2 chunk的三元组 3 A& ]+ o8 d6 Y& q6 B0 l
+ A7 Y# x* R& Y" }( A* Z6 }( d* T
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。0 H" s0 w o4 B
1 s# Q% n4 E; T0 q' k- P' F# v 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。% x; g9 v, z8 p, ?0 x
% n* v0 u9 a" p Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
% N) {$ S2 k& Z# t! T0 M9 U+ V; W/ S# r$ s3 X: b. b$ k Q
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。% x0 u$ q# T" S5 R- ^
$ m" t J3 u( U
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。; W$ q+ I4 i# G/ u% G
~2 V. z% n9 Y: M
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
6 I' L1 s, I5 `3 }* k: f$ \. S0 ?9 i7 l. O
Replica set$ r$ x3 z$ I3 t$ v+ u' N; f/ T ~: N
& E5 ]: V2 E8 f, J% V+ } 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。' i# _ p z8 F" U s2 L
( t" x' M5 H# B2 ]# b 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。6 T" V% ?4 a% L( W+ L1 l% x( K
/ D/ f8 y9 C q/ H6 u Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
) S$ M& ? ]7 q1 W
1 D# U' s2 q8 ^5 S, I Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。. w9 \: S1 R8 x: T3 D+ r. u
( S) n( d5 k8 g5 P) O: c, `Config Server1 `, y& }2 E2 e) r7 m$ g
) T& g7 i9 F, `1 c' X7 {3 I8 j
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。. Q7 v: [ c! Y, A
4 Q. Q/ f/ \# C 每一个config server都包括了MongoDB中所有chunk的信息。
) |$ S! s1 S |; d$ O$ |4 l: L- N J* `6 W
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。) e7 i7 a) u/ R& t( c; c( P; E Y
, D4 [0 \$ f# Y! K
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。$ ?( h1 \" A% g
- v2 N# F+ d: V$ O1 [ MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
( ?5 T- N/ d1 |1 ~
0 E! k! H' l6 f& c& ?Mongos
. Y( y3 H' S/ p0 F0 J8 Q& Y- N- \$ ~" x4 M) u) P
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。' t1 b: x4 `3 `( A& k7 w% F
; c0 B* a, r0 X- R/ T0 @. t
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。9 |6 z; i7 X# I7 I: n/ U8 {
' K1 G3 I) i% c. ` Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
) b" F t( ?2 p0 Z6 m X" f2 r0 G1 Q/ W! N0 I0 B
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
_3 U% R( V4 v+ L1 t) L; k
- z4 S8 M, n/ s7 P 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。, S' q" l- [, u( G' h: {
+ {7 J. Z1 a8 N- G: d2 o* b
8 U3 j6 `$ i0 o+ z8 D8 gReference，
% n. |/ i- E1 u6 x$ Q. J- m \+ k- {: \/ C
[0] Architectural Overview
* K* m9 r7 Q/ A% T: Zhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
: I, R% X+ y4 c4 s; C8 F' j$ A |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
- C9 H+ H! F" Y