|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。" D: W/ s. l0 ^+ }/ [1 y
! s9 |1 {: A+ X
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
w, M2 S! S+ x1 O
0 g! @1 ?8 k+ I 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。+ U N! D8 k( F" S. [# q m
7 x' a. x, ?6 l d
1 R0 M! W4 r6 L9 D7 p' S& `& j; G# s, K
图1-1 MongoDB架构图
y8 Q M' ~2 i+ H R- j/ [, N, s9 q2 Q9 w9 [; x; f' u; k1 S
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
+ h, G6 {; P+ n" C: w' K( L) e$ a7 R$ l9 |- Z4 B! W
Shards* ^% c3 S& Y! `
, S+ W. B" u* U. _+ [1 E3 d Q MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。" j( V$ o' Q8 X
$ Y( m8 k) y: q0 t3 C Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
4 t z' H3 ~/ }, _
' v: Z* @& B9 D7 g/ G1 j# w$ E2 b k 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。: [$ E7 _+ L) t. ?5 H
. a' }5 a% O9 N1 u/ s& W5 @ 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
. @$ l/ M, o v+ G# Y `, Z! r5 H- F! u; w) p$ N5 z
Shard keys& V$ \ w9 ~) k4 h
% `* r. K. ?! X$ P
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。0 W. k9 [* q" A! {$ q! c5 p4 u, A
8 x6 J' \2 Y6 c6 Q; Q 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，! K1 ]6 w& G6 P# p( Z' j, u
- z1 @1 w8 ?/ h) @7 i. _$ K{
6 k9 e/ d& f6 a! w "ISBN": "987-30-3652-5130-82",
# s( X7 U5 \# a9 W$ v4 @ "Type": "CD",
3 S7 J6 f' p2 O0 _& p "Author": "Nirvana",- N% l+ Y& B1 s% Y$ a) g, k
"Title": "Nevermind",
5 J, ~: \2 M& K1 K& v "Genre": "Grunge",; X$ M6 S! b3 Y5 q$ Y. C/ ] ~* d
"Releasedate": "1991.09.24",
n. B( ?) |+ w* p4 j "Tracklist": [
& @5 u) A2 o. K" p {
/ L. k+ G: R+ W4 c9 ~/ j "Track" : "1",
* C1 W4 y: i$ X! P" }7 S4 J, }4 W8 U "Title" : "Smells like teen spirit",5 B `5 _: y$ E
"Length" : "5:02"
4 O e* v- W+ W1 C& H },3 J+ ^' L9 a) v
{
4 v/ i9 J) r% ]: k) w2 C "Track" : "2",
9 x& I s8 w G. B5 O3 ]6 l+ |0 P "Title" : "In Bloom",
% c: Q( H; y }" z1 `* d6 F' I- m9 H "Length" : "4:15"
. b- H+ R3 q) E* }" m q }# i5 {4 B1 m' u$ C; ], s
]+ t2 Y; I4 j) w( h: x" I6 C
}
0 z' T+ W# t; w+ Z L- R- |: V0 s! W1 r- G
{: H1 m: o: c" w5 d
"ISBN": "987-1-4302-3051-9",
( a3 ~" a& H6 }! J "Type": "Book",, ~+ l S5 n& q l7 p8 o" ~: X
"Title": "Definite Guide to MongoDB: The NoSQL Database",* Z9 o- ?$ t, N5 v
"Publisher": "Apress",/ @/ {2 H* \2 A. a& X
"Author": " Eelco Plugge",
5 m# ~$ i5 U% }& p4 ] ?) M: ?4 Y "Releasedate": "2011.06.09"
# y" K7 a2 G7 O5 ?. b}
4 ?' {" r" }- S8 ~, Z$ Z+ S0 i7 s% N% a. q8 b1 y$ X
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
; }# j, V0 @7 E, P z( m! w8 U% N1 u: _, j& {
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
6 y. K1 F- e; C7 t, Y! _" E( n
8 ]% i v- ~2 n2 C 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
! n2 d. R4 j' ^, u; z& n1 g! X2 W* u" d: U1 b7 Q7 x
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
. w f B1 l% ]$ ?0 X* @$ _) g3 G. B* d) V" w1 s
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。- x; `2 I! d" g3 k; j* z) M7 R4 O
1 [; F2 t" g" \4 {Chunks) Q. U$ V3 K' h. A. q8 I
1 G1 f/ m) C9 L* d3 V
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
/ }3 X! v2 F5 ~5 i/ q/ V, p% `1 b% M! Q; o3 `
, T) e( T3 a! J& P' ^& B图1-2 chunk的三元组
% [8 a- ~1 E2 _7 V' C
# y; G+ P9 o1 o 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
+ _* Q ?1 Q7 ?! c& R9 P* W
2 H, b8 X' T, W7 e8 X 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
2 `& k# e8 k6 |6 S1 E) H- ]" @
3 O2 h6 @; o6 g. t# b; K Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
1 b% I2 `4 h) v0 J" H6 I4 Y/ B8 j3 A, z! N" w' F+ p% y; j# ]/ c) G
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。" V; B8 ~" X& ]* b! C8 n; }
6 L' o* F; ]! w0 [$ U9 | 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
1 O4 d, L3 V" K2 V! j. B0 @0 V d& n* ?2 {7 A+ E
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
1 G+ s+ d- [7 f' L% q& T; y' v
; V& ?) ^1 P# w fReplica set/ v {+ C: W' U% E
: Y( b6 T9 }3 P/ j
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。# q. y9 [2 h; q7 J9 q+ I! B
/ c6 P9 v: N7 y, l+ m
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。0 g& M+ w5 G; g2 i- ?
6 }% r" N0 q" ]3 R8 E, T6 u
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。3 r+ e; o' O# X/ i, {8 C" u$ k3 `
/ f: A9 ?1 n3 t! M1 B; o5 V) q8 c" L Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。7 C7 V& e5 i, K7 o0 }
3 f d, m8 H6 [( g, C
Config Server$ F3 o1 p4 |7 R! J" i3 J6 S( I# \
0 a* c2 i' h( b+ g( h Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
' ~0 Q7 p O( W2 t n2 n
8 ^2 Q0 _' f& h: w1 c8 A 每一个config server都包括了MongoDB中所有chunk的信息。
0 D% Q: n5 Z- U; e- M
+ \2 d, N) Y/ h% }. C' Y. b Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
. A* L: }, @- \! ~6 j2 z7 T3 h- ]: @
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
: S o! X! Y1 o3 s$ s% c# ]2 ~% L' E9 |: v. C
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
9 U& Y C- P% y: H4 U \/ Y0 F; R( i, d1 c; X+ f6 y
Mongos- }, M" t( L/ k! G/ x) }
! d& X7 ?1 y' c1 E 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
: r( M0 X1 \; |. l* p
& O& y0 U1 o! F9 Q; i, W" q 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。% a7 G P) }" X* Q" J' F ^
+ J4 A5 C- D, t1 c% u- \
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。/ G6 Q: s" Q1 ?$ l
5 w" x% M7 _9 ^ Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
# X: C* V$ I/ } f h/ ?3 W- U4 Z+ t3 v7 w$ I) i9 e
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。- v2 w. x# d# k T
0 B1 p0 `" O) u9 m$ q/ \: d
. ?* P7 e3 w* ]1 _
Reference，
7 y# f0 b7 ]6 I1 j, N6 b9 a' U( y8 b; T* H) v% V0 d
[0] Architectural Overview
1 q; [! {; s9 b4 |' |+ i+ ]$ l1 @http://www.mongodb.org/display/DOCS/Sharding+Introduction
6 |7 g: I9 T# ~6 j0 Y' E" o |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
# \" J6 j% \ b6 x; w" t1 p