|
|
关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。
; H2 j; o2 P% [! b5 W% o0 H5 n Y; W0 Z2 s& c, H4 j" o1 f
阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?- `% W. q" I( B, |$ [) l" E
W1 s5 L, M5 O4 s1 j4 _ 不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。
8 A$ I; F/ I# c, R8 v2 g& _; @4 x4 T4 h% O8 p
8 N5 \4 b/ p+ Q' ~1 B- V1 Z! a
3 O3 u$ U [$ ^3 n9 y5 p9 q2 C% e图1-1 MongoDB架构图
- r' A8 c3 u3 A, N* o5 Z* d9 i9 V" q* y9 ? o4 |$ V
MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。
L: F% j" d, i3 b% {& \+ d7 t' P% q% l# H0 T6 P6 L& a
Shards
/ V, X1 m- i. r' Z7 Z \5 T& F
0 R* |, Y( i: l g: e/ G5 s% { MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。, E" A. v7 x% U! R* G1 ~3 t& K
$ W+ o3 W: i) e4 |& P
Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。- _. L( F+ f5 v5 ]8 M2 m
/ C0 R8 |7 y6 Z; ^& ` 每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。/ q' U5 L6 ~; n: Y
; H' Q! b& w, J1 ^# x 如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
# x, w5 w* b( a
) m2 }' f# Z9 zShard keys
# Y! G2 R ]$ P; }: u6 l
. P' F# Z' A- M# q) c. g) J 为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。* H h/ h3 Q. Q+ w' X2 M
* q+ G7 w8 T8 z! f- ^ \
如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
5 K" P. a, S# O* J" G D2 h! K& o% ?8 {( i% N3 e: k: k
{
# n" z: f$ O, E, [ "ISBN": "987-30-3652-5130-82",
# A$ T# u9 N' R( W, N2 S6 u "Type": "CD",& q2 P. P9 a/ ^7 L+ S' n6 m
"Author": "Nirvana",* y* f; M5 Z$ B6 ^! ^- Q9 N/ ]
"Title": "Nevermind",
$ K9 @6 E3 j/ j "Genre": "Grunge",5 L" [: w8 Z" b; z
"Releasedate": "1991.09.24",
6 k9 S2 m: x* c! z0 U4 X: q "Tracklist": [
/ J4 F9 X7 E1 ~3 W6 L {3 f" i# W7 ]9 l8 a& r( {
"Track" : "1",
& K7 ?) a) D4 m& L. \ "Title" : "Smells like teen spirit",
; I) k( V9 M X' L @3 ^) _ "Length" : "5:02"
! ^* f7 W) B7 ]! }! V/ p7 d: z },. g3 l, n: c ] O$ Z
{% D5 |: R! e6 S/ q7 r
"Track" : "2",
! }1 Q( P1 Y" P& [5 j' ?$ f "Title" : "In Bloom",
5 @# p h8 U! H9 e2 G4 v "Length" : "4:15"
) i" M* @5 L$ ?" ~: ? }
* U) E) Z7 r/ t: x9 j5 [- P3 C ]' p; N) [. W8 V& Q
}
, R. R, J& Y+ H
% P9 l! z' G4 ]% v7 L{
% V1 \, O1 \5 s: F# l "ISBN": "987-1-4302-3051-9",# R8 [) o/ d/ t2 R
"Type": "Book"," k- D% n( N2 j9 X
"Title": "Definite Guide to MongoDB: The NoSQL Database",
7 A9 ^- s% G* I4 ?6 O. @ "Publisher": "Apress",3 S4 Y8 Q, }1 [( s% w8 c& o
"Author": " Eelco Plugge",
% I6 q- s* V% U. W! M3 l "Releasedate": "2011.06.09"6 F8 M7 R# ^% `8 O' ~/ Y% m6 q+ T% \. }
}
& E! U5 n! R7 ?2 M9 l; r: }) ?+ b/ L' }
假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。, x1 U* F9 Q8 h# E. t- p( {
: F1 }0 C3 N) E* p! e
在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
$ W n2 N3 ~/ t8 i8 Y8 Y
* b" w/ {9 a H8 `; x 例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。; L; _1 |1 o% t. O! [2 M/ ]
7 H/ O8 X. R. [& h0 y3 C, J
很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。0 ?/ Y0 y. U" N/ G3 W# O- f
6 |# [& ~( s4 `7 L 延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。5 b N4 u) Z& J; y/ l" A: j6 m! n; P
# _- R" x0 L& B) {: xChunks
1 Z* l. ?3 U1 B7 }4 O 7 I' S' ]2 J- Z( J& f: S
MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。( x( ?2 I$ _1 }1 `/ O. R: `
0 q/ H' Y' B4 j. y1 ~4 L; @1 ]4 Q
, p9 L2 f @) B
图1-2 chunk的三元组 I. j9 h1 c$ x3 D. j; K
+ t/ }9 S* M, Y/ h! {) D/ t
其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。
b9 ?7 w# n) M# z u' K
2 e; g' H# q& U3 S3 V 如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。! t' f5 f3 m: v, J; U& }
|0 R/ D# D, q" X' w
Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。
5 o2 ~# ?; \& \& ]. @* k. H o# w6 ?2 u
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。
3 z; m8 S. N) ~# r q& N% Z
1 L& s) x+ q! W# R$ m8 v: f: @ 当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。 v. Y2 N5 R+ x! |9 \
0 r* @. }/ v8 l6 e# j1 C+ r% J 这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。, ]* @6 ]$ y1 N: S( g0 w
4 G9 B! v; Z+ U: q4 ~
Replica set# o' G7 W- c. I/ {+ K8 |/ o
+ H# J, j4 t' g M( b& V 在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。! `% w8 Z, a7 b5 ]
& P' p# |% ~' _4 V. _3 f8 ? 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。( ^- g( c# [' \1 b& x
) }: ]' D6 Y# H: B1 z0 M
Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。0 q: B1 ` G$ ?
, M8 |) E8 r4 |; a# P8 V' j Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
/ J3 t" b9 b0 q; C" h5 b5 {* h- g/ x0 W& H5 @4 ]% W ~
Config Server
3 J. k; J' s$ m. N
0 o% X* P) F1 Y) t# Y# D( D Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。
0 V- _1 t- n# E- g8 x# ]* S2 l' B% V/ E; I
每一个config server都包括了MongoDB中所有chunk的信息。$ _) \( i) ~3 A/ }7 c6 Y+ v5 a
5 {! Z! \0 N6 m% }$ x4 P5 L" g Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。/ h3 A7 }1 |1 F2 r% Q, |3 I* U
8 P& j x; p/ w1 b 如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。
/ Q( [8 \3 @$ Z- @* H& p) j
7 a0 [' N3 h; s6 v MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。! X0 W$ x4 J# _+ a+ ?% B+ F+ c5 s
7 M' L) T) [) R7 k* \* T. l" M
Mongos
% U% c4 |7 y7 f' T7 k1 d% B4 W& P. j1 F) l6 {
用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。
) o/ Y. C+ E8 E5 q2 Y4 T' N9 u% t( z$ Q
当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。
# T/ X/ _% h; s9 P+ P3 F: R- ~; l! s# F) a+ p1 c4 n
Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。1 B; z4 t% w2 `
0 |: d7 S) L- @7 J5 G) X* S" L Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。
* W8 l: I5 V+ n9 O; @5 c$ L8 }1 ^
5 D. D' V, S1 X4 O( m- w! I 通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。" J# \1 W3 @" q0 S
2 B0 w4 n2 F" J5 F+ t
6 X8 E: W( M# L5 ^, N, C L' g
Reference,
4 n+ h; V1 C) O# @, v1 k# s0 m. _- k- M) R+ m) t" L+ f% p9 H
[0] Architectural Overview
2 m/ I0 |+ Y7 l3 O3 Lhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
& o# o* L$ @2 M( i+ y* P% p! y |
评分
-
查看全部评分
|