|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
- X! _ T$ z8 S8 |' V$ X( N' r7 O3 q! S: J1 v
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
, H8 I* j/ S1 P, M8 w9 H! I0 ^$ K7 f" O$ U5 U9 {
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
, P6 M+ k1 x. i1 J! ^0 j5 w4 E' b% A& y6 L7 S
! p/ }& L. d) z$ y
* \4 k3 ~ e& D5 }# I2 ]9 @图1-1 MongoDB架构图 & N7 B+ [. ~% _" f' W$ f
* a. I) ~4 `( B& L i3 |
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。6 g1 M+ W+ T8 b4 ] q- j
+ ]$ _& Y* ~, X4 TShards0 ~4 y/ O& z+ j
: G# e% L; o9 Q9 g6 J
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
5 U6 F( {, O+ J( U7 M1 Q# O. v) {3 p( q' o; h# B
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
% |3 J% I4 z ~) D0 k6 C* P/ l6 ~% O1 t% c- Y+ Q
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。7 x/ a. e4 N6 S: u, T; Y
7 z$ d) K7 B& e' t3 g ^/ E 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
! D: k+ r& X8 B
% \ k- \# g- HShard keys
6 ^: ^7 M0 ?" H, p. @
1 Y1 r% h) h |; L: t8 D 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
3 ~4 `* ^2 K- S
' K' g, D3 T8 u2 b 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents， z* W' {( o. v6 ^! q
/ u, V, T, L! K7 N7 x
{
/ t$ u& u- y* ?' r2 l, z" U/ Q7 g* D "ISBN": "987-30-3652-5130-82",. d, F( \/ X2 I7 Y7 w4 ^' U; l2 w* M; O
"Type": "CD",7 `' g6 G# B- O4 U1 w
"Author": "Nirvana",
" @+ i/ d7 h: v2 Z! g. h3 d "Title": "Nevermind",- j! e J% J% p7 k8 s# W4 N
"Genre": "Grunge",7 [* s4 r' x$ Q, p* H4 D0 N- }4 X( _: p3 b
"Releasedate": "1991.09.24",
6 J0 h5 ^: f# c$ L" a "Tracklist": [$ n: b: f( z4 K' N* v1 X
{
5 B$ d0 i" K/ M# P8 Q6 Q "Track" : "1",
: \4 G+ n! v+ G# G/ f% }0 v "Title" : "Smells like teen spirit",- I9 c: R: `; N3 Q5 y$ K
"Length" : "5:02"
$ ?- M' Q7 D4 X- R! c },2 x3 _6 J3 K, D: Y" B1 y7 i
{
' e/ K0 b' ~; n. v "Track" : "2",
5 k/ I$ ?/ z, z [9 z6 S- | "Title" : "In Bloom",: j& Y; T1 \ s8 P
"Length" : "4:15"
$ O4 ]8 `/ y0 z, [+ k }6 _0 ?6 I6 E+ e5 r
]( i8 i' l' O7 P: s6 N) j$ Q% L' ?
}
: b Y$ {- P& U: {
& g& h" u0 ]+ I{
; a0 N: T% a, U3 e "ISBN": "987-1-4302-3051-9",2 H, P0 L( L; b& K
"Type": "Book",: Y3 r ]# i) @
"Title": "Definite Guide to MongoDB: The NoSQL Database",
; v1 [; M) |# O5 k ` "Publisher": "Apress",
' W8 W \) V) o, |" R: @ "Author": " Eelco Plugge",
: j4 r; S9 K' A: z% _4 g- ^ "Releasedate": "2011.06.09"1 G U+ |/ M$ Z
}
2 n: I. I+ D8 ?8 R, Q
% `; B# X- m) Y, C+ H 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
. V5 a% ^0 M2 n! O# N, f# w& _% Q0 E( `
在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。2 d. e* h5 s" Q/ U3 T
# ?/ d, r% ^2 R6 @1 K 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。6 C+ s6 }1 H% m4 R
4 I" ~ N# a6 k, W2 l; N$ K 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
# R& G" K5 e) o3 J! |7 _& H; c4 v1 ?" X* k" g; O, O7 T" k: \
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。, z/ `% w+ ?; l; Y) R3 p: @
* Y% E `* r, _; E
Chunks1 z, d1 s3 w$ a8 Y5 a! i n: Z: k a# z
0 p- m: y# q/ }0 U3 j+ F- o' @ MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
# U7 O' Q; a4 S5 i
+ _# k/ H: x% \
. ^& U0 b& p2 s g1 ?6 l! @图1-2 chunk的三元组 + h3 c+ r5 f, u( ?
) J# q0 G1 X* J0 V4 ` 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
2 g3 ]$ E5 n; w- F: K
+ C7 [9 o& Q- R Y 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
$ z2 h4 P0 q' C3 X5 Q4 s9 w z+ |! R4 ~1 ?& u
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。; Z9 W8 }& B+ U \& u% c. l
% t3 p6 [$ j( ]9 X# [ 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。2 l. B0 ]6 J$ _ V' f2 a& \3 n
( w8 a! N! \- |4 ]0 F 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
" b b: v) e; ?- z2 Q, s9 }
1 d% @! u# l+ R0 Y+ t 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
7 l- X$ a8 x+ c# U
% i5 q) `7 ]' U: X4 F7 ?Replica set# `* y6 C: g2 c2 u5 r
6 \# ?; K8 B y( x 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
5 j, y; ?& [" y" o4 ~5 w6 t8 M/ D# r. G2 w8 m9 i' q( v! F
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。9 i3 u5 M8 M) W% f! v! P& q
, ~8 H! y; T4 c0 ~ Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。3 |: G5 ~- Q$ X
) |' i; u- t- q+ [' o$ w8 S Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。( T2 ^% n* w' N% u8 K
0 T+ y3 r7 v: b( ?' ], d) X( G5 [Config Server
2 Y3 D6 U3 U8 W- x ` : ?- k8 [+ p- `( ?& p0 d D
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。2 @; [4 l6 @; g/ \+ h
* |# X4 U9 S/ v+ {' w7 [5 y 每一个config server都包括了MongoDB中所有chunk的信息。
" @$ J8 m! S1 o: O: P0 r0 Z. I+ t. \+ {; A7 D A1 b
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
5 v R7 [7 v+ N) W4 Q5 R% O5 _
8 h, d9 D6 P4 w2 [ 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。9 `' r" q1 i7 _5 l7 v& ]
+ L- q; k# E. y0 S& _ MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。7 B, T# H8 N9 e/ z1 m9 @4 O
" C [+ y* o5 J LMongos
5 ~& ]" o% Q3 N) J: o" o
! d5 I' A% S% L 用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
% ]( [4 j1 ?8 G
8 Z5 h! x( |9 _# W3 f W( d 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
) n0 m# O+ V D. d/ v$ X5 K/ Y9 r7 _5 N1 Z" W5 x
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。! v, O( `; {9 {' k7 _
" h9 T# a& t1 M0 M+ G+ T Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。7 }5 h# @9 Z* Q6 V/ o# `: y' ]+ H* b
# M4 M# f! O9 Y9 d" A/ |1 @2 k 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。$ g- A! p5 c; O
% u# Q; x7 O' t+ g
& p7 n! {" W$ _% t& M& n1 `/ \Reference，
" J ?% G1 V% ~! ^8 b2 i+ G
; V1 |; C' O1 T7 r) n[0] Architectural Overview
- t' B7 w; V* Z. C! phttp://www.mongodb.org/display/DOCS/Sharding+Introduction
4 q9 B# e/ j: j) Y5 c9 r |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
' b) h1 Q ^4 p# Z* O+ Z F