设为首页收藏本站

爱吱声

 找回密码
 注册
搜索
楼主: shengnan007
打印 上一主题 下一主题

[信息技术] MongoDB架构概览

[复制链接]

该用户从未签到

跳转到指定楼层
楼主
发表于 2012-9-18 12:31:10 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。% P- @; ?+ g3 w5 f& W

! T  t- G2 p  q5 u( n9 Z1 Z7 g4 f: X    阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?
% q3 G- R9 j. T: [3 H
$ `$ D$ ?* u# Q8 u: x4 v    不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。
5 R9 |" ?. V5 e  D$ q( |( {
3 A' L/ W) S6 `) O- ~/ J

4 ~: _' n1 G. z
" q+ p: J/ `& C. U; b9 N图1-1 MongoDB架构图
% i9 p1 P+ n& s; a. _0 K5 I- M

0 E" x! A0 v1 m6 ^    MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。
+ c: O* i# B  Q& w
% y. F, K0 G& N5 I5 n3 n4 BShards
: J1 A+ u+ _. N9 o1 K3 j; C- k* ]1 O% Y3 \. X+ S
    MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。  V6 h' U5 v( o
& }+ D: {3 n' O; A, a! B
    Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。* F5 C/ G  I3 e
& p$ ~. h$ P+ [" }
    每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。
5 _5 Q7 w8 B! m$ M* P
! K. M, p4 J' k; t    如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
4 a) |9 E7 l$ J' T& U' V
7 Q" |$ v8 F/ S( u+ C/ P+ ~Shard keys
. ~8 i8 x1 u' H* m( q1 C% G        ! f; b% o- ~1 ]: c0 p5 X
    为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。( G* T3 F4 g9 O) p8 n( W

$ ]+ |2 m; v% v: O* E+ B    如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,
- k; `7 U9 o* u/ g1 L1 E6 X) v! k" v, ?; J4 n# g% ]+ R  N% Z; ~
{
5 k' J+ o3 \' |( ~0 j1 l  "ISBN": "987-30-3652-5130-82",. i7 ~6 t2 j! l9 }; a" o, @
  "Type": "CD"," D/ X- ~% ]# L/ B
  "Author": "Nirvana",& d" S. Q/ @. ^- Y
  "Title": "Nevermind",$ F- m' o! D1 |& J) L! g  |& o
  "Genre": "Grunge",
" r0 G' }: s* S% }: `0 e- Q! s   "Releasedate": "1991.09.24",8 D( ~- r/ p' f" p4 s/ ~" P$ Y3 D. {$ m
   "Tracklist": [
9 Y4 V" i& k9 m- i4 B0 b     {
3 ^* b" e" V1 z7 P; d; z) @* ?6 u        "Track" : "1",
9 m$ ~9 t2 r: r- Q/ b- E# ]        "Title" : "Smells like teen spirit",5 q1 b! |) d2 V  e, R1 i# ^$ c
        "Length" : "5:02"- W. J: ~2 F. W( f0 C6 ^8 Y
     },% b/ x2 n: v7 ^7 @$ w  s
     {  v! h. P5 M+ B" P/ P. m) [
        "Track" : "2",
4 F: y' j* A2 S, |$ o  E: M        "Title" : "In Bloom",
* F, J* G* r. ?/ g, ?        "Length" : "4:15"
2 f6 g: R  d. u0 U1 [1 v% ~3 C     }; j& f0 z& J" q0 l! @" i
   ]
+ W) a3 L  T6 y0 A* Q}
5 [" F' Z1 {: ?8 t  t$ ]" E! z3 s3 X
* U- w. L2 I0 F0 t' G{- H% \( P% F( V0 `4 n
  "ISBN": "987-1-4302-3051-9",0 H- H7 v; f! E' A
  "Type": "Book",# B! p  t. W, c: p' H
  "Title": "Definite Guide to MongoDB: The NoSQL Database",
4 I: e7 t# T5 x, P' {2 P) f5 o  "Publisher": "Apress",
! @1 D9 \0 a3 }! m/ K  "Author": " Eelco Plugge",8 M, E' s8 v# n
  "Releasedate": "2011.06.09"
, o, _3 I9 k# L, h6 ?}3 I0 B7 \5 y7 c* ^& Q% h

