MongoDB架构概览

shengnan007

    关于MongoDB，我们能看到的资料，基本都是在指导大家如何使用MongoDB，但是，MongoDB内部是如何运作的，资料不是很多。
7 s- t5 _+ ]' ^
! K+ O% q% W* e/ F) }    阅读使用手册，会有很多疑惑之处。例如，有人说，MongoDB 等同于分布式的 MySQL。它把一个Table ，按 row，分割成多个Shards，分别存放在不同的 Servers 上。这种说法是否正确？
, t* `+ u' }8 E
( z$ H  G# W) X1 z    不深入了解 MongoDB 的内部结构，就无法透彻地回答类似问题。这个系列文章，就来和大家探讨MongoDB的内部的工作方式。
* L, H5 z8 t: m& Q
9 S8 e' r# ^/ i) Y5 K! W2 t5 T

图1-1 MongoDB架构图

5 a5 }1 a3 c6 W3 Q+ W9 \
    MongoDB 通常运行在一个服务器集群上，而不是一个单机。图1-1，描述了一个MongoDB集群的基本组成部分，包括若干shards，至少一个config server，至少一个routing servers（又称 mongos）。
, B: j3 t" |, u* H
) D/ ?/ n/ f: k7 ?+ Y: NShards

    MongoDB的最基本的数据单元，叫document，类似于关系式数据库中的行 row。一系列documents，组成了一个collection，相当于关系式数据库中的table。当一个 collection 数据量太大时，可以把该collection按documents切分，分成多个数据块，每个数据块叫做一个chunk，多个chunks聚集在一起，组成了一个shard。

7 y5 `  W  \1 p; \, y6 T( a    Sharding 的意义，不仅保障了数据库的扩容（scalability），同时也保障了系统的负载均衡（load balance）。

) ?( h' ^0 G! S# c/ K+ Z    每一个shard存储在一个物理服务器（server）上。Server上运行着mongod进程，通过这个进程，对shard中的数据进行操作，主要是增删改查。

+ l3 d2 l9 T$ M) T8 B    如果系统中的每个shard，只存储了一份数据，没有备份，那么当这个shard所在的server挂了，数据就丢失了。在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
# g# I) I' P7 I6 G* f) @7 S
  ~$ b* s% `2 tShard keys
. P, t9 ~* `6 k        
    为了把collection切分成不同的chunks，从而存放到不同的shards中，我们需要制定一个切分的方式。

