|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
3 X6 |; M# T3 d$ G0 m0 y/ M: b+ n$ ?2 p2 o, X' f8 \$ z
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？0 P, j: N5 F5 r. O/ v. `( h
) i" E% ]5 r: m8 [" M$ N( G
不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。+ y+ @. G" `8 G% e4 n% R1 D
5 ^, v% N% p' @% \8 T/ G% Q
& Q2 v' C3 S+ `: I$ H1 |: s/ L' [( U6 S
图1-1 MongoDB架构图
# u4 Y8 B" _. }# X% A# F) g" p- ?3 A7 T2 a, p7 ?
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。/ `7 _5 y9 p5 U* ~
5 ~$ k) |3 w8 f! z
Shards
% b/ c% E8 |) J) ~( v
* Z# U8 e0 Z4 l. t2 g, H% Q MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。9 x! J4 l3 }) D7 V6 h! A% D
* i% a' b% K# G( K
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。, W1 T% Z: z' _" L
" [# u' g, `9 w
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
, R+ ]5 X8 Y/ ~+ Q+ L
~ {% X3 E# v3 z# x, J8 R 如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
' u- }1 _. ~, N4 ?) j/ g4 G5 y
: K$ }# U f( E& Z) W$ vShard keys
' U- ^% F, g3 I+ D7 D" r . b3 }1 N8 U/ e5 t. Y5 ]
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
6 `2 V8 H# B% V) v
9 E9 W2 U- @4 G/ q$ Z: u 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
c" P6 K( y' K* g: e0 c2 a$ R; L( J: L1 d; n
{
- {0 C+ u& \- Q# a "ISBN": "987-30-3652-5130-82",, d! N9 a" W/ C- [
"Type": "CD",% F1 p9 @$ }. H$ H; V
"Author": "Nirvana",
' j3 i9 V. e: s' N! H+ |' I "Title": "Nevermind",! C$ u% g9 z7 B0 A1 e* i
"Genre": "Grunge",
- w1 b4 Z0 j" [& @1 [: V8 P "Releasedate": "1991.09.24",1 `5 O8 V- a2 x4 Y9 T' N
"Tracklist": [ M( m# C& t: B! C
{
; G, |5 f& y' v "Track" : "1",6 z! e7 n) Z3 Z% l. R" @+ ?% L" T
"Title" : "Smells like teen spirit",# {& }' k" K5 x, ?; S4 @: U; f
"Length" : "5:02", V! @; c0 p) O2 C* S: s* q5 `4 _
},
9 n; E& ` b8 ?0 P2 l" Y" \) g {5 z) D I0 x5 f/ D( S. V& [
"Track" : "2",
/ e$ T) L7 M# | "Title" : "In Bloom",
( M' n* q9 m) R) c. \+ o "Length" : "4:15"
' U6 L7 ]4 w, d; u% s- z/ B }7 j0 R; n' m7 H4 k
]. l! P9 x4 d: t2 a0 d% O
}
; Y6 @+ u2 g/ c7 p1 h2 Y! o2 L, u; k: e8 R- t( q
{. C' z8 S7 _, [1 n k
"ISBN": "987-1-4302-3051-9",
& y" D8 S5 \! Y9 S9 l "Type": "Book",0 y% M" S, Y' ]) e1 X9 ?
"Title": "Definite Guide to MongoDB: The NoSQL Database",8 ` ^: ^5 n1 b/ O3 Z' L2 m S
"Publisher": "Apress",# N* |! }8 t; P5 M* k$ N4 [
"Author": " Eelco Plugge",( R4 G. e& j" g, g( h1 f
"Releasedate": "2011.06.09"
% j' e2 ]9 i* ~2 g. f, P}
; N8 G$ N2 M/ u" C5 {4 Q2 c% o0 r1 N- T
假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
. K( M# S# z" a* Y( V. [2 M% h
% r( u m# W. b5 Q" j# ]/ E$ p4 y. B 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
5 o o/ u+ H' c$ P& e8 X
9 B9 K# L/ ~) p; @ 例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。( k5 J6 [- U/ x
# R6 ~* g/ B& |$ m2 l9 T9 s 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。3 D) `( T! J# T( t6 i- Y
7 B' N1 f! g' B9 y
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
9 A& n/ G3 G) A3 {& X$ B: U
2 b; Y! [. W. bChunks
7 T. H3 i. w5 O, G1 _. N2 W ; V% S+ E# C" W1 I
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
! [/ L* _" z( l5 v: j1 A/ ^- O! v6 y$ T
; K. b7 F& p, E) ?
图1-2 chunk的三元组 & S8 c5 z( Z, B5 |- ~. K" V3 l: B' v
' n' I/ L7 L+ C* x4 @4 r9 D0 K0 G& x 其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
% c9 r6 S8 F2 f9 x* t/ j1 X& c
' W3 h# l( q" | 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
! _; }7 W9 p! V$ R
- E$ g/ [, f1 R' r( R! F. z Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。8 g/ ^3 P, f# |- _8 @2 h7 j) H
0 l p/ v! V" ~4 d
一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。% v( [+ l6 m$ D
* N& T6 O9 S$ C% m6 q
当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。& E" m) u6 r/ t, {0 k# x
* h& n# s, f4 |8 t! c
这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
2 K+ h+ T' g9 T; R
# A/ [6 `$ s0 U( H' f4 FReplica set
5 m3 m! T( \: e) a/ H * t$ D. t& H3 \5 B _/ J9 B
在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。5 s$ b6 ?" k4 _
1 x( [( p. Y0 a0 n+ l* q
这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。2 W1 @, H9 m$ {, W* y1 l
1 Z) J* k7 a, Z& ~4 R! v |& C; Z" T/ N" H
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
. v3 ]1 c; i0 u5 d) k' Q0 t# U6 n5 M- t- t# I* W6 z
Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
+ P5 {9 A* J2 J5 P3 `! E! d5 {* n. y8 x- h* G7 E% R4 w9 C' l
Config Server
: ~: z' }/ j& w$ e1 N0 }$ U , j8 o4 V1 J7 Q( g. Y) E6 B" K1 B
Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
5 b4 u3 P) W+ J3 d, i# {! L) q4 R& a- {+ L4 ^
每一个config server都包括了MongoDB中所有chunk的信息。; l: K- \( F+ E/ |3 w
) B2 h9 B' Q5 A z9 ]4 B
Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
. P2 v: J/ N) i. E; O0 A
7 l h4 R+ z+ X2 P+ P% l4 Z 如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。, X8 i/ D! z9 l9 {# D2 v2 ~4 w+ K
0 ]( ~7 f3 L0 W# w; e
MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
& L. W4 M' z# U2 b
4 Y& ~ e* |% ^* Y) m( u+ GMongos
; n- z0 p) `+ l6 d8 p; y' }2 S' D2 x: t- s8 q2 ~6 y( \( }* X
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。8 H0 k; B9 J1 t3 \8 D$ \
4 ]% C. V* i7 i 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。. _ l9 y; o/ D" E
9 X2 L) C$ C: b _* p Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。; r5 v* y( }, {/ }2 {) R. O9 ?
$ l( K1 v5 D7 S L4 x6 c* z( }" c Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。4 B: B# v2 Z. d1 d8 H* Z% m
& M2 w Z' G2 g8 ~: I* w7 N+ k( l5 Z: O
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
' c, \0 p4 }+ i' r
. a& m% D( M1 W6 N0 I
( o* b8 k6 Z" H9 i: z/ zReference，
! i; G _7 l' E4 M% C2 e
3 G* q. n/ B( R5 _7 Z, T[0] Architectural Overview6 ], W: r( p Q( |9 ]$ t+ N
http://www.mongodb.org/display/DOCS/Sharding+Introduction
5 o( R5 x; k K( q$ J9 t) i7 \, @ |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
