爱吱声

标题: MongoDB架构概览 [打印本页]
作者: shengnan007    时间: 2012-9-18 12:31
标题: MongoDB架构概览
    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
1 K1 F. b% j! z$ g- k  G8 M8 a6 G3 F% u6 k- R
    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
$ z/ C- \2 U- w3 g6 [8 N* k. f3 S% o( V1 b) l% @$ X6 q
    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。; {# E5 b6 ]- X$ Z- N, Y

# ~( r0 o; [# ~; i+ ^8 ]6 v

( C; ]  d; H+ r0 Z3 U$ X1 q+ r
" W9 C' v6 i) ?图1-1 MongoDB架构图
, G( h7 X+ n) D; Q1 b) p! v

; H% `* f2 Z- l! F" X8 s    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
. c9 n! ]( H: n9 `0 e. z; e, V: }2 r/ W
Shards0 Z; t! s/ I; p# C
+ N* M. X! h+ F. ]( }2 m$ x3 `* i
    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。; |' R) ~$ s2 E# A6 ?

8 N* m8 }1 ?( ?# r    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
6 Y' J/ Q/ |$ Y% J! M6 a+ ?# f* B
    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
8 {/ ?0 l; J9 E
+ d: `- e4 C: M7 w+ u- r: n    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
# R' L  x% `5 L6 E: j5 J" k  B, j+ v! l& O  M
Shard keys% v, r7 |. b/ M) p# k( E$ ~
        9 T% Q0 K3 K3 T! d0 ]
    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。  K: N" ^6 c, d2 E# a

