爱吱声

标题: MongoDB架构概览 [打印本页]
作者: shengnan007    时间: 2012-9-18 12:31
标题: MongoDB架构概览
    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
; k' |0 h. D; L' v! D: W8 A" _6 z8 K4 z2 u/ P  q6 Z
    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？7 ]* A: v+ j  y) T$ g
/ |% u4 i  _3 _' h1 }  A
    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。% U- R" r4 _5 O; s1 ^

1 A4 _  [4 N7 p8 v
+ }. x. P8 D" p: ^3 I4 N1 L  q

& m, [1 F: c# p5 M图1-1 MongoDB架构图
5 |: [* B) O3 w+ q6 s( O
& f$ A, z" f9 \/ B0 b" U' o
    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。9 a' f) M! F2 X. @! S2 c3 ?
9 i% V) M5 F8 @  \# M
Shards
6 F3 D7 s3 M9 K- B6 ]! d  J, R5 Y$ z/ l9 s& J* V2 Q# v; p, e
    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。
( n2 p# R- x' |. S" c5 q- [
3 s) w4 M2 g( y* y" S4 b    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。
3 i7 d: p% [: L) _  y; D( }  b. Q6 h1 n  U  G
    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。2 i0 E* B* _7 [( o6 O6 w5 B/ \

0 v9 K) K. L7 ?    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
  u! X# N2 O% a; i, a9 R6 _5 H+ b; O1 ?. E5 Z3 S
Shard keys
, [0 l" i) Z+ }, F" u/ ^        
4 f% I4 ~5 t$ L& M) [    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。
. a4 B& t4 B9 @  B" ~; h, ~6 n: {
% Z) m: A5 x: Y+ b& r9 R7 i& [    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
/ {% z/ u( d  x* A
/ {. r5 w" w8 q8 D" g1 g{
/ i+ g& g7 i# n, C3 J  "ISBN": "987-30-3652-5130-82",) Z1 t/ T) g, n; |8 T
  "Type": "CD",* x' G# ~+ T! J4 I( K7 [
  "Author": "Nirvana",, b) r$ {6 o8 ], [3 M8 U: C4 A
  "Title": "Nevermind",
' J5 w2 @( V( B! E. E4 I  v9 \  "Genre": "Grunge",
% Y! o8 ^+ ^2 h  r+ \' E5 o& J   "Releasedate": "1991.09.24",
/ e6 ?& L; t/ g- y   "Tracklist": [; k/ i! u8 ~6 v  I
     {3 v& \, ~2 A3 u* I  x$ ^6 D! t' \
        "Track" : "1",
( F& Q7 ]( D3 U& H( [1 V        "Title" : "Smells like teen spirit",
" Q3 I$ V8 f7 E. O! F3 f        "Length" : "5:02"/ C4 W! Y; J. {& e+ d9 ?6 B
     },
% N+ n! d  E3 r     {: _& b5 P, X/ ?
        "Track" : "2",; w$ e! l. Z+ O( V# H
        "Title" : "In Bloom",+ Y, }5 E' E# t1 Z+ A' Q" U
        "Length" : "4:15"5 _8 B3 _$ h6 P+ c1 F5 U0 Z1 f( o
     }
7 I: W1 P2 @. P2 o/ `2 {   ]
; c! h& ], g: B! V& J% J% h6 _4 S}
2 @1 b) [# Y. X$ ~; F. b: w2 ^) m5 k: \- V$ V
{
" J$ X  j$ \7 ~; v  "ISBN": "987-1-4302-3051-9",
. D0 `) l1 E' d* ?- B; j  "Type": "Book",
: ~  ?2 V$ x& r* s# e" C  "Title": "Definite Guide to MongoDB: The NoSQL Database",
7 E3 `0 N& N& s5 B2 D2 ~  "Publisher": "Apress",( R, P3 C0 u; j5 L9 B9 i, h
  "Author": " Eelco Plugge",
" v4 V$ v9 }6 p! R- V6 S  "Releasedate": "2011.06.09"" O* y, ?, Y6 P, f( I7 h7 ^9 R
}
  r) m: \& C0 u' v6 L0 z
8 i4 n% {- i8 u6 Q0 N) q    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。! z# {, z' Q& [: X2 f, f
" l0 m3 f9 a- Y7 a5 l: O( \$ k
    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。- b5 n+ D' S. ~0 D
0 g" \+ F7 A9 h7 M' N( H7 c/ S
    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
" D0 w' @8 @% Q
1 `4 b6 D! L$ g  ~+ }" E    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。/ L: s, U* |5 y! f; T! f2 q! j

+ j3 _% e6 w7 N7 G    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。6 V8 V" ?, P" O; v6 m1 N5 a' U
5 W6 M& z+ O3 g* \* X
Chunks
( m! b. S0 I1 m) B, a/ C        
4 E$ m; [9 R3 _& w# W$ s. s    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。
1 j4 m; F- g/ ?' {: B# e: g2 H7 F
' f. }% }5 k; j5 t3 }# a& p
$ @& s7 s5 U5 W1 L
图1-2 chunk的三元组

9 O8 t4 F* V8 L% x( Q3 X
/ J4 D; f! ^2 F- j    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
' M: Z# T! l) q5 r: h6 x% K7 V, U( t/ k5 m6 _8 F
    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。* [( W0 N* n; Y& W' }& f
- c6 {0 b8 u( h9 L8 m0 E4 X
    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。
/ |/ u( b6 l+ ]+ X6 t) k, E4 U6 N& r0 l% T" k# _
    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
% V9 [4 d! n$ a, I. J( e5 a8 \  X; N4 \: U% h
    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
% b8 M: {! c  H
9 u6 v) c0 O; e    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。7 F+ Z! y, {2 D2 P

- a# r' ^& b2 K2 TReplica set
$ D- D/ J' x/ X$ v        6 u; Q, y4 S" u
    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
+ P$ }2 V( E; U- j4 A* `( @6 J! S# J+ `" S4 @- R/ `% @+ H
    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
. U# P4 n3 Y% v: F; K' r& e) Q/ g) l) E  g+ E5 B/ L
    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。& `3 c  M$ e5 K* B

, `2 k( @3 ?4 q! K    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。" j8 o/ s- T1 u

7 M  z4 J- a3 C9 P! c" O% H+ jConfig Server  n( }: y" x1 k( @' i1 x6 j
        : I& n0 @8 j1 ~) `
    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。2 q8 Y2 A; ]7 J4 U

! z9 i+ e% E" p    每一个config server都包括了MongoDB中所有chunk的信息。% |& N4 p+ F! j* S; s& |
3 E# m% k% d) S, [- Q- }  B- l
    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。% Y. Q" `4 Q% U  \- U
( A7 s' V' Z2 W# v' w/ s" n
    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。4 c, d, x' i( @0 I5 B

, Z# X6 ]/ R7 a0 S, w) [    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。2 X( V; c# y6 l8 n

4 K* `% c" X9 Q4 O3 fMongos0 a. }& [( P- L: G5 k! k
8 i9 y2 i4 q7 Z
    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。9 G: N5 [1 G7 @( |
8 J2 n% f6 O4 E+ ?+ W& R
    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
! `7 T1 D: y, x5 Q$ k: ~
- R5 @9 ~' r6 l! V2 @( ~$ n& J    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。
/ @8 g3 e. c0 B& Z5 w! f6 s$ K/ i6 x7 B) ~2 z1 a: R, V
    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。
2 d0 B' b$ y# E8 `4 T3 }$ N! s# e
* r8 E) O. s) v: V    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
$ f( w$ ^' f$ f: f) Z+ t
7 b1 I- U* q! Y: l- Q/ x) c. B5 X# u; x- ^4 J* k
Reference，
4 x  X" Q, y" L* A% C
' I4 N% Y. T% k3 e1 e' K+ L  v* L[0] Architectural Overview( h) k0 j' O# |' q* y3 E
http://www.mongodb.org/display/DOCS/Sharding+Introduction
8 T9 t4 V3 B1 j
作者: PenPen    时间: 2012-9-18 12:40
本帖最后由 PenPen 于 2012-9-18 12:44 编辑
$ C  e0 Z9 H' E: M  ~7 H  Z/ i1 v, N5 Q( s

$ e0 M! t% d) q# k6 P  H& i- n您是和邓侃一起写文章的盛楠么？
作者: shengnan007    时间: 2012-9-18 12:44
呃。。。是我啊。。。
作者: shengnan007    时间: 2012-9-18 12:44
PenPen 发表于 2012-9-18 12:40
  J8 m/ [- D% s' F您是和邓侃一起写文章的盛楠么？

- U' Y. q; l) R1 `9 K是我啊。。。这都能被认出来。。。
作者: PenPen    时间: 2012-9-18 12:47
shengnan007 发表于 2012-9-18 12:44
; ?9 f" Z( d$ h- u0 a是我啊。。。这都能被认出来。。。

( `- r/ {  s$ s& p- m; Y这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
作者: shengnan007    时间: 2012-9-18 12:49
PenPen 发表于 2012-9-18 12:47
  b# ^, h* b$ B1 ^: F* ~7 i这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~
) }/ \, h- |  i
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？
作者: 不爱吱声    时间: 2012-9-18 12:51
shengnan007 发表于 2012-9-17 22:49
4 ^+ u1 W* [$ z2 Z, g多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...

# X9 \( A) {& l  u欢迎，欢迎，已经给你变成正式会员了。
作者: shengnan007    时间: 2012-9-18 12:57
不爱吱声 发表于 2012-9-18 12:51 6 C+ D2 e7 W4 }4 y* C
欢迎，欢迎，已经给你变成正式会员了。
; k' L- T- O4 G* I
多谢多谢啦~~
作者: 巴山    时间: 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。* c* r: Z- M8 }7 D* H+ [

, W4 \1 D  s, A( x/ z9 z
作者: 梦晓半生    时间: 2012-9-19 04:21
谢谢。
: q, E# L9 c( R& k) p) X
% [8 R4 S3 R3 P# g, N0 V' E中文看得真累，大部分还是英文术语。+ \; |; I' n3 A6 ]9 v/ O& c& y0 f

7 h( `9 y* R( c这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
; v4 n: I; u  U3 r, X( S: v( L) Y. F
现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。
作者: shengnan007    时间: 2012-9-19 08:40
巴山 发表于 2012-9-19 03:38 2 A( |: Q) Z# ?! Q- Z
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
. C7 S7 H5 b& `5 }7 R
$ ~% S9 d7 y( r; K+ B ...
% s: z! c+ n: k9 ?6 q/ k/ q0 `
mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的
作者: shengnan007    时间: 2012-9-19 08:44
梦晓半生 发表于 2012-9-19 04:21 ; A& Z9 d5 g' {3 G- D8 |* ~
谢谢。
% ]6 R$ ]. ?6 W4 B$ ]
; M9 L: k; s: ^中文看得真累，大部分还是英文术语。
! o0 {' l  V% r, |$ M
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。
作者: profer    时间: 2012-9-19 14:16
shengnan007 发表于 2012-9-18 12:44
; C) C+ i  ]/ C是我啊。。。这都能被认出来。。。
: Q% p) S. u- R- P
是邓嫂么？
作者: shengnan007    时间: 2012-9-19 14:17
profer 发表于 2012-9-19 14:16 + O; n' f1 e: H# T+ ?! J
是邓嫂么？
- S7 r! q" t$ n" X: g, ]$ s9 e1 K1 F
是邓的小兵
作者: 恶魔吹笛来    时间: 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
作者: 梦晓半生    时间: 2012-9-20 00:57
shengnan007 发表于 2012-9-19 08:44 % u& G8 r8 H& z% B
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...
- Q. Q  Z  E% I( H0 t3 z5 Q4 l) i- M
太好了，期待中，希望都带上英文reference。' `3 _; ]0 ^& h: C& M0 _8 m
+ v/ O% m2 V+ w7 M0 p, Z0 {/ n
现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。4 U7 m1 _3 ^8 W8 J* r$ G

+ M  I, f* ~+ j0 ghttp://en.wikipedia.org/wiki/NoSQL
作者: shengnan007    时间: 2012-9-20 08:53
梦晓半生 发表于 2012-9-20 00:57
" l  D/ Z; T2 e3 n( \& Q5 z: ]太好了，期待中，希望都带上英文reference。, r" i( L+ y$ ^

* c, @+ x# I! {6 ^" v现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...

$ o& F! ~0 _3 X  T1 m- r* D% e; m现在写的也很纠结，资料太少了，哈哈
作者: 梦晓半生    时间: 2012-9-21 11:52
shengnan007 发表于 2012-9-20 08:53
* g- ?0 [1 [9 D# u5 Q现在写的也很纠结，资料太少了，哈哈

; F9 `3 g3 f! l' Z/ F4 f  W建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。
5 e$ x& }# i% X
6 J! k9 S/ S. \# r3 W$ L" }# ?) d* Phttp://en.wikipedia.org/wiki/NoSQL* q5 E- ?: a+ p9 a! l1 c
, R, d- c" H; M) z. P
作者: 定风波    时间: 2012-9-21 17:03
恶魔吹笛来 发表于 2012-9-19 18:35
% S# s8 ?. z/ M有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
7 S5 s0 T; l8 o$ B
有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。
作者: shengnan007    时间: 2012-9-24 09:11
梦晓半生 发表于 2012-9-21 11:52
2 g. a, C# l! @+ D5 U; K建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。9 F9 f4 |. G  h& {0 D/ `  _

2 P; Z" Q& f* F6 zhttp://en.wikipedia.org/wiki/NoSQL
& K  q2 V; w4 {! c
好的好的，现在这个写完，然后开始写nosql



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