, E# H5 C' V/ e    如前所述，在 MongoDB 数据库中，一个表collection由多个行 documents 组成，而每个 document，有多个属性 fields。同一个 collection 中的不同的 documents，可能会有不同的 fields。例如，有个 collection 叫 Media，包含两条 documents，
0 p' i/ `) V( z/ H5 D3 L5 q' [4 k
, V" G, e1 ]) J' C" y{
, {# U- P% R2 Y9 c1 v. x8 Z5 @6 F  "ISBN": "987-30-3652-5130-82",
  "Type": "CD",
  "Author": "Nirvana",
. v! {/ \7 h) D% Y" ~9 L$ ]  "Title": "Nevermind",
  "Genre": "Grunge",
3 Y, g7 z2 y4 O7 q' U   "Releasedate": "1991.09.24",
% {) }5 ^. a# j   "Tracklist": [
     {
4 L3 Y, C% P, \+ k  g        "Track" : "1",
        "Title" : "Smells like teen spirit",
        "Length" : "5:02"
     },
4 u2 m8 D3 k7 e8 E) U     {
        "Track" : "2",
, ^# m% R$ _, s) Q' `" a! i/ h        "Title" : "In Bloom",
1 U; X0 ?5 h9 R4 ^" A        "Length" : "4:15"
+ }/ V/ R" c; t     }
+ A2 n7 p$ P% B) u; b& P   ]
" R# X- y6 r5 \0 F  Q8 Y( |}
* d0 j( `# _: Q8 ^! A4 i, f
{
3 {8 r& ]% F( l. P5 ?- K  "ISBN": "987-1-4302-3051-9",
  "Type": "Book",
. Q  v/ i. m, ]0 ~, A  "Title": "Definite Guide to MongoDB: The NoSQL Database",
& b6 z  T6 j7 A# ^+ F5 R  "Publisher": "Apress",
) c2 K. T! V1 S1 B5 G0 s; h  "Author": " Eelco Plugge",
  "Releasedate": "2011.06.09"
}
0 ]7 @% ~! W9 W
    假如，在同一个 collection 中的所有 document，都包含某个共同的 field，例如前例中的“ISBN”，那么我们就可以按照这个 field 的值，来分割 collection。这个 field 的值，又称为 shard key。

    在选择shard key的时候，一定要确保这个key能够把collection均匀地切分成很多chunks。
& N8 m: b, T& `
6 O9 p! I  H' J/ z- R# G    例如，如果我们选择“author”作为shard key，如果有大量的作者是重名的，那么就会有大量的数据聚集在同一个chunk中。当然，假设很少有作者同名同姓，那么“author”也可以作为一个shard key。换句话说，shard key 的选择，与使用场景密切相关。
3 t( |' w. ~* T- l7 @. J
    很多情况下，无论选择哪一个单一的 field 作为shard key，都无法均匀分割 collection。在这种情况下，我们可以考虑，用多个 fields，构成一个复合的shard key。

5 U6 i5 E2 i: r+ u3 ?    延续前例，假如有很多作者同名同姓，他们都叫“王二”。用 author 作为 shard key，显然无法均匀切割 collection。这时我们可以加上release-date，组成name-date的复合 shard key，例如“王二 2011”。

1 P5 Q6 s& b' j$ o% c: \5 D( b+ \  UChunks
. a6 u+ C5 ~! D% I. j* m        
    MongoDB按 shard key，把 collection切割成若干 chunks。每个 chunk 的数据结构，是一个三元组，{collection，minKey，maxKey}，如图1-2 所示。

# d: H% O1 f  Q图1-2 chunk的三元组

# S" M$ `8 G' O. ]6 s9 {2 j    其中，collection 是数据库中某一个表的名称，而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值，决定了这条document应该存放在哪个chunk中。
/ h( q7 f6 `! {+ X1 t% r( p
6 A) _$ s' }- V8 g! D+ e* y$ U4 M    如果两条 documents 的 shard keys 的值很接近，这两条 documents 很可能被存放在同一个 chunk 中。

" E. g" n4 a8 `8 T$ J- K    Shard key 的值的顺序，决定了 document 存放的 chunk。在 MongoDB 的文献中，这种切割 collection 的方式，称为order-preserving。

: J: k; I5 M  v/ F) B9 w; ^    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量，接近这个阈值时，一个chunk会被切分成两个新的chunks。
6 B+ R/ y+ ]7 Q4 @0 q/ o
) F8 f" x3 y" l7 d0 c& d    当一个shard存储了过多的chunks，这个shard中的某些chunks会被迁移到其它 shard中。
; \: ^$ g0 G' {
    这里有个问题，假如某一条 document 包含的数据量很大，超过 64MB，一个 chunk 存放不下，怎么办？在后续章节介绍 GridFS 时，我们会详细讨论。
