爱吱声

标题: MongoDB架构概览 [打印本页]
作者: shengnan007    时间: 2012-9-18 12:31
标题: MongoDB架构概览
    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。2 s, e5 }1 l2 Y/ x" V% G& ]
) m5 {4 [2 R3 Q) c4 v
    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
6 m+ Z8 K  v/ V' @' t( e
5 h, y# K- C0 ]    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
: [* H0 U4 |8 X7 _) J# I" p# ?$ X' ?; u; w1 G
& R8 e! K- i/ O, o3 u; K" W

# ^+ {% ?- y( b) J) U图1-1 MongoDB架构图

) Z$ o% J! Q+ n( L- k( J0 N' {! F; Q: x) w& w! A3 ]5 P
    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
) X' o+ Y: r9 x- ~6 R7 z6 \- z5 e/ N) ]/ N3 Z6 b  Q4 I8 \
Shards% q! |; i4 O+ k: Y3 m

  j+ a+ E+ n) z4 v* s    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。: x& Q4 U% r8 g! s

- g8 ^, X7 ~0 [! G0 x2 l2 C3 R1 f( v    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。( d8 M$ ?  o1 |, \  I

9 x- Q: T0 v& Z  T    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
  d0 e- }6 b5 N; O" d" t! E$ b: I+ ?/ {( U) g2 |2 R
    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。5 s( P- h3 w- S2 z

% X* B/ V5 Y2 d7 _. {* `6 bShard keys
' r8 O. A1 S, p5 j* p        4 V% G' |/ w, I' ~8 f/ S
    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。: I+ s) l; Y- |& n3 t5 X. I

1 I. t. C) U3 J2 G3 r4 O    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，1 T3 S6 f+ g; {* Q2 P# s- W3 ~  |

6 w3 D/ B$ K4 H' J4 X{
( a7 F; |: S9 f9 L. T, e  "ISBN": "987-30-3652-5130-82",! @! R- T: }1 I$ D* @
  "Type": "CD",
7 e$ l% _$ [6 t  "Author": "Nirvana",
  j6 Q, z; F& i& j4 f& P( N  "Title": "Nevermind",* p/ z. J" H' B( Q2 D
  "Genre": "Grunge",  ^% z, q4 h7 x( o; [& I' A
   "Releasedate": "1991.09.24",
" H: m9 h4 d, N( |- V2 H   "Tracklist": [
) ^! H* }3 i, S' o& b     {1 T; \3 \6 R6 F# C9 \
        "Track" : "1",
/ f, \2 B* R, o+ {% ]        "Title" : "Smells like teen spirit",; W  P5 K) T6 R
        "Length" : "5:02"2 l* O0 R4 z9 L+ _, u. l; I
     },( d8 a6 b$ c$ `8 w) Z& _
     {
3 j9 c  x# p9 K; k3 N, D% P        "Track" : "2",
9 e3 }) |& {  I0 b3 Q        "Title" : "In Bloom",$ D3 \0 I: H% v  ~# s5 ?
        "Length" : "4:15"
1 ]0 i8 {0 l7 Z$ v     }
, _' M: c8 ?. ?4 g   ]% F: e9 t' S4 q' F% D6 c
}" i' Q7 G: n1 J( ~% t& D9 t
, R9 F; \1 Y5 O$ R& I' V: ^
{7 d* L  \2 @! H2 a8 ^$ B* F
  "ISBN": "987-1-4302-3051-9",  c3 u, p0 I1 ], C4 l+ r' ]
  "Type": "Book",
% _8 w+ _& O) Z& k/ i- w  "Title": "Definite Guide to MongoDB: The NoSQL Database",
; P! X- D* Y) w! X" u" K9 u$ n  "Publisher": "Apress",
; n0 a# L( h6 x2 [  "Author": " Eelco Plugge",
; A' d5 J3 N, A+ Q* Y  "Releasedate": "2011.06.09"# z* S9 @, L' X; D2 N" q' X# C- S2 y
}
4 S2 X9 ]; X6 d8 b# @6 i- \
: q* k- W; @! J+ i4 G. d4 A# H    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
5 c! M, W! Y6 v+ P5 T
2 r( @8 x: O, Z4 [0 }  S8 R' X    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。1 T7 I% l' h$ _( g
/ R6 t  [- w7 c. `! I
    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。5 h1 L) m+ k- _* W) N( F
0 _, O8 _2 Z1 b
    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。
) {0 r' W3 D- [7 b; x$ ?5 ]0 r  G+ d. f6 h* \0 i* v: h
    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
/ e) H) T" u  l2 b  Y' L5 |( b6 ?! R% n. Q2 s0 a: {7 G
Chunks
: n  }% S: [0 f3 G7 r. H        
. {, u2 }+ f* q8 i$ C2 W    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
/ Q# k% Y6 Y6 R! ?5 \
* b/ O$ u: h; L, `1 r

% Q0 C: s! h' m" a图1-2 chunk的三元组
: h6 |5 M/ L) X

# O+ @1 C- T+ ~6 q+ n; {  n2 t    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
5 d% f6 z4 u; Q- D; U% G: O- ], B
/ A: A3 a( [+ U4 x; h( r/ A    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
8 }; U8 H9 l( o% t! \  B8 @
+ Z7 N5 i, K  j8 N& u    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。- o; h* b) ]% p( r0 |& N/ l4 d9 m
7 n5 |9 f! {; V8 R
    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。# c# Z2 ~0 R5 f$ B6 N
; f" Y: t( i: Y% G0 S$ B8 Z" E/ G
    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。8 u# p2 B. A( d& p% e
7 C" l+ b- K; Y1 v: q1 G# {  B
    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。3 e& R- ]2 i0 M: k
) D& j; a: \' c# b4 Y
Replica set6 G* t8 l: T& p" |
        & c5 o" _* T* b: _) g$ p
    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。* `: g+ y0 ^' X
& t/ k6 L- u: B% X
    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。" N5 H+ j; k+ Q! F

' V6 e  E0 q' R0 ]* J! b    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
5 l  y& M% |* O: M. f0 m; V) u& `
/ v( |5 t& I' ]% z, t& c, w1 F    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。6 G0 Y# w; R' c: }

. K( f( m1 B3 [7 l2 G" D" h2 tConfig Server
7 v# h/ q0 H0 {        ; s4 C4 L+ F0 c9 P/ q4 f4 j+ a$ O
    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
$ u+ F6 e2 [* u8 I
) ^0 o. D; a9 X4 w3 M    每一个config server都包括了MongoDB中所有chunk的信息。$ ~3 ?5 b& M& a( I& u# c. h1 L
! b2 H# w: c7 U$ j
    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。% h# c  g# C" @( v, Q
. T: a2 |& [/ _
    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。  q* A! L9 S1 K& _  [
5 i; p: G4 t8 a: {
    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。, a! f, `) K: \% K# L9 B5 G4 {! w

* v- Z2 U0 H3 tMongos) U/ D$ |' @+ ~; q" y/ G: e" h
$ t2 F3 A' Z9 e7 V8 U
    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。4 E' h# _3 {0 a/ O: }+ q

& d9 J) K+ l0 y    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。2 U0 e" I" Y/ W$ H1 v% q: w

  U; a7 m; o3 t' J/ g    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
. N% ?( g" e4 E' H4 t) _5 g- U4 F. j$ m; V0 |
    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
: N, r' `# l5 W, F" `1 [1 J2 `# M( I% |
    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。% W" \& `, I7 {: `8 }

% i5 f" @8 f* d3 A; w. [7 ~# R, W5 M4 v6 u: k0 w- }+ Y5 k4 ?
Reference，
7 p2 K/ G5 @; N' ~9 w$ C3 L1 J: y3 v( d" r; @
[0] Architectural Overview, Q& r6 J, N& N/ z
http://www.mongodb.org/display/DOCS/Sharding+Introduction0 P2 c5 l; v5 e4 k
作者: PenPen    时间: 2012-9-18 12:40
本帖最后由 PenPen 于 2012-9-18 12:44 编辑
0 ^) d8 x- F; |9 ~. o# N
( Z* F0 I. [6 p5 G; E6 b
: C6 _' F  e. F您是和邓侃一起写文章的盛楠么？
作者: shengnan007    时间: 2012-9-18 12:44
呃。。。是我啊。。。
作者: shengnan007    时间: 2012-9-18 12:44
PenPen 发表于 2012-9-18 12:40
$ s2 u0 Z2 m* M, h& F您是和邓侃一起写文章的盛楠么？
+ g; t" J7 S7 J( x- X
是我啊。。。这都能被认出来。。。
作者: PenPen    时间: 2012-9-18 12:47
shengnan007 发表于 2012-9-18 12:44 ! v! f) \  T2 m' z: B
是我啊。。。这都能被认出来。。。

+ s8 k: K# g) n! V; }0 J- B这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
作者: shengnan007    时间: 2012-9-18 12:49
PenPen 发表于 2012-9-18 12:47   d# q) H9 P+ X& j
这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~

, @, ]4 h4 m: X4 S多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？
作者: 不爱吱声    时间: 2012-9-18 12:51
shengnan007 发表于 2012-9-17 22:49 1 S3 W+ b, d  z, T
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...
. G) F# q/ E6 z' T- \9 n
欢迎，欢迎，已经给你变成正式会员了。
作者: shengnan007    时间: 2012-9-18 12:57
不爱吱声 发表于 2012-9-18 12:51
6 t/ I! A3 b2 F0 U# B- p欢迎，欢迎，已经给你变成正式会员了。
8 m4 P2 E7 Z1 w. o( }* Y1 ~
多谢多谢啦~~
作者: 巴山    时间: 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
* X7 q, r7 x6 k, l- H" u8 h! i& Q. X7 U* q- |1 {
作者: 梦晓半生    时间: 2012-9-19 04:21
谢谢。2 i5 K& g' ^3 n$ r

$ j8 K' W1 ^, p. @7 q7 e+ M7 Q中文看得真累，大部分还是英文术语。, v4 A2 v& c. x# C
7 p% [3 `$ s- G) L0 a7 q0 V
这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
  u' W; w8 @& h2 {* s) ?! U5 a
( z9 D. v0 |. M) q" o/ v" E. `' N现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。
作者: shengnan007    时间: 2012-9-19 08:40
巴山 发表于 2012-9-19 03:38
# K# \1 w: P% j5 Q我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。+ ]$ ]! H6 L/ S7 k, n
) I* g- U( d. j1 ~7 B. m* f; S2 U
...
; [* h) G2 Z) W5 d
mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的
作者: shengnan007    时间: 2012-9-19 08:44
梦晓半生 发表于 2012-9-19 04:21
, w' w7 ^  Y: `0 c9 G! h" y谢谢。4 j1 {% l! o! [
' b0 @8 }- X  \8 d
中文看得真累，大部分还是英文术语。
- C6 J/ L8 q6 M9 Y" f2 m& y
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。
作者: profer    时间: 2012-9-19 14:16
shengnan007 发表于 2012-9-18 12:44
5 y' ^( V9 g. _% C1 c* @3 o是我啊。。。这都能被认出来。。。
4 ]* G1 {! X- r4 {+ M9 s  x
是邓嫂么？
作者: shengnan007    时间: 2012-9-19 14:17
profer 发表于 2012-9-19 14:16
4 Q3 O; V" T# M+ {9 }1 l是邓嫂么？
; ]; D0 O4 z, c. S; i& `3 T
是邓的小兵
作者: 恶魔吹笛来    时间: 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
作者: 梦晓半生    时间: 2012-9-20 00:57
shengnan007 发表于 2012-9-19 08:44 ; L8 e) ?# W' O9 Z6 D% G% D+ g
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...

9 ], I8 ^: \7 S& U5 C太好了，期待中，希望都带上英文reference。
0 `# L" C: a9 N
' A8 D7 r) x2 x+ B2 B' B" W. A现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。! M: N  {7 v' V% b2 D' r
. t' n: b% l6 Z
http://en.wikipedia.org/wiki/NoSQL
作者: shengnan007    时间: 2012-9-20 08:53
梦晓半生 发表于 2012-9-20 00:57
1 Z2 ^) ?) x7 O/ X  T太好了，期待中，希望都带上英文reference。; T. {; `! [4 |9 _  W+ L

/ u# w* Z) M  }4 J5 ]现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...
7 T% h% Y4 U$ Z: I4 U
现在写的也很纠结，资料太少了，哈哈
作者: 梦晓半生    时间: 2012-9-21 11:52
shengnan007 发表于 2012-9-20 08:53 4 [6 b- i7 g: Z9 J& Y  o
现在写的也很纠结，资料太少了，哈哈
% S, {$ {3 P5 L( G% t/ c* ?6 n
建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。
- t' w* n# \& _6 `0 m) m5 f6 I4 K3 L
http://en.wikipedia.org/wiki/NoSQL
- G  R! x- V0 e- y! g! F
, J4 S2 Z9 A% p! b
作者: 定风波    时间: 2012-9-21 17:03
恶魔吹笛来 发表于 2012-9-19 18:35 2 [8 U' K5 j0 [' v
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

# Q$ ]' m1 t. h. x3 A, W有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。
作者: shengnan007    时间: 2012-9-24 09:11
梦晓半生 发表于 2012-9-21 11:52
! b7 ^& X8 k! H% d2 s; Z7 |建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。0 r3 v" ~  T5 M) N6 R) p6 t5 y* v
; o  y3 l. y  y& A& l! I  `0 Z* \/ f
http://en.wikipedia.org/wiki/NoSQL
4 y0 v6 D2 p# H& J% A# }
好的好的，现在这个写完，然后开始写nosql



欢迎光临 爱吱声 (http://129.226.69.186/bbs/) Powered by Discuz! X3.2