|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。7 F4 g: W+ J6 C3 o7 U' Q# P4 C- u
( Y: `& E/ ~- E1 n0 E* O6 F; i 阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
7 R/ t5 K( l8 m( X" m" x" L: k s
# [6 ?3 {# j' {7 s 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
5 `& Z# n- `1 |* K; w* [: S$ g Q& k
" e5 Q9 Y# p: ^! `5 U; ]' x) W5 M3 K2 P
图1-1 MongoDB架构图 - |% Y C, L/ u8 }
( S' h) e2 h/ w4 n$ ~2 ?
MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。3 K# L/ X1 F& \4 `
: D T6 f8 F. v# t+ e. z5 R" c# L7 H
Shards
. R6 G5 c% B5 _* C7 v1 t+ A; h7 c# k0 d6 R1 U' @" r% G
MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
8 e) `8 z! c( O4 N7 L5 V* O3 A: c2 z1 v$ R3 ]. a! k) R2 g
Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。) `- h4 v; s- s. V& d7 I& c$ J
$ c: ]) T( j4 K7 j0 ?; Z
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
' V5 }4 f% t2 G- ?! v4 r! m) u2 V0 D2 W7 v1 E- w* o
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
6 a6 _" `2 M8 F* l7 n8 {% }
Z7 x/ M0 ^! ?Shard keys
: y/ e& L) L$ |% u9 X + x" I. _+ }/ v# K. B. J
为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
A) v: W* K) ?0 Y1 u! i4 }/ W+ ~+ k& C0 J& H7 b
如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，/ |/ s! R/ t' r' D
1 i+ C* w* _; ?$ t% ?3 ~% F7 Y
{
; R1 y4 f Z' U \ "ISBN": "987-30-3652-5130-82",
0 \* C5 y3 F6 S {' y4 y- y "Type": "CD",
" K8 i! {( l6 R9 J5 c "Author": "Nirvana",4 y; Q$ ?! ~) b, a% B! R2 K
"Title": "Nevermind",. h6 H% _/ {' J! i( W4 O/ z
"Genre": "Grunge",, R( U8 ]+ Z5 g2 C# j
"Releasedate": "1991.09.24",7 ?% Q6 p3 Q8 A! F% ~9 r4 @
"Tracklist": [
5 X% C' p9 H0 F3 ]' v {9 m5 O; \. }. i* g
"Track" : "1",+ f7 h. g% v/ i: T
"Title" : "Smells like teen spirit",0 N1 j7 J8 r- c# K8 h R9 q2 A
"Length" : "5:02"
x9 b4 X9 }7 E5 b },
/ j# b B$ a- \( K& U% K {2 p. r. \& K% w6 N3 Z+ i$ Z" ]4 l
"Track" : "2",% ~1 d1 j$ g0 ]' C% q* d. i* m
"Title" : "In Bloom",! Y7 c% h/ U' S; A% B! P3 [9 y0 P
"Length" : "4:15"1 |! U6 Z. T, H& m
}
' Q0 O5 `* j+ e+ U0 u4 e ]/ f2 l3 |' ^7 K% N
}+ P ~, I0 y; f7 d6 U2 T5 d
3 F+ I: [5 j0 E1 ?3 C{$ \ d7 m. S- t
"ISBN": "987-1-4302-3051-9",4 p, ]% z: P3 ^1 m) l [
"Type": "Book",
! Q2 z4 e. b! {, e& h4 O2 i1 ?, Q "Title": "Definite Guide to MongoDB: The NoSQL Database",6 Y" r$ I# D M0 m0 C
"Publisher": "Apress",# S8 n$ k9 h7 R/ h1 e
"Author": " Eelco Plugge", L9 b& a/ r' \/ f% S5 G! w
"Releasedate": "2011.06.09"
9 L' s* Y0 i/ a& G- N* e}
( G5 g9 T; x. x& A/ t; f3 h
( E1 N9 c% O" x( Z 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。; V3 I( Y7 P+ F6 ]1 z6 G( d
+ J# i& {: n, ~ J! j$ X# o3 b 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
( m0 P8 l; e+ S+ b3 {/ ^: ]0 R0 j% a: j* R2 u8 `& _- a3 Q
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。) [6 h2 F4 P1 {! R
6 I; \( k" b9 n/ D) \ t' X 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。6 K2 f& K0 S8 b5 X
- m0 N% n3 {* a1 @
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。+ ^6 g1 T1 b# [; l- Q% ^
6 K8 p8 k. q6 \" X6 o, g
Chunks+ }/ `1 h$ y" U( D' }0 A
: g6 ~2 ?( I) @ p ^* l0 A
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。; v' ~% p& ~8 S' W. O! \$ b0 n0 P
8 [* n7 y, ?: x% j# l2 Y: G7 M1 F
+ J% D, o: a& i# J. |' c$ R* j, S: p图1-2 chunk的三元组 ! p3 K( T+ t J N. U
2 j- M' q& e N& B
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
" u& X2 l0 \ W2 n/ C) Y w
5 x( @ s/ i0 U 如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。1 I/ _% R! \3 }# c3 I3 r
* j' X: X$ l- a* I/ V6 x2 ^
Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。- N# J- t, _+ E4 F& b
" h# }3 ?& K# Z- j 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
2 B; I3 A+ J1 z) f& Z& o
* c" n; u6 k$ {( f) ]& c 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
! {# z) p8 P3 f5 f- c: i
; a# {8 o; P+ w, K0 r" B 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。( |* J- n* o6 z7 z E! O
3 T& _- D! e8 O( o% |) n
Replica set$ [" g3 Y$ y7 n& O& D- l8 I% V
: n$ I# h. i: j; }; R' O 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。. m$ K$ m" h: m. s) P
3 R) L$ ]& b* G7 Y4 O 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。6 U, e% h# o. D2 o8 u {
5 u! e" e! j7 w/ t* j! H4 O
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。 S' j( _) e7 j( h
9 M7 r1 O4 g+ ?; H6 l1 C6 P Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。, t7 D) e6 q0 K% T0 C. l1 o5 `8 w
3 u- W( X4 _ C) J6 ]- a: D4 ^
Config Server: p' K" k! g7 G4 i/ `1 Z
9 x- H5 Y1 u- h! E; Q# z Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
% E' o! N! D& ]/ k3 n/ r3 p3 m5 Q# [5 ?2 n: ^5 z1 `
每一个config server都包括了MongoDB中所有chunk的信息。
8 W* m$ l3 D C+ u2 @% C- j _
@ k8 h' l8 S& x; ~ Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。
; B% [: M8 n+ a* H7 s, T' h: K/ l7 B! o2 I/ T6 A# h
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
! n' p4 z) P9 N
9 Y( F9 D1 N$ A+ D8 C# x MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。; \0 d; w( O/ |
. [ y. m6 |) G9 F+ z. p4 S# \Mongos
6 U0 J# S( C/ U6 K2 d; D- ]. p$ L9 p$ J9 m! |* x8 p" {# i
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
5 V( d, J- h1 Z6 U( T
2 t+ W( t' K) ?, O( f 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。. ~1 @ z1 Z0 ]4 ~4 v1 C% p6 @
% G$ u! G( A9 J; y# r: U0 z Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
" A& g6 @3 q$ Y' x: [3 s5 i& Y) r4 s( w8 k2 x* y0 w1 f. T
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
) t) o' U/ k/ f; j& u: R
$ ~! ~. M4 t2 z/ `% k6 j: X 通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
! d0 F4 `& C: Y9 a+ s# e% N8 C4 P( F" R8 c
/ J0 t, y4 O+ N! K
Reference，
# d) w/ K8 v7 p4 x+ M' j8 o5 g8 K" a4 U) j* Z
[0] Architectural Overview
4 Q; K% E0 ]5 ^. {% F, ahttp://www.mongodb.org/display/DOCS/Sharding+Introduction4 {3 I5 h5 K Q2 Y N. a
|
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
' _& Q0 ]. ?6 m; r& e& E