|
|
关于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 |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