! R+ @8 q. X8 T8 q* g1 f" \
Replica set
" M6 E+ s. ~  p8 ~3 U4 e        
5 [/ X$ u$ X4 U7 B  t& l    在生产环境中，为了保证数据不丢失，为了提高系统的可用性（availability），每一个shard被存储多份，每个备份所在的servers，组成了一个replica set。
3 v, @* e; @5 `# X- ^2 f( L
& B( O! s+ M; [5 {' f* X* R    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性，所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后，再异步地备份到其他secondary中。
$ D! U/ O' {8 _$ J* f) ~% Y5 Q- p
    Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障。
; l0 ~7 z9 X1 U% H1 w: `
% N( f! ]2 l, {6 i% B    Replica set的选举策略和数据同步机制，确保了系统的数据的一致性。后文详述。
' _6 s2 [  P  l! `+ g  i
Config Server
) g4 O7 G7 X9 U  N8 u        
+ W4 f  Q, i% B$ `7 J& ?    Config servers用于存储MongoDB集群的元数据 metadata，这些元数据包括如下两个部分，每一个shard server包括哪些chunks，每个chunk存储了哪些 collections 的哪些 documents。

    每一个config server都包括了MongoDB中所有chunk的信息。
! ?! v2 L+ [6 w( H% ^1 ]! \% p
; _* I1 q. P* I( ?/ n1 ~8 Y" h    Config server也需要 replication。但是有趣的是，config server 采用了自己独特的replication模式，而没有沿用 replica set。

! l; h* p! ~4 I4 V+ ]& `6 a    如果任何一台config server挂了，整个 config server 集群中，其它 config server变成只读状态。这样做的原因，是避免在系统不稳定的情况下，冒然对元数据做任何改动，导致在不同的 config servers 中，出现元数据不一致的情况。
3 n8 R; c6 V. j: E+ V
" e1 N" }" Z+ {5 X+ i! B    MongoDB的官方文档建议，配置3个config servers比较合适，既提供了足够的安全性，又避免了更多的config servers实例之间的数据同步，引起的元数据不一致的麻烦。
1 x- p) ?- r& s0 x$ \6 l
/ T! k( t: p/ x1 @  c- M/ [4 ~Mongos

0 E4 n; `  ~& \# j) r9 B    用户使用MongoDB 时，用户的操作请求，全部由mongos来转发。
! y8 C  f2 f! b, T
    当 mongos 接收到用户请求时，它先查询 config server，找到存放相应数据的shard servers。然后把用户请求，转发到这些 shard servers。当这些 shard servers完成操作后，它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后，它把结果返回给用户。
/ D1 u5 }* R6 i0 k% u9 Z& ]
    Mongos每次启动的时候，都要到config servers中读取元数据，并缓存在本地。每当 config server中的元数据有改动，它都会通知所有的mongos。

& S+ t8 o2 p8 [' y    Mongos之间，不存在彼此协同工作的问题。因此，MongoDB所需要配置的mongos server的数量，没有限制。

    通过以上的介绍，我们对每个组成部分都有了基本的了解，但是涉及到工作的细节，我们尚有诸多疑问，例如，一个chunk的数据太大，如何切分？一个shard数据太多，如何迁移？在replica set中，如何选择primary？server挂了，怎么进行故障恢复？接下来的章节，我们逐个回答这些问题。
. |; ^, I) o/ ^9 r; `; q
, w( f" n0 {, K: f/ }- E3 E
Reference，
8 ]6 w4 I7 a6 Q+ v" l6 f0 e
[0] Architectural Overview
3 l2 i. {8 _$ J. X  s! ~http://www.mongodb.org/display/DOCS/Sharding+Introduction

PenPen

  V- b% Y) K3 ~7 j. C: G+ c1 f) P' V您是和邓侃一起写文章的盛楠么？

shengnan007

呃。。。是我啊。。。

shengnan007

PenPen 发表于 2012-9-18 12:40
# L' X* w) J$ I您是和邓侃一起写文章的盛楠么？

是我啊。。。这都能被认出来。。。

PenPen

shengnan007 发表于 2012-9-18 12:44
- k. q' p1 Y0 o4 f, w" L" J/ B是我啊。。。这都能被认出来。。。

这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~

shengnan007

PenPen 发表于 2012-9-18 12:47
$ {; }- _) |% p% c( D- z这篇文章我读过。开始以为是转贴的，后来再一看id就发现真相了~

( [7 y9 X% W3 S6 Z9 T7 F多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会员是么？

不爱吱声

shengnan007 发表于 2012-9-17 22:49
; }* i7 p4 a0 Y7 b) y多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写，比较慢，hoho。这里是要推荐才能变成正式会 ...

欢迎，欢迎，已经给你变成正式会员了。

shengnan007

不爱吱声 发表于 2012-9-18 12:51
. b! ~5 y) `! I  \) U# S1 \$ L# |欢迎，欢迎，已经给你变成正式会员了。

$ l% p" r0 K* \/ B9 {0 J9 p# S' K3 J多谢多谢啦~~

巴山

我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
1 C3 m5 z/ `* |

