爱吱声

标题: MongoDB架构概览 [打印本页]
作者: shengnan007    时间: 2012-9-18 12:31
标题: MongoDB架构概览
    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
" D/ L; U0 }7 w4 @5 @& {; r: v) r2 o& D, }
    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
5 W. u  X0 W- j5 Q5 D% ^0 m+ r+ v! p0 m3 B
    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
# _, t# u) Z& ]1 ^9 m/ H& z3 \* ^2 _/ i0 s$ x' A: G
9 s9 K. \7 [/ C( [4 e7 ^& X
. F+ W, N9 \$ G9 v) ?0 a: s
图1-1 MongoDB架构图
$ ?; S0 L! P. p  q* B
" P2 m* N  X' X
    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。3 a% p1 c3 J+ p6 K$ e0 T# B

" c6 I$ h$ F, \9 P0 u" b& B( aShards
' q  j# W4 L2 h& x& U
$ ]. H, x/ b3 Q" x    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。! s( b! ~' O& ~1 H
: O! k, n7 N6 V2 D# A; ?; q' J
    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。. |& Q4 j6 |, j+ \* v6 M5 x6 O
" b& e; B2 I3 {; s1 Y6 Q
    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
# {9 c! g/ _8 N7 h% Z
, k3 [) h0 e- ~& V5 c    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。0 L" W5 u) _( Q0 ~  ~

4 c  J5 i( y: S3 Y, W) UShard keys
6 y8 V1 u+ ^$ x        ) _7 E9 M; C" L4 z* G2 x
    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
, M9 L; a5 U! A4 C: p
9 J  O  y( [% N    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
6 N9 J$ q$ t+ E, s5 B2 F! `  q5 v
{/ K5 F8 c2 t2 e: h" J
  "ISBN": "987-30-3652-5130-82",
- b& t# Q6 F  K& j; {% C  "Type": "CD",
" b! G5 m" e$ X/ G9 T# x  "Author": "Nirvana",6 v1 L1 I5 ^/ @2 j
  "Title": "Nevermind",
, _" o3 u3 U/ G- B5 V  "Genre": "Grunge",* F, I/ C' ?( j. }
   "Releasedate": "1991.09.24",! P5 O6 s/ a/ ]9 J& @& a: l0 X4 n7 O
   "Tracklist": [
1 [9 `1 G: {5 q     {
  }/ o$ p; @, Y6 O        "Track" : "1",
) P% S  [4 g; ~! p" A4 G. @        "Title" : "Smells like teen spirit",( A' e$ v* O6 e8 r
        "Length" : "5:02"* s! V; E3 d7 l  D) C" J! s
     },  v6 i  ~7 v# h0 m
     {
/ Q) W* h; X4 o% W# ~& v/ s; W        "Track" : "2",8 F4 N  s$ v. ?0 E2 v
        "Title" : "In Bloom",+ f' z" v( B9 f9 _, M4 ?( T% L1 d# @
        "Length" : "4:15"
3 X' U3 d( G) Y) T2 o     }
7 p7 Q$ G5 n# Y) Y& e) G) @   ]
: z+ I" p* \7 d8 b5 g: J}
: S+ Y9 k% v7 a( v6 t
" i' U; ]( [, ^( g4 N0 a' s2 b{
  K- t  |) p8 s  "ISBN": "987-1-4302-3051-9",
0 P) t8 s* v7 {- _2 z  "Type": "Book",
1 O: w$ ?! T, P  "Title": "Definite Guide to MongoDB: The NoSQL Database",
% a& \- w4 m1 m" Q' v; |; F' i  "Publisher": "Apress",
, Q) I4 {( {2 }' {2 _: R  "Author": " Eelco Plugge",
0 w* s, Q4 u# l: S  d  "Releasedate": "2011.06.09"; z& U9 T! e, s6 `4 W
}
1 ?  G9 u! q0 k4 q; t! _
2 ?6 ^) x0 B7 c9 W    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
* \, b% ~2 R8 [* Q
. w: ]) y# B3 ?6 W- h0 h    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
" ?0 e8 b' d% j/ ?. b
2 m& ^' G$ ]- o- p    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
1 g" H$ [6 X9 `% U# m/ W1 M9 _, o, e' p& k$ W/ p: L' ]2 k
    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。8 v) Z! S* Q* Z! }1 [( W+ V
6 _! F! j5 ~* j! e; ]
    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
, [/ {0 C; a* |9 E" \1 v: V
9 k, E( i, b) q) G$ ~4 U3 fChunks
) z2 c% m, v3 h8 L* m$ u: n$ `$ n        
# A) x' j) k( i/ L    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
" e* J3 J. c4 Y" S4 {# x2 V, K% _3 f* h+ [, e" c
! A# n4 r( u( ~- Y
图1-2 chunk的三元组
5 J7 o8 D4 a9 H* z
1 n! U1 @" b3 x
    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。( S3 J3 W* U8 f$ O8 W
' C: [( ^, F, P7 u# J2 K# c
    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。
: j" S- ]; J; A! C% {4 U1 _& y* d4 C+ e
    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。; J% A" w0 d8 q) u/ F( k: v
; z, q' o" t9 W  l
    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
% b! x2 X3 T) P7 n0 N  s$ V! R4 T
    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
$ F" a2 c( @5 G) N( r8 s* o* z3 O4 a1 O9 b9 y+ u: \
    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。2 Q6 i/ T. m, C$ W) y6 j

' T' f$ p8 j6 l3 ?, w8 f4 gReplica set+ p( }0 i) X! U* {
        ' _/ s; x  k1 ?
    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。* k- N5 U0 Q. t& n1 t1 k
/ C4 E$ [4 n. k
    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。3 @# p: o+ V8 ]0 G
9 F( D; [) ?  q  D
    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
- `6 ^2 ^' ^' r* @
- F/ B$ c( ~4 t    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。2 E& {8 T% G, F: D! o( d& D1 [

7 {) R) S  }2 ~, xConfig Server8 A9 |& R/ w! W6 V6 e, G
        . S( m* g" F/ f# `! ^+ ?
    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。1 d  D; Q  Y/ D2 k7 `" D7 O
  T8 d; Z& v7 C/ G1 @0 N6 N" O- s; D
    每一个config server都包括了MongoDB中所有chunk的信息。: q$ L% k+ _3 k+ C$ n; [
: @( M+ F- J, y" `$ ^* @! g9 ?
    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。' R' F. d9 `( D% S% _1 ~
5 ~* |# }/ J! t0 x& n
    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。' `2 j/ K  D3 w5 w
- s0 {) q" S! E# M$ e
    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。9 h" B6 U* A! z; d+ e" V4 S
: K, `+ ]9 k6 ?5 C/ ]* M5 O% k
Mongos
7 }0 s$ o: @# Z, x9 o1 F- V
! K7 r- H1 R7 D    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。1 ^5 E- Q/ n  M, H9 g' Y6 X

% t! x, G6 U# I    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。: R. h8 A# J4 I7 f2 u5 P) e

) ]+ u* b9 j0 L6 A( ^( _1 F  W2 V    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
! ?4 Z+ U( S2 u6 m# u5 g8 c4 F& }- w
8 [- ]8 U+ `. i+ {, q6 s+ W1 p) A    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。! i  s5 I+ y" U+ v( x, O/ @/ z

8 g: T5 m2 f0 K0 ?' e  V    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
- K( a& c- a3 Y: }( L6 e, `& ^( z  x* Z. r# x

3 O0 J) W) [9 m' T+ y  d, N( [Reference，- E, N9 t4 L2 P: |9 J
5 @- \1 I' S( V9 p7 T
[0] Architectural Overview
! y1 z8 F/ B7 U2 F2 A/ S, Q0 ohttp://www.mongodb.org/display/DOCS/Sharding+Introduction# ]9 x1 a* U0 Z2 w  U: Z
作者: PenPen    时间: 2012-9-18 12:40
本帖最后由 PenPen 于 2012-9-18 12:44 编辑
$ }# S( Q- b4 h  M, X  T
5 R6 @/ y0 i' P; E/ I1 l! {3 w
3 d  y# c+ M8 w# Q2 j+ \您是和邓侃一起写文章的盛楠么？
作者: shengnan007    时间: 2012-9-18 12:44
呃。。。是我啊。。。
作者: shengnan007    时间: 2012-9-18 12:44
PenPen 发表于 2012-9-18 12:40
  D, v/ K# Z9 ^您是和邓侃一起写文章的盛楠么？
6 |# R+ o. g1 h8 E6 N
是我啊。。。这都能被认出来。。。
作者: PenPen    时间: 2012-9-18 12:47
shengnan007 发表于 2012-9-18 12:44 , Q6 {, i7 k5 M" v1 T8 d
是我啊。。。这都能被认出来。。。
/ b8 `% f; T. @1 `
这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
作者: shengnan007    时间: 2012-9-18 12:49
PenPen 发表于 2012-9-18 12:47   X; I1 H" A5 }1 ?
这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~

. L5 O$ a& }9 V' b* f; q4 o2 v多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？
作者: 不爱吱声    时间: 2012-9-18 12:51
shengnan007 发表于 2012-9-17 22:49
  ]" v, x# J0 S1 v7 O1 H% q3 {! E多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...
8 |/ F' W; O/ o: e
欢迎，欢迎，已经给你变成正式会员了。
作者: shengnan007    时间: 2012-9-18 12:57
不爱吱声 发表于 2012-9-18 12:51
  U. l: j- |# Z% p7 c" h4 I1 A+ s欢迎，欢迎，已经给你变成正式会员了。
  x$ G& d5 f/ R' P  L
多谢多谢啦~~
作者: 巴山    时间: 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。7 g/ h! {# f1 B$ p
6 m8 ~$ q1 ?0 d# `& S# T. v1 H
作者: 梦晓半生    时间: 2012-9-19 04:21
谢谢。. u# t" t+ K2 w) q
  @- g+ J# T; r3 a
中文看得真累，大部分还是英文术语。
0 W6 i0 L. {) ^: z; e, z; W3 O$ Z
这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
$ o6 r! |+ e  h9 u- G: T( B6 Q" V* M$ c; Y0 ?5 O
现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。
作者: shengnan007    时间: 2012-9-19 08:40
巴山 发表于 2012-9-19 03:38 ( @) L$ b+ _8 h
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。) m/ H: x' m+ \, m& L: |, i

+ p% @3 O$ [' m( o& O+ x ...
6 T+ n# V% [6 B2 I
mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的
作者: shengnan007    时间: 2012-9-19 08:44
梦晓半生 发表于 2012-9-19 04:21 " ^! y( h3 ?2 o% F! B1 r' w
谢谢。  k; i) W2 {% n$ a  S. v0 b/ ?/ h

" \* Q. I$ z. @中文看得真累，大部分还是英文术语。
9 G  Z9 s+ f. m0 h9 J
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。
作者: profer    时间: 2012-9-19 14:16
shengnan007 发表于 2012-9-18 12:44 0 a. `8 F; W4 [, ]% \
是我啊。。。这都能被认出来。。。

# h6 _1 I' G, m" J: z( E" [* C是邓嫂么？
作者: shengnan007    时间: 2012-9-19 14:17
profer 发表于 2012-9-19 14:16 7 i. S: E* d% U! u. h3 t
是邓嫂么？
( U) x4 P' Z7 V
是邓的小兵
作者: 恶魔吹笛来    时间: 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
作者: 梦晓半生    时间: 2012-9-20 00:57
shengnan007 发表于 2012-9-19 08:44 ) q  O8 _" Q3 _( J/ N! p( _/ I5 Q& P. Q
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...
( f6 P- @0 s  N) ?2 ?
太好了，期待中，希望都带上英文reference。6 i! i+ @8 l: g7 C# {4 b+ g

% V8 R8 o. h) Z7 M; f! u) o现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。
0 [  q6 s5 V! K) n; ~. O- }7 M% c. O1 C+ S8 I+ Z' A
http://en.wikipedia.org/wiki/NoSQL
作者: shengnan007    时间: 2012-9-20 08:53
梦晓半生 发表于 2012-9-20 00:57 8 W( g2 k% |' J* c) @" Q
太好了，期待中，希望都带上英文reference。: l6 s9 b; M% }' @3 z% S

% t' ]; }9 c- z. a8 a# A4 z现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...
/ j9 ~# i, s* M& F
现在写的也很纠结，资料太少了，哈哈
作者: 梦晓半生    时间: 2012-9-21 11:52
shengnan007 发表于 2012-9-20 08:53 / p6 u+ q& ~0 n% q& X
现在写的也很纠结，资料太少了，哈哈

! E! \) S8 ?2 r8 \4 s+ m9 O; Y建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。; b; ?. U1 o5 Y1 P

5 A" g% V% G/ }5 q# v# i) Vhttp://en.wikipedia.org/wiki/NoSQL; C3 Z- ?6 P9 B4 B) d+ d3 W
% C/ J' i9 ?, f: V
作者: 定风波    时间: 2012-9-21 17:03
恶魔吹笛来 发表于 2012-9-19 18:35 0 ~$ }1 U! z/ r2 Z# ?; d8 B2 l: G
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
5 H. I0 C  n7 l' z
有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。
作者: shengnan007    时间: 2012-9-24 09:11
梦晓半生 发表于 2012-9-21 11:52 % n, h* r1 p$ X3 n+ ^/ r
建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。8 o: W( U, B* H8 w) J. x/ c) J  B' }

0 U% d0 ^. B$ L. Shttp://en.wikipedia.org/wiki/NoSQL

' T% B& n& S0 b0 |, N好的好的，现在这个写完，然后开始写nosql



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