|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。, h, D* O) u9 b! s7 P
- j3 F) T" J; f( O( R; p
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
5 O+ b& v/ r+ I% K+ l- o W2 H A$ E& c. Z0 [" {( \% v4 v
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
( F W% T2 |0 q, I. y% E/ f1 \& o$ L, t# H+ n2 S
8 N; N6 f- S/ d/ w3 D0 d
5 N; P, T- K9 c图1-1 MongoDB架构图 & [" s) G# ^2 A% _
0 b5 g# X, u# a. R MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
4 X& J+ y- |* n+ R- f7 a3 N. b
7 @( V7 ]8 @3 F4 J; k) Z% v! ~Shards
6 `7 h; Q: D+ G1 ?4 w) k
1 z/ A/ x( q5 W MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
* x8 Y. t1 T9 L8 r/ m1 k
' U3 n, ~$ [$ }8 @$ b! N Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
# ]" i2 b) Q: ^1 C4 c- f" ]5 R- O' J2 B% S2 J% Y
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。) G* [# E+ s: r% v( k2 @
8 B5 g% ~, _& t* N/ D
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
. C( q0 o7 G) z9 U4 L3 @6 T9 G: D& a) u2 q
Shard keys
" v- J0 N$ s4 O, l8 w
; V. f! _' m/ V m" Q+ _+ @6 q" N 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。; ^1 n+ z( Z: L, A1 l1 I ]5 U
6 N5 {& C- a2 n, B 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
6 C, h }+ g ~# `& l; t7 b% u0 r0 e0 I' W& {
{
2 o# j6 Z; m/ S. Q. e "ISBN": "987-30-3652-5130-82",
2 y6 p- t' F, V3 T "Type": "CD",% K7 c* h$ G; R8 p. G8 @( _
"Author": "Nirvana",
6 q' z+ H" D% o. [* ^ "Title": "Nevermind",
2 N; y# j9 ~; P+ l8 M "Genre": "Grunge",5 r0 o+ S; P, H; X6 Q: U6 A
"Releasedate": "1991.09.24",( w- ] N/ K! \6 p5 f [7 G
"Tracklist": [; I2 h) o3 d- K0 M5 t$ {0 {
{
/ H6 u5 k0 ]1 g8 [ "Track" : "1",
" D/ S! X9 X2 W0 t "Title" : "Smells like teen spirit",) x0 O2 ~" M+ z
"Length" : "5:02"
* f, F& T6 D) O6 i6 v) ]& ^" V+ Z },
7 ^2 J _& A3 `2 O% @" S {) G; Y+ \) i6 f R6 T \# f: g, D
"Track" : "2",
3 o/ P/ i! M5 l1 ]- P "Title" : "In Bloom",
6 P4 W; }! O- N+ o+ o: O; I "Length" : "4:15"
2 E1 M6 K: C: Y4 K, q2 \, l }, e2 L( ^8 w( j$ |3 M
]* n- d$ [1 _) B* o7 j M, K* l
}' v' N. _( x# G- O
0 L" L W9 b; x* }- g4 j, y( {4 Q$ R
{; l& A. B$ r+ |% v5 n" k" C
"ISBN": "987-1-4302-3051-9",
, E# Z" _8 G; u3 q "Type": "Book",2 o! L- A& W. E8 j8 D5 J2 L9 ?
"Title": "Definite Guide to MongoDB: The NoSQL Database",
+ N2 Y& I. Z$ S6 R8 j, F9 x+ | "Publisher": "Apress",* Z9 o& |$ V( x+ l9 J c
"Author": " Eelco Plugge",
5 _- ~5 U9 {. s, \# V "Releasedate": "2011.06.09"
8 f" f) H( |5 Z$ q4 W}
- |4 q W7 E- R! R" Z4 V
* x. h6 G+ f) C2 O) l, \' Y 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
& r% v* J; m! A& [* R/ U9 }
% r( D% O; h U8 n" g0 u 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
9 L' f& t! f; N v& j" o/ D$ Y9 ^1 G' Y& m7 U \
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。$ p$ L9 X- P5 z) j* k3 J4 e' V
! K1 D% ^' }& k7 Z7 Z9 d% r, F 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
/ O5 n# X" J+ x3 S
9 {, w) _, E! ^$ j 延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
( X# Y8 y1 r7 C0 P4 N# w
; |( [! z0 \4 r) g* h2 T' }8 T- iChunks' o2 x& i5 q- ?' J+ ?
q( x* p9 x) `3 t# B5 h
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。- h- m" O$ H# F
% G8 A- C) |0 V; ]9 G
, H' R A$ |6 H H5 C1 F" V
图1-2 chunk的三元组
- C! \. _5 n3 j, n) A4 e9 L- g/ F; p4 h2 @$ E8 \
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。9 w: C0 `) _ C& ?' E# h$ C
3 P; |/ b9 N# O; H9 x
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
6 y! V! p D: f1 ]/ L/ H; H/ y3 u6 e3 Y, s$ E! O: h7 w. |/ b. R
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
' ~& u- O- U( K
- c n4 W1 z, p9 {7 w3 o* o( l 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。* B) h9 D$ x( d* _$ x9 w% r
; |9 G. V" A( }- \- n 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
, p/ j# _; f3 k
* Z& B' ]& v& \* z) j. ] 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
5 u; X3 e8 c$ T6 ^% i. h
0 i! o" A/ \& N7 E7 C9 dReplica set3 E. j6 i8 F5 |6 e! r
9 v, j" `- b1 A$ f
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。) t2 O( Z1 z$ n& A
9 d1 c* p7 r" c2 x 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
4 J1 s& r7 Z# x' i, T
0 z5 d& v6 \3 w. W- r" Z Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
# W4 F6 ^ t) e: |0 B
3 S( u* E3 U( r! b% {% q) j+ P v, S Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。2 |0 H4 W. ^& t& ~% `( q$ R( o
% {2 s9 N. J) C, k# F, [Config Server
# k$ y m5 B: ^) Z 1 ^' ^- F& q5 E) q Q1 O
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。! G7 U: X2 ~% S. T
, b- v+ o3 j! j4 @ 每一个config server都包括了MongoDB中所有chunk的信息。
8 o5 N4 v) j/ n* G7 x4 U- y7 [5 c7 l+ A% Q* M2 j. F% O
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
$ T6 Y* k* {2 }' N) o9 a: B0 L% O, W1 n. ~2 d+ ?/ c9 k9 S
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
- E' V4 t3 a; P
5 Y( u1 J R9 } MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
, n9 |+ I. e1 e1 z) v" n) Q! C5 t1 e+ }
Mongos
. P' V- i; w9 I3 V4 |1 p
% p" [7 i( p2 M3 B& \ 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。( _4 E! |6 [0 ?
$ T- M" |$ ^2 O' r" X s8 A1 R5 N 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。6 a; S( | P7 V! w6 [
9 E" |; D- x2 c% Z Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
! z. F* T0 u( J3 _$ X& |7 [3 O+ V" X1 e* y. c5 x. U l
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。% _+ U8 q& N! N- U/ p. d' g
$ t! G g0 }, T( c0 P; y2 {
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。/ V) h( {! O3 S: C+ K
" y7 F% n, y/ r* c8 K( c: M7 ^4 g M. j% Z8 a
Reference，! ?: V3 H0 k) d5 _- {6 o5 ]# Y% P
2 t% Q; r2 W. x: h7 ^[0] Architectural Overview
2 Z5 h; O+ T* J9 c9 Thttp://www.mongodb.org/display/DOCS/Sharding+Introduction
0 B/ @* m) U. z2 W; B Y: N; d }& e |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
