爱吱声

标题: MongoDB架构概览 [打印本页]
作者: shengnan007    时间: 2012-9-18 12:31
标题: MongoDB架构概览
    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
8 P7 v$ L5 D& K' z( j
3 @" Z) v! T1 V% k5 A6 T8 R0 V    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？, k/ ?, L0 x- t
; |" K" k% M' u7 R. C/ B
    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。; J. Y+ `$ b/ u

4 F8 j2 n, E; p+ \. S
/ E3 \$ A, e: b6 @. n5 x! Q, Z
$ Q7 y' }% ~) S1 O% A0 ^
图1-1 MongoDB架构图
) b6 L# B7 J( [' W
7 c2 D1 }3 e7 X
    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
8 V, r/ j: B! Q; v# T: ~2 h" t2 G  \$ o. Y3 l1 n
Shards
6 {7 Z; Y& |4 D6 q' }
( }, S+ I7 [% s    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。% G# M) i5 u8 K
7 |. x1 ]2 A0 A0 N3 l' O* \2 Y* g" J
    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。9 c* M- x8 ?2 ^5 g4 D
8 L/ V- I; [* W, q6 V/ X
    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。
' h, v# O2 [7 ?0 S  T
% ]; N1 Q* e3 y8 O# Q. H8 _    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。- D4 \, @6 d4 l7 _
4 M1 d$ ~, u5 x& n  G1 {% N
Shard keys# P8 U6 N9 Y& B, C5 j, e+ }3 M
        0 ~+ S. }. `/ v' y1 p
    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
) ?" g" |( A6 A7 L5 q  @$ [, a) m9 e, X1 W$ M2 D6 A
    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，4 [0 V5 J/ G+ I" m7 n

% v/ V- V: J+ s! d{+ L( L2 v, a& W$ k! S6 Z2 G0 I
  "ISBN": "987-30-3652-5130-82",; p- A3 F$ T9 N3 x3 w$ W
  "Type": "CD",$ S, A8 L9 e  i
  "Author": "Nirvana",
! z/ u% d, {. ?6 ~% Q  "Title": "Nevermind",
, ?+ q9 b" }+ O) _4 D/ n. r0 T' o$ O  "Genre": "Grunge",* S) ^9 C1 J7 i
   "Releasedate": "1991.09.24",- v# m. u8 X2 R0 v/ }
   "Tracklist": [
" x3 ^6 }. n6 |' s& m; h: h4 {     {
% ]# Z5 u' }. F( d; N+ u; J        "Track" : "1",
) p+ m+ P3 f5 o# h& W        "Title" : "Smells like teen spirit",
0 H9 v0 B( w  G6 O5 l        "Length" : "5:02", q' L7 w7 Q! a8 b( _3 O5 U
     },2 `7 Z3 r' [+ i; U' |; o
     {
) ]1 Z3 }, w* L# A3 }8 z% E        "Track" : "2",
- h* ^, N3 ]% ^- A: H        "Title" : "In Bloom",$ \; J! \0 h. v8 N+ C6 _2 J& U# y
        "Length" : "4:15"
( b7 z: g6 P1 w4 Q& H  v5 D     }8 P6 s7 i4 W, a* o
   ]4 i" N6 q8 p0 c4 |- \* }
}
- p% |! F" \* Z5 G9 a4 w2 N' A- _. N% k7 h& y1 t
{
' ^. D+ I1 Q! q9 m8 J* n, t# {* h  "ISBN": "987-1-4302-3051-9",
; S; h) ]' Q- i) `. o. H  "Type": "Book",+ g3 x2 v! ^9 b5 a" f
  "Title": "Definite Guide to MongoDB: The NoSQL Database",! I% @- S% ^3 S* A" U
  "Publisher": "Apress",
! s, R% o& `# Y+ T. ~2 d  "Author": " Eelco Plugge",
" G6 Q0 W9 D) {* a8 R  "Releasedate": "2011.06.09"/ o* j7 {2 B; L, m, _
}
$ w7 Z/ B. l$ k" C* X) e9 K( I. `$ v1 k
    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。
8 F" B, i9 O# w6 e  |- X2 p
4 S, f7 ^+ _7 ]! j) f% F! E1 r    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。# q( _  X8 G7 j4 w, M

; t( [  u/ i: p% T- J# a, u    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
# M7 b& ]0 L, I4 h* U( n: f
( q4 k0 d8 p& o; [# C8 y- n    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。- N8 C$ w* n/ S  h- }$ @( W5 _
3 Z" K9 u3 o* H2 M2 k" ?3 x4 ]
    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。
; x9 _+ k; g1 o" m" n6 R5 e) ]0 L) Z; B- k2 q* T; _$ Y- S$ ]
Chunks
% M0 m0 k" i$ w, v        
: F  S3 }' U3 L  @5 q    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。* L& ^# I( d1 Y* s) a, ?& N
( U+ a  e1 Q9 _8 t5 g  n$ X" \

0 e* u, n$ R8 N3 P* p5 i9 q图1-2 chunk的三元组
( ?' O  @+ L$ b( G  q! Z5 V

/ c" P8 V! p7 Q    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
0 [1 G+ X% e0 P1 w, [, x0 g9 |4 g; ]; L2 R
    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。) ]8 p- t1 Q3 V: r
; D6 [" T' S. R& ]8 ?! F8 n
    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。. K% v3 ?1 P. a% j
: w9 |6 l: E- N, u5 j( S9 v" p
    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。- M0 }! C4 K, P. X! C1 o. X. A
5 \( D1 g6 J# d% [  @' z4 H% o. m! Z
    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。3 q/ ^3 F( _. d  k% q! y+ K
0 \+ T) [" L6 b: N: W9 t
    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
8 w1 r: e. J0 X, Z9 }9 ~8 w2 m+ Z" Y3 Z2 J1 c! ?8 t4 |
Replica set9 W9 K. ]0 _+ Q: [; ]* ^/ L
        6 u- f' P- n9 A4 e8 u
    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
+ ^7 |9 s3 ?! \( V  @) z& V- ^) T/ @2 K+ _: N
    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
4 v% V# N7 t4 h, K4 r  A6 ~1 a6 y" m4 A$ e: @- }$ T3 X& w
    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
) T2 y& B: F1 O" D( e2 v5 u
: C1 C% K7 i1 L2 p" f    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
3 k$ P( m& K$ O. u2 Y% p0 P+ |$ n6 c# _8 F! i7 X
Config Server
( q9 S, ]- Y! k        ' t2 V2 [; [) h) }& x  ~& D# [
    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。/ g" U6 E$ [% }1 ], j8 y# y" H  y

+ p& @! Z0 u1 Q) h9 M    每一个config server都包括了MongoDB中所有chunk的信息。6 C8 x' r$ l. x5 H( B( K6 M& Q