$ }" [0 s/ ^8 k/ o/ R    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
7 e$ `( x/ u2 T4 A
; Z+ l' E( y) [- d+ P{
% G: u) v9 E. T4 s5 {7 z  "ISBN": "987-30-3652-5130-82",
2 I- E+ h+ {( T/ Q, c( b$ a# U  "Type": "CD",
7 Z. z, ]4 v2 |1 k  K  "Author": "Nirvana",( o. I; u0 \! X. d  k3 W
  "Title": "Nevermind",
) n4 c7 Z& B; q% k$ w) P- J/ _  "Genre": "Grunge",) x( B+ |, ~* q/ A+ b2 `: N$ z' J$ g
   "Releasedate": "1991.09.24",9 \4 F0 y( Q$ R9 n9 r
   "Tracklist": [  M, l$ l7 t- V
     {
& A- T: W9 p5 j$ F2 E        "Track" : "1",; L! L+ W- Z- t
        "Title" : "Smells like teen spirit",
% w. D  f5 S* f) U        "Length" : "5:02"
1 f2 C4 b5 Q- G+ H- {     },; r0 h: @# s* C: [
     {' h* ^6 g" r! C9 C( Z# O
        "Track" : "2",
. j- y9 s/ m: h, {        "Title" : "In Bloom",% Q1 _* \' o' ]7 M) m7 c! @
        "Length" : "4:15"
# X# r6 g5 I6 h, ~. n1 ?     }
# [5 E7 S$ l7 z8 S2 m7 C$ O3 y   ]: w/ W9 {2 C' W, n6 G1 Q
}! V7 B& J0 Z: u/ Y' Y

- {- @% H1 t- o0 \, k( A{
" g* p5 [3 ]% H) H! }/ _" }& P, S3 i  "ISBN": "987-1-4302-3051-9",
" \- t0 V7 C( w8 X6 f  "Type": "Book",* V. t9 n; d1 A; G( o7 ~
  "Title": "Definite Guide to MongoDB: The NoSQL Database",
( A4 @1 u  f! X  O& K  "Publisher": "Apress",
  W. z) G4 R3 K, {; y  "Author": " Eelco Plugge",- ]" t/ `) l: w8 h/ Z
  "Releasedate": "2011.06.09"" W3 k8 l* C  _+ b, E+ q
}
' h# T  {& M" F# \" y& c7 O8 J4 A& M  O& O' A# g+ g
    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
5 }& e; {  u7 |) q5 W4 Z5 P& W/ R
) q; `9 B( F4 N) o) z    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
" C' g$ s9 P; b& S  ~) F! V/ K0 h0 _/ E: B" C, K) P2 W
    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。3 {* Z! V/ ^! h) T" b

& E" _5 k9 V% G  g    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。) Z! W6 @3 \+ y! y" d9 _8 n! }  _

+ [4 {7 m% p* a+ K    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。+ S9 w! S) y, t7 K4 u: |
2 ?& E$ D" }8 i4 O# i( K5 s
Chunks( h, i1 @$ n# Z: l" e8 ?0 L# b
        
0 {$ q- H1 `- {4 X# j8 c    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。8 a7 Q% R( i  S7 r

: r4 V6 s$ l8 L8 A1 |

3 P9 z4 T5 f4 o4 @6 Y图1-2 chunk的三元组
7 L, K& @/ s/ j$ Q5 W2 Z) H, {* `
7 C# Y* [( j1 d/ E7 j: f: W9 M
    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。" y3 {7 x& j' c" }* j2 p

8 q6 H& K9 W1 E4 M" t" Z- X    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
; e! W+ e/ U: G6 q- F6 Q- h
: ^0 U& h  I% C2 W1 k1 H! i    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。" D- ]) `& D4 G7 x! |* n. M; C0 l

& p- S; C  y, d    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
' a0 i! j" |$ u  I3 J& t
9 _5 H  x; |- H    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
8 N3 A7 n  P) G* {; ~
5 V. z4 _) }6 u3 `    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
  D& ?, e4 p4 e  C) f) M" d$ A: f; Z8 R. J, X( _/ }9 w
Replica set' C1 X5 S: Z* X( h
        
; S/ B4 e; @, v    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
; K& U4 h4 b! I
! ]8 o3 D$ B/ o- Z5 d1 H* l    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。$ N8 ]' G5 f% H- R
6 X* F' N& i9 d, A8 n- L) {
    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
; K$ E* Y3 D% C, v' R4 |" }$ S, C" g+ c& ^6 N  J6 r
    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。, e9 j0 @1 R) y) ^

5 C( Q' c/ S8 l, N6 CConfig Server4 ~4 ~% F: y. @2 ^/ X; I
        / E% r6 \% ~! l$ r% E; N* ^, U
    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。
$ Y; g! V: T- }# r0 v6 O; l: S3 r; C' Z, ^2 _& N
    每一个config server都包括了MongoDB中所有chunk的信息。
/ l* e! h6 t$ M4 ?% U. S
4 A/ ?4 G# m' k- S, u    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。* v; A* n% H. D' q# _' a( d7 P
2 T: G! n. X1 p8 r& @- w# e
    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
9 c1 C) f& E7 o  |) Z% G
# F* @4 p) }, y+ p. X0 y% {9 Q    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
; f! S5 f3 J8 t3 G% H# w* X2 ~4 \$ L8 l" {* D
Mongos8 }1 S9 v$ x" P/ r, ?" y- l% S( j5 N

: I# J; W% s/ }# r+ z, Z% k    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。4 I% \+ R) P' b9 h1 d' k2 ]( ]' n

! N* f9 S3 d3 X5 f: R4 B    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
: [0 z2 d* l5 d7 l) q/ e
3 b; H  v/ o% e6 O    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。) ?* X4 j! Z& ?+ q6 g( c( K' A
5 c3 j4 Q/ s9 S% `
    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。% L; d8 h; s; J. [* K; a0 f

% G1 S9 W2 M1 h- f9 q" O. b# q" l9 D, D    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。# i3 q/ d( ~9 `4 J9 b, f

7 L. W& A9 \' e: C' j7 E+ ?. y' v
8 f7 R+ d% x% C4 b2 cReference，
' {, V. s4 ]9 T6 D: e$ f+ L( M' J9 Y' q2 h/ |
[0] Architectural Overview
" X- r. o7 q4 hhttp://www.mongodb.org/display/DOCS/Sharding+Introduction
8 |- P4 G: L/ U' m
作者: PenPen    时间: 2012-9-18 12:40
本帖最后由 PenPen 于 2012-9-18 12:44 编辑
, C7 i' t* D/ m! l, V' i- w
% G" l( A. c% w0 }" o# j* f
7 r# [9 {9 V0 L* ^. Q您是和邓侃一起写文章的盛楠么？
作者: shengnan007    时间: 2012-9-18 12:44
呃。。。是我啊。。。
作者: shengnan007    时间: 2012-9-18 12:44
PenPen 发表于 2012-9-18 12:40 6 C6 B, E& S( K* O
您是和邓侃一起写文章的盛楠么？
" ~4 ~3 q: X. A! F
是我啊。。。这都能被认出来。。。
作者: PenPen    时间: 2012-9-18 12:47
shengnan007 发表于 2012-9-18 12:44 6 D. [2 w" X- x  ^9 H3 _/ x& W$ m
是我啊。。。这都能被认出来。。。

: ], q( d5 w8 V1 h6 k7 @# N这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
作者: shengnan007    时间: 2012-9-18 12:49
PenPen 发表于 2012-9-18 12:47
) l9 e9 G+ @" H$ `+ W这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
9 |, s  p5 o( j  h0 j! T" x: t
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？
作者: 不爱吱声    时间: 2012-9-18 12:51
shengnan007 发表于 2012-9-17 22:49
+ ?4 i9 b3 L7 J多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...

0 r! ~) h; ^. f! [, U4 f欢迎，欢迎，已经给你变成正式会员了。
作者: shengnan007    时间: 2012-9-18 12:57
不爱吱声 发表于 2012-9-18 12:51
& C/ J" S# o9 w& C; m0 m$ B" q欢迎，欢迎，已经给你变成正式会员了。
( A# k0 I  q( P+ D; U
多谢多谢啦~~
作者: 巴山    时间: 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
4 i8 W* T; F  N- K3 i' |% Z- j' ~; I+ ~" C7 `" n
作者: 梦晓半生    时间: 2012-9-19 04:21
谢谢。
7 A# |4 W' ~5 \8 J6 M) U9 ~0 {1 r. Q
' f, _- c0 T+ k& X  o6 r2 T% y( B9 G中文看得真累，大部分还是英文术语。: f) W, q9 x6 n8 p3 a6 ]

) n& B0 @- ^' Z: e这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
3 l! {9 I/ Q$ [1 L7 F( h
( Q- |8 E% |8 {3 R' E9 s* Y现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。
作者: shengnan007    时间: 2012-9-19 08:40
巴山 发表于 2012-9-19 03:38
+ a6 B& i3 l. g: W( d$ ~, r我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
- K9 p* ?* l' G, `5 j4 h( w# L4 Z# L  v  x% N$ {
...
$ ^% X, a) ]" \! }3 t% |
mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的
作者: shengnan007    时间: 2012-9-19 08:44
梦晓半生 发表于 2012-9-19 04:21 ! x5 o( `1 w: b. i0 K
谢谢。
$ p" B* u% d; ?/ m7 a) N; v9 R, k7 b7 B/ [
中文看得真累，大部分还是英文术语。
# i0 V+ ]) @1 Z6 j  K% }$ L# V
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。
作者: profer    时间: 2012-9-19 14:16
shengnan007 发表于 2012-9-18 12:44 / B, c( l: g: v$ K
是我啊。。。这都能被认出来。。。
0 u! [; Z7 n) j, V2 S
是邓嫂么？
作者: shengnan007    时间: 2012-9-19 14:17
profer 发表于 2012-9-19 14:16 " U# p" S$ Y. ^. B8 L) U; h
是邓嫂么？

/ v3 p& U% C+ c& Z) U是邓的小兵
作者: 恶魔吹笛来    时间: 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
作者: 梦晓半生    时间: 2012-9-20 00:57
shengnan007 发表于 2012-9-19 08:44
4 a5 s" C7 P4 S+ P现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...
. F* ^! X" A; p5 U% o6 `4 S$ K
太好了，期待中，希望都带上英文reference。% F" S3 s+ C5 [( O/ S
/ h6 w/ m$ g: y6 o. ^
现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。' ?; z& [% b+ u

2 A) g8 ~1 [9 ~! |: Hhttp://en.wikipedia.org/wiki/NoSQL
作者: shengnan007    时间: 2012-9-20 08:53
梦晓半生 发表于 2012-9-20 00:57
9 O& ]4 l) s# w1 Y! V, }太好了，期待中，希望都带上英文reference。
; R8 ~0 f) e- p  K6 J6 H2 e/ _( t" S" m8 d- |
现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...

' y' v5 Q* c8 a现在写的也很纠结，资料太少了，哈哈
作者: 梦晓半生    时间: 2012-9-21 11:52
shengnan007 发表于 2012-9-20 08:53 & g# I6 g# {* e
现在写的也很纠结，资料太少了，哈哈

9 |9 A$ c$ z; S建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。
1 c1 @* Y- B6 G7 u
0 v0 @8 l5 ~( |; V% uhttp://en.wikipedia.org/wiki/NoSQL
) t* i9 b  }0 n. i" y( p) e- _# O/ X' R1 A# L: e$ S3 N$ q
作者: 定风波    时间: 2012-9-21 17:03
恶魔吹笛来 发表于 2012-9-19 18:35
/ F' _. w; t3 k! ^& _8 }5 K有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

8 y& r% R$ a0 C有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。
作者: shengnan007    时间: 2012-9-24 09:11
梦晓半生 发表于 2012-9-21 11:52
; n6 P# I+ C6 q& v, ]# l* G建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。; o9 J! w2 ]/ ?2 Y

3 w* Y2 ^& Y$ @" Lhttp://en.wikipedia.org/wiki/NoSQL

. W6 G+ F3 E' Y7 P好的好的，现在这个写完，然后开始写nosql



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