|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
# @/ H. u$ }- ~) l4 y
! n# F0 c% w# t0 ]6 j( p 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
7 G/ c! {- |7 @
' Y: X# z( P! P& [, _& i 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
+ c# x8 _+ y8 l/ f: g& _# E* a' u9 m3 W2 _5 c7 v: T
# K' a7 Y0 c# W v. L& V$ y: Q
. k' L3 c4 {3 j4 P! z图1-1 MongoDB架构图 . }1 J+ _' B9 t$ K2 A% D) j
: m6 \( r+ C& g" C& e H9 [
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
$ `1 |6 N' n4 J( A* w
# w. P I( Z7 v1 F$ A, aShards
Y3 ?6 t2 C3 u
9 e& X" G U6 h7 \' y MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
# X! ?5 S& w, u. c* h: Z* {2 |/ a0 Z
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。& Q, p# F' s3 v# ]1 I
& _; f+ ]8 i: C2 F 每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。) {" e& _5 \* t" l4 n& W
) g3 m2 y" {+ L, o8 w9 R5 Y9 b" g 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。2 g2 w0 \6 q; V# ~% M+ U
0 J7 X3 L: k* ^# k1 U
Shard keys
1 E$ r9 w; O2 F8 h
" ^/ E7 G. u3 e- M8 T9 d, E 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
( E+ d: a v0 R3 g4 X* s$ P# m/ B D9 y+ T9 ^7 L# s( E
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
7 I8 T Z0 w! H9 g' K' d7 K* U; s3 P# k& O
{
8 S8 h9 w6 X9 c9 ] k "ISBN": "987-30-3652-5130-82",2 ^6 P. _4 d6 {6 i4 R4 u% J
"Type": "CD",$ M7 r# W6 c6 h
"Author": "Nirvana",
4 q3 Y- [7 A/ N: r+ f5 { "Title": "Nevermind", v/ T/ ]. M5 \; E8 F
"Genre": "Grunge",& m L3 K) p# \: J
"Releasedate": "1991.09.24",- x2 _2 f0 W' \" L: G' B
"Tracklist": [1 g( j! \, Q% q% h8 c1 J
{
+ B2 Q! A( j( h& q "Track" : "1",
: A; A# u+ L; e+ `% ~. H" J "Title" : "Smells like teen spirit",
9 Y/ e' T! f& n3 B( N3 Y5 N3 a "Length" : "5:02"
' Y6 U: c7 h/ e' z },; \& Y q. e8 f
{
" k& [& S9 P3 z "Track" : "2",
- Q7 f& {. f$ u8 S% h "Title" : "In Bloom",' Z8 m' G) H* [# [
"Length" : "4:15"8 X+ l+ B. W; L$ ~1 y& e
}
v6 A4 s: l+ J5 y! H) g* x/ ^ ]: x, o# C2 Q, A* N D+ x
}- g, M a+ s- d* j3 T5 w
' @5 @) u& I! G. ^0 y{& ]2 j/ Q- k( c9 E7 k" z: Y
"ISBN": "987-1-4302-3051-9",% a \- E( c1 e+ U" s) E4 C& x: h
"Type": "Book",5 V: y4 t2 G' o: {
"Title": "Definite Guide to MongoDB: The NoSQL Database",- l2 u! x( z A" v8 @5 C
"Publisher": "Apress",* i9 p$ S2 ]4 {! `, _
"Author": " Eelco Plugge",
: V% z* m2 p% y, D8 W "Releasedate": "2011.06.09" ]& ?1 h& a" c7 ]3 D5 p, I
}
8 [7 o, }% N1 b0 M6 Q, ~$ s5 s+ f& o. w" j/ C- c
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。% l! H9 K: K: M; A/ ^
/ B( E0 J' b( f" S1 y1 R- A
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。, Y L6 R/ v O' x ~6 Z* A
' M% i9 b9 V% u% p- Z0 z
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
" [$ w0 i, g5 l# T5 g% c+ n. |$ G a1 a
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。+ ~9 A' l% E7 |8 P
, I t# R9 @( O. p. T8 N
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
1 |" z0 Q5 \, K) I
0 b7 g0 ^% Y9 }& G- E2 BChunks0 O3 J- e) z3 u2 p
% i1 A! I6 I% v
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。, w, x7 O! ]/ b$ x; [ z
6 ~7 X% G* v( C, K r
( ]# B4 Q6 b: b3 P" ^2 [6 G& z图1-2 chunk的三元组 2 o) c- B4 V- }
) o) p. P2 F. f# x6 c* B: h
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。$ i3 W" A! x- X; Y3 K, w8 t0 L/ b4 X
W1 b7 f( A/ _% N8 e 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。( L! O c3 T1 c. z9 n0 z7 ` W
) M/ F9 k5 U4 f5 W5 u2 n* X Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。1 g2 C5 Q, Y9 U8 e2 I
- x3 s5 r0 T8 W% W8 ^# j$ |
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。 D0 k/ \" y6 F1 P& N3 j+ g
, O3 S5 Z* r' B* p. r
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
' j/ e4 w2 N' ]2 Z+ R
) U4 e8 N" G) b3 x U3 M7 P. t 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。. B( f7 B# ~6 M3 U* u" z9 \
9 d6 _" T6 }8 A; }% U0 RReplica set
$ q! ~" N* ^8 j* c2 _% @. t) Q0 z ) P8 l0 ]" h; l i
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。2 ^* @3 P' ^* B) R* E" J, G' e
3 R' q1 w, H. N1 T3 [ 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
6 D1 q U' B: @
' a5 }' ?; V5 |' f# o Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
6 m: }5 q. ]' ?% }9 D6 p
+ h# W* U4 A: l: w" ~; E# r+ {- R$ r' J Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。9 x& @) z; }/ o
7 n! l* A2 q5 m' |# j
Config Server8 R: }1 A: m8 ]( e7 \. n
# E7 h! c: I% M) Z4 i1 g
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。" N1 O, G( P7 r: G
I4 \0 k: g7 y+ i 每一个config server都包括了MongoDB中所有chunk的信息。' |9 {9 c' N& f
6 Q. X R. k: g. ?# D+ E: Z Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
2 o. X7 ^ q9 @( k+ l) A
0 V; }5 u$ c" B+ S! g 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
6 e6 T2 r& ~& \) W8 B2 y* A x, v2 G3 x7 Q
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
6 k2 @3 }! ^9 C: x. S
# X5 h8 n( i1 O1 B* P, f) UMongos
2 M& O! H* m& }# J0 o7 D' q5 @5 l. Z& G1 Y) U$ k
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。% k# P4 _' D5 n8 q+ p
6 n9 O: P9 ?$ `
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。, n3 n# K4 G0 K! a0 m
) c8 z: P7 J8 m) c. I3 e8 ]. g3 Y Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。4 ~1 k& v) y, }2 r& q4 ~* d
7 ] w G. {# I) X A: R Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。3 i; [0 \+ M3 j
6 l$ _2 K% E* H3 r' k8 y! p 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。: T6 L& ^$ y' N/ O# G
9 I' m% t7 H3 [& l' n6 o
; ~3 ]/ D& `1 L" V, B4 x, o( V
Reference，
5 ]! c6 ]3 r3 w$ P, ~
4 D# d) M; B+ O[0] Architectural Overview
1 t) U- X% @ N& U% L. shttp://www.mongodb.org/display/DOCS/Sharding+Introduction
" m! Z) }4 R5 b" A3 h i) @( c |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
% y' G/ r2 T# W$ Q* P) a6 R' p