; @2 O: Z- W& }. n* F    假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。
7 ]  ~; Q6 {5 G: {" @
% `* V- X7 r& V  {6 o" v    在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。$ c! @6 D6 |4 r+ B7 O
) L/ @4 ^3 W3 Q$ S
    例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。
  `4 K5 r1 n( q. ?* T0 n0 R4 P
+ l/ q5 K. u6 ~- h* y    很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。
. ?9 d5 q: f# D6 e+ @7 c0 J/ M; V! M+ @( l
    延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。
1 z0 j* |! S  o- `" W# e
1 A; B9 d4 F3 J7 W8 w- xChunks
; j# y6 Q% x0 O3 q/ y4 M8 ~        
! c: t/ s% e4 Y9 X    MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。
8 o+ @% i4 ~9 j$ D' u+ l* C* |  e; g. ?5 @+ V
% N% z7 W, l, d8 r2 x) w
图1-2 chunk的三元组

' G& j  y, J3 `9 j
3 V7 o) J) a; d) V. N    其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。& n0 U0 X# m( G: r( b4 \
1 S; s1 D3 N9 Y
    如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
* w- q6 B7 t3 P3 L' {/ m3 ]
6 x# }6 s  J3 K% D4 G    Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。; K- l& a' l. c6 I& ^2 P5 t7 O

2 ^) ~$ z% q+ Z' Y, j9 B( q    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。
* T) B  ]' N  A! Q( c* O, k4 X
( j3 r/ M8 f7 a5 J' e    当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。
: b7 }' L) Q& l/ P6 B9 g2 Q7 F3 p& S# p: j& @
    这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。
" k2 C) W- o( P& e* X' S
- k" U+ w1 e4 X+ s9 x3 n1 TReplica set' |+ i& q3 K' i4 n' w9 c
        
# }/ A7 [' I3 n* M( W9 @* Y! z    在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
( G2 R) `1 O: c
3 l: K7 f9 t3 a; M& Q    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。
# D) W+ D3 W% Z& L6 p
7 Q4 {) [, F* x7 e$ F7 z: V/ [* _    Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。, Q9 Z% c7 k" ]/ i; ?

3 r; r. ?  r% O0 [    Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
; o' ?; w* C, B  T& |- o  B6 @  ^5 E: R/ b. {1 I
Config Server: `4 q; y# V: Z$ P3 G  i  h
        
# K* H( F  d: N9 V( H, d    Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。
; n) v8 I) z! ^2 h& Q
/ {9 ^- E: d$ w, _0 z. u    每一个config server都包括了MongoDB中所有chunk的信息。! s# B  [& X8 X7 k2 k* L$ U
. d9 s  c6 z- s3 K# Z
    Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。6 a0 O/ P( g4 b7 Z

! ^" [0 X/ r- K    如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。( v$ L; ^7 E0 y! w$ g- L

8 G. B' C. Q( s7 k1 N. i    MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。
$ k# x0 R, R, |5 M$ A1 u8 V/ L# I. F% i- J; [9 W( |/ x
Mongos$ n9 W3 X4 r8 R! o: ?0 \

0 J: n' x. V1 i    用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。
  h9 ^8 ^5 u; ?; P6 I$ [% o5 w/ I0 O8 D4 o8 X
    当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。
9 B. v6 H) z: n
; c5 ^( j) B  W3 A$ I    Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。8 ?' C9 w4 {/ D6 C' u+ ?
/ p  J) ^0 {$ L/ U: N/ u- z1 |
    Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。$ v6 l' c. M: \

0 s' _! i7 V- V    通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。8 ?- B/ k+ z* R. }: p
6 k4 s, d& H% \- ?7 ]* q
& F2 a  K: d/ ^/ J5 F0 P
Reference,! z, Y3 \0 a' ~

4 W2 |  {2 ]# I- m3 U% h. j[0] Architectural Overview
5 f' N! S) ~: W, g" r7 ?/ Ohttp://www.mongodb.org/display/DOCS/Sharding+Introduction: G2 p+ |$ d1 D3 b0 g- c* R

评分

参与人数 1爱元 +10 学识 +5 收起 理由
不爱吱声 + 10 + 5 谢谢!有你,爱坛更精彩

查看全部评分

该用户从未签到

沙发
发表于 2012-9-18 12:40:50 | 只看该作者
本帖最后由 PenPen 于 2012-9-18 12:44 编辑 * K6 V6 h* i4 \+ Y0 S& Y

# b' N( J- V5 v% e) A* n" `1 w% t* R* X- {
您是和邓侃一起写文章的盛楠么?

该用户从未签到

板凳
 楼主| 发表于 2012-9-18 12:44:19 | 只看该作者
呃。。。是我啊。。。

该用户从未签到

地板
 楼主| 发表于 2012-9-18 12:44:45 | 只看该作者
PenPen 发表于 2012-9-18 12:40
1 E6 I1 t$ Y: ~# J) s- Q% Q, k您是和邓侃一起写文章的盛楠么?

7 y. D3 U/ H' Y4 n* {( L, ~+ a是我啊。。。这都能被认出来。。。

该用户从未签到

5#
发表于 2012-9-18 12:47:20 | 只看该作者
shengnan007 发表于 2012-9-18 12:44 . r9 g  p" j: R! T+ a: [
是我啊。。。这都能被认出来。。。

- M2 }* X+ A7 K7 A  }4 R这篇文章我读过。开始以为是转贴的,后来再一看id就发现真相了~

