|
|
关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
9 _& ~7 b7 B2 B0 g2 l# Q8 v2 d; A' Z6 p/ Z& O* S
阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？( i; \' t$ m, e, F
5 y7 z& S; F$ u7 ? 不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。- ?8 c1 E$ w9 R& O Y; H, `- q
( O6 {' g! n+ {2 J8 C. k
0 D: S, O4 |3 [7 ]! N& @
, p& ?9 i% D2 s' K, k图1-1 MongoDB架构图 " k, B: J* l: Q; `% |! o: ]) Z
1 [8 L( m" ~$ V7 W0 a9 A4 _1 \ MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
# d! ?* d# d, A9 l6 x7 y Y, n+ l6 j* D5 G+ ]& [
Shards( M6 x; l3 q% ]3 p# X
4 `0 D0 U: T) W8 V/ z6 v7 q MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
' P) c) A: S. ?% U, N# c+ K
2 x) X! S5 V$ U, l6 N7 L: P Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
7 J$ r" m' [4 a, |6 Q1 B, O+ F5 b9 `" r& m2 J8 [; P
每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
; O: o* |* R# |& j- H G) d! A* n6 E: D
如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
; N3 o- o t0 z6 s+ ^5 K
2 D) N7 \0 W; G' W/ A6 r ~ ]Shard keys
' {# S+ T1 n2 y. c( E0 k
t' k( P. h( m3 d+ n2 r 为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
g5 I- v& ~+ d" [. n4 _
2 C1 W- ]! y! I i: q1 }9 \/ { 如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，- @8 Y1 ^; s) r: z. b8 J+ @2 Q1 n
, H7 o5 u1 R' r
{
% c* \5 _2 K) L" u' `0 s0 P9 N "ISBN": "987-30-3652-5130-82",8 |/ T4 e& U$ I/ B! t) e- |
"Type": "CD",
; d; p0 I0 ^ C" D "Author": "Nirvana",- z n1 v, e$ i b, C- T6 c5 S
"Title": "Nevermind",7 @5 }( N7 U9 z i5 h
"Genre": "Grunge",
4 \) C& x# Z3 f4 C. `( |8 j "Releasedate": "1991.09.24",
& I4 B+ q% F5 J "Tracklist": [
' z) y* {% {0 P/ s; y- D {
2 W5 T8 c2 }5 c "Track" : "1",( u4 t; t6 `& n: U
"Title" : "Smells like teen spirit",
) w. T6 }& e2 o. H+ q' E- y) X "Length" : "5:02"
' O z# p7 u. D },
! S+ z7 F2 _, H7 X {
; l4 h: W; [" C3 ]( v9 H "Track" : "2",/ v j. s8 F4 V
"Title" : "In Bloom",
2 X' X9 E4 {3 `, G1 i+ S "Length" : "4:15"9 d: f9 k5 N. m7 T2 M2 W$ Y9 J D
}3 h& o' @2 D6 B: O1 ~
]: _; ? l( u; V7 \. S3 }* |8 g
}# }7 o+ d) k+ c2 K" N+ X6 {
% p' R% t0 Z4 {+ o& _. q+ ]* l{( z4 s& f, \" k$ q( @2 @, s" I
"ISBN": "987-1-4302-3051-9",
7 ]9 k2 F/ w( u* J S/ t "Type": "Book",
9 ~2 H5 h4 \2 _* \ k' @; ?6 k "Title": "Definite Guide to MongoDB: The NoSQL Database",
' C2 A' O; F( H& L# y "Publisher": "Apress",
; q7 P- J' ~. a* Z+ F7 r. x "Author": " Eelco Plugge"," w* A) s6 ?: m M% ~4 ]" J8 |
"Releasedate": "2011.06.09"' L( e( J" g8 h2 E7 H; M' S# t( W
}5 `2 F v X) Q' M
+ Z6 X7 k$ l4 }+ j0 c 假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
0 ?* p$ @4 Z2 r* @3 _
; C" s6 D& E* h 在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
- B4 I. i- `+ a& ?# J8 Q0 w2 B
例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。; v" [' o8 F4 ?9 b( K0 e# Z
' B# m0 g& _! R( o4 d 很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
; I/ k) }& H! \. k4 m/ B$ d! H5 }; L5 M( g! T$ m
延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
' Q% i# a6 Z( A- W" H4 j. s$ d
, L: Y- w2 t5 D8 S* b5 CChunks
0 ]0 R) ~* R+ P: O , t# r: J+ N# u1 K" i
MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。! _9 I, n: l& t0 T) w2 y0 u
6 G5 Z+ z- D1 L: h$ e3 R
' Y: [ ^. k7 h7 a' u& W. A
图1-2 chunk的三元组
& Q# t& L1 z8 z6 D# b- _6 V$ Y" q6 i6 F8 t8 L
其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
) c4 {3 j& f( [1 A: F, a8 t1 x7 I: s* j
如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
* @. W6 m: i1 B2 b6 A& U
1 f( e/ O, ^: { }4 i+ d Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。: `% I9 j' q# \2 o( s
" v9 A6 L$ ^% q 一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。: j* ^+ y' Q0 u. X
0 a }3 g8 z$ @( b 当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
, ]. P- D2 ^+ h/ A
5 I3 P, j# n, W6 I; }5 t 这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。: L1 b6 b( V* Q' Y/ D7 ?! y
7 Y7 N( H$ w' v2 J1 h5 k% |1 }
Replica set' z" i) ^# Z5 T8 b. |
# Q' \. p6 R6 ]6 F: `& ` {! h 在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。1 H- d* y1 u5 A. P
; {" h! a* V2 @9 I; u7 I' C, L: |" S 这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。3 R" j) t/ [% o7 M/ Z' ^
0 j+ g5 j. E, O* e5 f. ~# |* R% Q* A
Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
' U3 K; X( C& q% B& I# p
; q# C! J( n. m Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。; T' b" o! o# l7 r
+ g5 ^/ f! k! V
Config Server; H, N# R$ _: v
- C) v) i1 j A6 X0 O( T Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。4 `4 U* {5 X+ M3 E- D: [8 {
+ k3 n0 h( n8 a8 k: S! y/ N# _! }
每一个config server都包括了MongoDB中所有chunk的信息。
) b w6 B' B" J: y! V
5 G: x+ _- f2 e; G, U Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。* e; q) W0 ], m" c# W( Y
* n. \2 s) O; S" F) @* O2 E! b' o
如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。$ I- P e4 \$ \5 b; x1 Q1 `
% v; P' R6 s6 c& m4 O& p. g. h MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。- g- j5 Z2 Q- U, m
- r c1 R+ v& j+ |1 d* P& y9 NMongos B$ ~# `: A" F9 h! d! g; C
% |* C6 M% g6 T. B1 j: [. k5 O
用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
- P3 ?$ ]" |7 |. p* d* D( I, y) j
3 x! [% o5 t( C% r: B, d 当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。3 U# q; w7 n- `' p4 C
) j; H" {6 e6 B
Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
/ D" L/ l3 L+ Q# {# ~3 Z+ ^* Q" X1 p* S, ]
Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。+ n& J0 ~+ j A0 q: B4 z. r% O% L
}) p3 F' E6 X
通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。8 U8 \( X) Y; G/ u; Y: `
# w1 F; D3 B/ c6 v
* h# Q& Q; `3 R5 B+ B6 n% PReference，4 s+ ^9 j$ R( H* M) X" X& H$ |; [5 ~9 S
) t- n6 C! k4 U3 `1 U9 Z4 k( W
[0] Architectural Overview# |$ q& P* l7 n, I( Z* L8 F) T# K
http://www.mongodb.org/display/DOCS/Sharding+Introduction
5 b; u* [1 {! B# m |
评分
-
查看全部评分
|
雷达卡
发表于 2012-9-18 12:31:10
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
已经给你变成正式会员了。
3 G/ n f" H$ p& k$ G9 y0 S