梦晓半生

谢谢。

# a& \1 w9 d4 d4 A% x1 T  r中文看得真累，大部分还是英文术语。

这应该是一个系列吧，后面怎样寻找，执行指令等开始入门，还是说的太简单了。
  E  w; @7 A* M  W5 ~0 M
现在distributed DB在那些大网站很重要，现在开始有跟已有DB分庭抗礼的苗头，不过不是那里工作的话，其中的奥妙大概难说清楚。

shengnan007

巴山 发表于 2012-9-19 03:38
我们现在的 technology stack 就是 php + mongodb，涉及财务方面的东西用 postgres。
" M, C8 ^. V9 C4 x
* t" r. I* p7 F' e ...

mongoDB作为存储是没有问题的，财务这种核心数据，还是不建议使用mongoDB的

shengnan007

梦晓半生 发表于 2012-9-19 04:21
+ N  I/ ?0 G  _谢谢。
( V) l& K4 X1 @
中文看得真累，大部分还是英文术语。

现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体系。这个系列文章的目的，是让大家了解mongoDB的基本的运行机理，这样以后使用的时候，可以知其所以然。但是由于这方面的资料很少，我也是到处找资料，写了这么几篇，再往后，就是边使用，边看源码，边写了。

profer

shengnan007 发表于 2012-9-18 12:44
是我啊。。。这都能被认出来。。。

是邓嫂么？

shengnan007

profer 发表于 2012-9-19 14:16
是邓嫂么？

  T4 p' J; a5 o3 f" @7 B& q是邓的小兵

恶魔吹笛来

有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

梦晓半生

shengnan007 发表于 2012-9-19 08:44
现在关于mongoDB的文章，大部分都是在告诉大家怎么用，涉及到内部运行机理的文章，数量不多，而且不成体 ...

5 J3 i( l8 a3 R5 {太好了，期待中，希望都带上英文reference。
. ~; x7 {. Y; t0 ?  R9 G
, }5 A, C$ e2 C5 g* \6 k现在这种新技术很多，Mongo是比较流行的一个，我这里附带一下一堆NoSQL的新系统，到最后估计会有几个胜出。
/ q3 e! F0 Q' s- S
7 T& _1 |" J9 a; D9 y$ Y; Zhttp://en.wikipedia.org/wiki/NoSQL

shengnan007

梦晓半生 发表于 2012-9-20 00:57
太好了，期待中，希望都带上英文reference。

现在这种新技术很多，Mongo是比较流行的一个，我这里附带一 ...

* K( |4 n7 i1 X现在写的也很纠结，资料太少了，哈哈

梦晓半生

shengnan007 发表于 2012-9-20 08:53
5 F8 N# q3 f8 Q) t现在写的也很纠结，资料太少了，哈哈

9 J2 T) G0 G/ \4 Y1 J3 @: }建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。

http://en.wikipedia.org/wiki/NoSQL
) l. l4 G2 R4 G; J
6 G! `* @, w9 k* S& S! r

定风波

恶魔吹笛来 发表于 2012-9-19 18:35
有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

) c  g( i2 ~! V" P4 ]# @有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢，从开心网一块迁移的。。。

shengnan007

梦晓半生 发表于 2012-9-21 11:52
建议从NoSQL写起，这是推动新数据库设计的需求关系，原始动力。
; C. \" g  v9 T  V
8 m* z6 J1 z2 U* }, dhttp://en.wikipedia.org/wiki/NoSQL

  p. g9 P' [% U! g: `) p1 M3 B好的好的，现在这个写完，然后开始写nosql