该用户从未签到

6#
 楼主| 发表于 2012-9-18 12:49:50 | 只看该作者
PenPen 发表于 2012-9-18 12:47 . ]( l$ o# M9 U0 r  J
这篇文章我读过。开始以为是转贴的,后来再一看id就发现真相了~
7 o, C! o, L- G$ f
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写,比较慢,hoho。这里是要推荐才能变成正式会员是么?

点评

你已经是会员了~  发表于 2012-9-18 12:50
  • TA的每日心情
    奋斗
    2022-2-8 01:13
  • 签到天数: 171 天

    [LV.7]分神

    7#
    发表于 2012-9-18 12:51:42 | 只看该作者
    shengnan007 发表于 2012-9-17 22:49 7 u# H' D4 N" Z6 B  y; O0 R- I/ d; s
    多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写,比较慢,hoho。这里是要推荐才能变成正式会 ...
    + d/ e3 t0 U! R" @$ s7 d8 t
    欢迎,欢迎,已经给你变成正式会员了。

    该用户从未签到

    8#
     楼主| 发表于 2012-9-18 12:57:15 | 只看该作者
    不爱吱声 发表于 2012-9-18 12:51
    $ g  H4 t4 t( i, g9 ~1 b欢迎,欢迎,已经给你变成正式会员了。

    , H  ?7 ^+ a! t, G( M多谢多谢啦~~
  • TA的每日心情
    慵懒
    2020-1-15 02:37
  • 签到天数: 1287 天

    [LV.10]大乘

    9#
    发表于 2012-9-19 03:38:34 | 只看该作者
    我们现在的 technology stack 就是 php + mongodb,涉及财务方面的东西用 postgres。
    ; a) W/ o- I( s4 B! V
    - D7 S1 ~8 y! [+ t

    该用户从未签到

    10#
    发表于 2012-9-19 04:21:40 | 只看该作者
    谢谢。6 Q8 N+ c7 c7 ^. b; l
    . Z, J4 g8 X  W! V1 X0 g5 {
    中文看得真累,大部分还是英文术语。
    6 L2 v* U9 p; g; m) {
    + V( g6 V% K4 J' y3 n这应该是一个系列吧,后面怎样寻找,执行指令等开始入门,还是说的太简单了。
    5 C  S1 }; z$ N0 O$ X
    5 r2 c' X( K( U8 U$ m$ N现在distributed DB在那些大网站很重要,现在开始有跟已有DB分庭抗礼的苗头,不过不是那里工作的话,其中的奥妙大概难说清楚。

    该用户从未签到

    11#
     楼主| 发表于 2012-9-19 08:40:52 | 只看该作者
    巴山 发表于 2012-9-19 03:38 5 l  w* @* X' L6 |- q4 z0 F- [, Z
    我们现在的 technology stack 就是 php + mongodb,涉及财务方面的东西用 postgres。  P' m$ s7 y1 q& d) A( e: k' h
    - o5 m6 ^3 `! w2 G1 Z) j. w( w7 A
    ...
    + S& o' I& m0 u0 U1 m& x
    mongoDB作为存储是没有问题的,财务这种核心数据,还是不建议使用mongoDB的

    点评

    主要是transaction acid的问题。  发表于 2012-9-27 17:12

    该用户从未签到

    12#
     楼主| 发表于 2012-9-19 08:44:52 | 只看该作者
    梦晓半生 发表于 2012-9-19 04:21 - _; {+ r0 ]4 s7 W+ ]
    谢谢。
    2 B! c! L& y) P9 d% N; }* i/ T9 ?! ]; x! i* w& L4 w9 d  ]0 A" G& y  D' ]
    中文看得真累,大部分还是英文术语。
    ( x( J- o& c* j* ?
    现在关于mongoDB的文章,大部分都是在告诉大家怎么用,涉及到内部运行机理的文章,数量不多,而且不成体系。这个系列文章的目的,是让大家了解mongoDB的基本的运行机理,这样以后使用的时候,可以知其所以然。但是由于这方面的资料很少,我也是到处找资料,写了这么几篇,再往后,就是边使用,边看源码,边写了。
  • TA的每日心情
    奋斗
    2018-1-6 00:24
  • 签到天数: 1 天

    [LV.1]炼气

    13#
    发表于 2012-9-19 14:16:01 | 只看该作者
    shengnan007 发表于 2012-9-18 12:44
    7 R! {/ H; }8 b) N是我啊。。。这都能被认出来。。。
    $ K6 h* M. w) I5 o( i
    是邓嫂么?

    该用户从未签到

    14#
     楼主| 发表于 2012-9-19 14:17:53 | 只看该作者
    profer 发表于 2012-9-19 14:16
    : {* k3 `, b! x$ m是邓嫂么?
    4 q6 A' @/ Y  G  C0 p6 V3 s5 T) l( x
    是邓的小兵
  • TA的每日心情
    奋斗
    2019-9-9 20:24
  • 签到天数: 1 天

    [LV.1]炼气

    15#
    发表于 2012-9-19 18:35:28 | 只看该作者
    有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

    该用户从未签到

    16#
    发表于 2012-9-20 00:57:50 | 只看该作者
    shengnan007 发表于 2012-9-19 08:44
    9 [2 p, V) {" x现在关于mongoDB的文章,大部分都是在告诉大家怎么用,涉及到内部运行机理的文章,数量不多,而且不成体 ...

    ( ]- D. D  G+ t8 J太好了,期待中,希望都带上英文reference。
    0 c" g6 R2 O0 }6 Z$ T) D4 G" f( \' ~. U) s9 X4 U  S% J" Y7 w& V
    现在这种新技术很多,Mongo是比较流行的一个,我这里附带一下一堆NoSQL的新系统,到最后估计会有几个胜出。2 M0 N+ f7 P! B. h
    9 Y+ A  Z8 J9 O- C/ J0 m7 p, R
    http://en.wikipedia.org/wiki/NoSQL

    该用户从未签到

    17#
     楼主| 发表于 2012-9-20 08:53:41 | 只看该作者
    梦晓半生 发表于 2012-9-20 00:57 ! Q: _1 s# s1 _( `" {7 U, r& _
    太好了,期待中,希望都带上英文reference。
    ' j0 A/ f) Z2 g2 P
    % l. C* x: i( e% P9 _现在这种新技术很多,Mongo是比较流行的一个,我这里附带一 ...

    + Y3 o1 U; U0 x4 M+ d7 y& w$ F现在写的也很纠结,资料太少了,哈哈

    该用户从未签到

    18#
    发表于 2012-9-21 11:52:33 | 只看该作者
    shengnan007 发表于 2012-9-20 08:53
    % P; d% M1 E' f5 r0 k( R$ |; Q) v现在写的也很纠结,资料太少了,哈哈
    ( D, {$ x: B: G
    建议从NoSQL写起,这是推动新数据库设计的需求关系,原始动力。) P' c3 Q/ ~) t/ b7 d9 s- W0 W

    # f+ O8 e2 J7 Whttp://en.wikipedia.org/wiki/NoSQL
    + j2 [* P- n9 `4 K
    0 g+ S6 X- Y+ u2 D8 _+ K0 Q6 E
  • TA的每日心情
    郁闷
    2019-4-22 08:49
  • 签到天数: 38 天

    [LV.5]元婴

    19#
    发表于 2012-9-21 17:03:12 | 只看该作者
    恶魔吹笛来 发表于 2012-9-19 18:35
    ' O% B+ `* y) ^2 d! s7 Y* o9 O( V有点惊讶 居然在这里看到这篇文章 呵呵 静待大作
    # D0 W  y( M. B2 C; T$ K4 d6 C$ O
    有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢,从开心网一块迁移的。。。

    该用户从未签到

    20#
     楼主| 发表于 2012-9-24 09:11:03 | 只看该作者
    梦晓半生 发表于 2012-9-21 11:52 2 L" _, `2 y7 C1 J: \
    建议从NoSQL写起,这是推动新数据库设计的需求关系,原始动力。7 ]7 {" ?+ W0 i! G
    # X' u5 v7 {% e$ x
    http://en.wikipedia.org/wiki/NoSQL

      `* R2 {2 y, `: H3 h+ Y好的好的,现在这个写完,然后开始写nosql

    手机版|小黑屋|Archiver|网站错误报告|爱吱声   

    GMT+8, 2025-12-25 00:40 , Processed in 0.044791 second(s), 22 queries , Gzip On.

    Powered by Discuz! X3.2

    © 2001-2013 Comsenz Inc.

    快速回复 返回顶部 返回列表