; N* U& t: a- D% [( R    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。* T, n6 e7 n! o$ z. o: e
4 [* s4 r4 A0 `
    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。1 D$ o9 Z) q7 P- v3 G

' ]5 x; H1 H, w* O4 B7 R    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。4 r7 B% C$ [4 V& J( b9 t
1 s- f$ z0 p. B
Mongos
. r+ [) X# k1 Q0 B' n
( ~) G0 v: V0 J! h( S+ N* D0 b' c& Z    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。' a' i/ u; L. x$ a  Q
+ V; q3 N4 [+ W% d
    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
, f1 s2 V; D3 v0 D! A2 Y6 \! \
  R; }( q/ H7 |    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
2 I7 f) X3 l  T5 y. ]: I! \. O
1 j# h- F2 t* ]2 L- B/ u' M1 W    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
: t& a2 V6 _3 V& m
% @8 s$ ~; K/ q0 [9 u9 C    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。' `7 u. _; K; o, ]# Q$ e  i

0 w- L0 f% B; h$ Y' P* M$ J# M- s0 R" l1 H, \& _
Reference，
& g  P( |- i' ]! n: ]
7 ^3 N" B% p5 k! s[0] Architectural Overview
, ^$ V% ~+ p4 O5 m. x$ _http://www.mongodb.org/display/DOCS/Sharding+Introduction
- ?0 b7 {/ |7 x; z% }2 `
作者: PenPen    时间: 2012-9-18 12:40
本帖最后由 PenPen 于 2012-9-18 12:44 编辑 ) {( f  T' m' b7 `2 C$ C7 Z* d8 I

9 c; ~1 d; @* g, A& \+ E  _7 ~2 R+ q* `3 e3 c# s
您是和邓侃一起写文章的盛楠么？
作者: shengnan007    时间: 2012-9-18 12:44
呃。。。是我啊。。。
作者: shengnan007    时间: 2012-9-18 12:44
PenPen 发表于 2012-9-18 12:40 2 _$ b+ B, [( {& a# _9 ^, {6 ~
您是和邓侃一起写文章的盛楠么？
7 ]& }" L5 M) n, a& o
是我啊。。。这都能被认出来。。。
作者: PenPen    时间: 2012-9-18 12:47
shengnan007 发表于 2012-9-18 12:44 9 ]- L. h+ W/ m* D0 ?
是我啊。。。这都能被认出来。。。

: g, c) q8 }0 z; M! a' m这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
作者: shengnan007    时间: 2012-9-18 12:49
PenPen 发表于 2012-9-18 12:47 6 e9 H. b3 w* t5 i$ K
这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
. v( f/ L- N: c4 n  O! j! b
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？
作者: 不爱吱声    时间: 2012-9-18 12:51
shengnan007 发表于 2012-9-17 22:49 + F$ b4 h" ?$ C0 l+ W* r" r8 G. G
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...
' x& ~7 g- f6 F4 R5 }9 n2 s
欢迎，欢迎，已经给你变成正式会员了。
作者: shengnan007    时间: 2012-9-18 12:57
不爱吱声 发表于 2012-9-18 12:51 ; L7 c5 |( p; T+ y, b9 r! P
欢迎，欢迎，已经给你变成正式会员了。

. f- C: J) s! K' ]. s多谢多谢啦~~
作者: 巴山    时间: 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
" R* ^8 n% L, E$ [" _6 q8 ]& t1 p4 j' A0 t( W/ O! _
作者: 梦晓半生    时间: 2012-9-19 04:21
谢谢。5 [. I# I9 l$ m

" i1 p6 N. `7 o中文看得真累，大部分还是英文术语。
* k1 t5 J) s0 m$ X) j% n
2 s0 R/ [7 f" E( Y这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
3 s& P% g, `5 _& y0 h4 r' o- U
7 u* P! X6 ]7 J$ [2 M现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。
作者: shengnan007    时间: 2012-9-19 08:40
巴山 发表于 2012-9-19 03:38 9 e+ X% G2 F% h
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
! {( L' x- }; M. Y0 ]! B# Y5 z9 z" d& L! }
...
6 n+ d* s1 i/ I+ ?" a( X
mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的
作者: shengnan007    时间: 2012-9-19 08:44
梦晓半生 发表于 2012-9-19 04:21
0 h% O  {6 }, m. S- `谢谢。
# s. g; a1 u4 K
; [$ `8 r) F+ E& L/ c+ J& ?8 Q6 o中文看得真累，大部分还是英文术语。

6 X2 g- X! O* o8 b5 o& l: }现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。
作者: profer    时间: 2012-9-19 14:16
shengnan007 发表于 2012-9-18 12:44 % }5 G0 P) `+ K* M# j
是我啊。。。这都能被认出来。。。

0 ]8 N9 m2 i1 K/ _) U是邓嫂么？
作者: shengnan007    时间: 2012-9-19 14:17
profer 发表于 2012-9-19 14:16 2 M  X) V$ {9 o3 J
是邓嫂么？
- {3 Y' D7 s6 X
是邓的小兵
作者: 恶魔吹笛来    时间: 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
作者: 梦晓半生    时间: 2012-9-20 00:57
shengnan007 发表于 2012-9-19 08:44
+ |" M* h. Q; S* v4 @' o: k现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...

; j* \: c! @& s$ e5 i" x& q太好了，期待中，希望都带上英文reference。- N0 F: p% |, u3 c+ C; V
/ v8 z4 R3 x# P
现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。# G9 }( E  a) s. G/ `

6 q! [, m5 [9 [5 dhttp://en.wikipedia.org/wiki/NoSQL
作者: shengnan007    时间: 2012-9-20 08:53
梦晓半生 发表于 2012-9-20 00:57
) U, p7 `) B6 l3 [4 \太好了，期待中，希望都带上英文reference。
. c8 T) Q5 @$ y7 S0 F: a( o; _) n5 L/ H6 v! p/ w0 c) q; o
现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...
; ?$ l# L6 s- E2 y
现在写的也很纠结，资料太少了，哈哈
作者: 梦晓半生    时间: 2012-9-21 11:52
shengnan007 发表于 2012-9-20 08:53 : ~  p8 H( s" b3 z  L, F0 p  q) \
现在写的也很纠结，资料太少了，哈哈

  Q; q6 D/ w7 U4 u1 G8 d" k建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。) P3 g4 \. v" A5 Z5 B5 M

! O7 A% M0 w1 F+ Y0 J9 ?http://en.wikipedia.org/wiki/NoSQL
# i$ v3 _6 m( H/ P% y. u) [0 t8 D, m" r$ y) I! T# ]+ U
作者: 定风波    时间: 2012-9-21 17:03
恶魔吹笛来 发表于 2012-9-19 18:35
; C. c: Y: h- e. e9 j有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

: o) u! u9 t8 }: x4 K& |# Z有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。
作者: shengnan007    时间: 2012-9-24 09:11
梦晓半生 发表于 2012-9-21 11:52 ; p. g1 a+ I" b& T8 B
建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。
7 x- l: Q' w; c% E4 R$ b
# m7 h" ?$ e+ f8 chttp://en.wikipedia.org/wiki/NoSQL

/ D& @' L; u* Y, m6 f" Z1 J+ P2 y好的好的，现在这个写完，然后开始写nosql



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