|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
$ j6 Z# X& g: ?( M# ^; e0 l: Y6 s+ r! z$ ~
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
6 w; ~5 B5 p. l1 ]) [# @' r7 L0 ~& W
# N0 ]# Q" A+ X r 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。# g* J$ P) E4 Y4 A
" V2 T# x ?8 p% |% u
# t1 k5 o l- O8 h, M( }; |# O; A6 ^; r# S* @
图1-1 MongoDB架构图 / m( B) ^& s3 V1 P$ r+ G: L0 \
" G& M, P' J, t+ [/ v, o MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
4 \. @- u9 L3 y$ S6 W, z+ i6 C5 j. v! }5 m& D9 l& G9 h' t
Shards" Z/ H' S4 W) E6 z
- C( b" |; j% T; N6 R) H) ?) [
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。, y) a: O! ^# s# p' r# @" N. O5 A: r! m
$ ^9 M4 `8 Y$ s; H: G
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。" @8 F- B; r: F4 U# d! Z
7 |1 o7 U' {! b) e/ N: V$ N
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。7 b! u! X2 G9 b1 F6 ~& c
: `/ K+ ?0 D0 t. S3 C. ^: z8 i 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。3 y: t4 a ]7 M$ v/ W
( x" @6 F6 \' F7 [: P. M7 o
Shard keys& i6 C- |; `6 k) H9 H
t1 b. U( d& S* ?$ o0 j
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。3 `8 M8 P! z9 l$ B. v9 c Z
0 l) v! u. F) l* O
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
9 m6 j0 O! {+ h4 {6 L
: T! M- L+ j: ]2 u2 h{3 u* @5 c v! Q* H0 \! h
"ISBN": "987-30-3652-5130-82",
, w; l! p& n. k% P z% @ "Type": "CD",* T8 Z' g3 T7 Z0 c3 t/ V
"Author": "Nirvana",
8 M, x' D' t V( I+ M' Y; [) f "Title": "Nevermind",
* e4 O) w- v, L: L$ K "Genre": "Grunge",9 n6 R, R" X; Z4 b( N) O# R/ s
"Releasedate": "1991.09.24",
X$ V- w6 Y) }6 r, k" t1 p1 O7 j3 f "Tracklist": [
0 `6 f/ @/ S! J- v {
- {+ I: ?2 ?! J; Q; s" N& t3 n "Track" : "1",$ B8 `" ?6 x4 e1 F! a
"Title" : "Smells like teen spirit",8 K5 P! {6 t3 q8 W1 Y& w5 V, A
"Length" : "5:02"
5 V8 P+ p5 R! t },
. Y, e3 v6 C+ C2 b# M( |# K {
3 J2 W; D0 H# s$ ^! b/ O5 I "Track" : "2",5 s, A9 }* {/ i/ @/ ^2 |% Z
"Title" : "In Bloom",4 C9 b) V( z9 x' a* D# h8 `
"Length" : "4:15"" W6 C: o: w, m# s7 H- v( ~
}3 B0 g5 H. a8 O/ w9 v; f. L
]9 r7 Y2 _# O0 T) j" l% X
}' D( c& `3 _/ `+ X h
9 L- N+ y( h5 h R/ f! A1 u
{
6 g- n& \ Z# x "ISBN": "987-1-4302-3051-9",4 z- j/ p- T5 }9 J
"Type": "Book",) X# P( J: z+ ^" u, b/ I
"Title": "Definite Guide to MongoDB: The NoSQL Database",1 X3 [5 {. {8 H3 n2 L! o# b
"Publisher": "Apress",
- y9 \8 F- ~) O6 C- L "Author": " Eelco Plugge", \: k [) ^5 {0 W% B( j8 b
"Releasedate": "2011.06.09"7 q9 s. J1 r4 E W+ P. \0 B
}
3 t' R( m3 ~* f/ y8 E
% |% [0 g1 J0 W 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
# B( J" @; a& ^- ?
9 a, O! s% G3 D$ m5 g 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。( x* E+ M# _* _! r
! ^9 Q8 [; s2 g& R9 o4 B 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
1 J( C+ O. e3 a' p% G) w! k6 B, \5 k7 f: d
很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。( j9 G# r7 L& }0 H0 U
5 H5 Q( e' S9 @% v
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
, H# [& X9 p8 j' [6 g( K( c% j! W" z5 U: H1 h/ e; e _ k( `) O
Chunks& P! X- \ B9 v3 w5 E
0 d, {* `5 o- N, j/ ~
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。6 j- W$ s1 P! Q l$ i5 J4 L
% ~9 u% ]* E X9 X' \
$ V* Z D, N. K* K, K3 ]% m
图1-2 chunk的三元组 6 w' e( y2 v" @3 i- f
' e9 P3 |$ [5 n& k3 u! Z: a2 q
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
+ \$ Z. Y8 c' H" Q2 h7 u" t6 S6 c4 b& m' w C5 j/ c" y5 s/ M
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
( Y7 |3 q; v+ X/ S7 i& H6 G7 g( D. V4 F( r8 f9 t9 G
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
8 J& T7 ]4 _5 X/ ~7 \
; |5 u0 h" m6 `; ~% P* b" g6 k 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
1 P6 Q2 J& m0 F3 ]! J" S; g) [8 N, i! x7 j8 h. w
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。0 Y; [% O# s' U0 G+ ^/ J: T
! z* G& o( B+ R# i8 _
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。" B. {* N9 J* B1 C# v3 ~
a0 J1 p$ O+ j
Replica set
' h! d6 U: z! T* C 1 d3 i0 X% Y) P& L1 s+ |& o. q
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
/ k$ J3 _4 c4 o" c9 {
# G4 v- Q5 @, t& E; X 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
: G' p) p8 d# b2 e* ~5 c/ F/ T9 ^. j
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
) j7 a" e# B4 c; i* E' _9 U3 w! a' W8 I# T. L e. V5 m. v& b
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
+ @2 [" }) l. I9 u1 Y" s6 t! w$ n1 [! G8 i& H
Config Server
9 ^$ |0 ?9 }' i' ]; V' L
. Q# d8 i, |; P% ~9 M Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。9 Y4 ?( i7 b. m
b$ A( B1 g6 m. l1 ^& k 每一个config server都包括了MongoDB中所有chunk的信息。( X& k8 P! ]8 N) F) e0 ?
6 ^* ]9 J. b) ~% C Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
! b" t3 \! J$ g8 B
$ M7 k D# l- c. Q+ O, X, x5 @ 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。$ H7 p: x* ]- D+ P, L
1 p) R$ B" m5 x8 C/ V
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
/ v! q; O$ p2 _# \3 f- U1 \" R9 }. j7 g. V' B4 l
Mongos9 `( G X- Q/ X5 w! m3 W2 u! x
2 c1 {; M& S% F3 [5 l3 V P 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。4 f/ F" P, P2 R% E
: g: t9 w1 t$ R: h' ^$ }
当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
, i: Y; J8 H7 _7 U4 E- w, d5 u% ?" W! ?9 l0 K! J0 A3 X+ C7 t8 h
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。6 a9 V3 o# d- Z* f
0 y: ^+ C, U. R' P
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
5 {) r3 F( v- b9 A( R" `1 k+ e, r, P- Y1 J8 |0 w
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。$ s+ A* A. f: l# c+ P8 b2 J9 z/ |' P7 F
$ K! [: i. q! F Z& a
R- X4 M4 l* O _9 MReference，
0 f" C9 ~" l7 i5 [$ N4 ]5 w. Y$ y. Z, D/ P. h: F: ~
[0] Architectural Overview: E! J K; X: P/ E4 ]1 }
http://www.mongodb.org/display/DOCS/Sharding+Introduction
8 ^2 ]5 B% D3 H7 @9 {1 Z |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
& ?8 H, `" ~6 w" Y% O# u