设为首页收藏本站

爱吱声

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

[信息技术] MongoDB架构概览

[复制链接]

该用户从未签到

跳转到指定楼层
楼主
发表于 2012-9-18 12:31:10 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    关于MongoDB,我们能看到的资料,基本都是在指导大家如何使用MongoDB,但是,MongoDB内部是如何运作的,资料不是很多。& I' |$ S8 X$ ^8 n. n; b) ?
" ^4 w/ v/ ?7 `% ^9 F
    阅读使用手册,会有很多疑惑之处。例如,有人说,MongoDB 等同于分布式的 MySQL。它把一个Table ,按 row,分割成多个Shards,分别存放在不同的 Servers 上。这种说法是否正确?$ o$ Q' k2 }  ]# I4 d
! u6 R5 J- h  z; h3 ~
    不深入了解 MongoDB 的内部结构,就无法透彻地回答类似问题。这个系列文章,就来和大家探讨MongoDB的内部的工作方式。
) s3 \9 z7 O, Y8 R- w% t
6 h0 P: O* J+ b% a7 O) h

& M5 R* O& B3 i1 t5 E0 C; b+ w
1 \3 I5 z/ c* G; W7 ^% q图1-1 MongoDB架构图
. `8 I  @) g  n  m! R3 O  `- N

# u" j8 s4 j) u! R    MongoDB 通常运行在一个服务器集群上,而不是一个单机。图1-1,描述了一个MongoDB集群的基本组成部分,包括若干shards,至少一个config server,至少一个routing servers(又称 mongos)。' C7 Y8 ~2 x! \% [! D
3 {' D+ D; M5 {' h5 T6 p" J
Shards
% {" p7 w# z0 B; r1 M& I' ^2 j# ]4 e! ~8 q
    MongoDB的最基本的数据单元,叫document,类似于关系式数据库中的行 row。一系列documents,组成了一个collection,相当于关系式数据库中的table。当一个 collection 数据量太大时,可以把该collection按documents切分,分成多个数据块,每个数据块叫做一个chunk,多个chunks聚集在一起,组成了一个shard。# n9 {7 v4 f4 E; ~) N1 n+ W

; q, g) |6 Z- D7 d* y    Sharding 的意义,不仅保障了数据库的扩容(scalability),同时也保障了系统的负载均衡(load balance)。
& f: n, G% r0 U
  J5 |) E5 r+ u! l    每一个shard存储在一个物理服务器(server)上。Server上运行着mongod进程,通过这个进程,对shard中的数据进行操作,主要是增删改查。  h& r: u7 |. Z# Q

1 p7 |! U: T. P& I3 z4 X    如果系统中的每个shard,只存储了一份数据,没有备份,那么当这个shard所在的server挂了,数据就丢失了。在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。  }* R  H) A9 ?) A1 |1 Z  F

1 I* {/ L3 Y2 s0 q8 B5 X. ]: P* x) N3 RShard keys
' q* z' Q( X* @  \! S        
9 S( t* m: k0 {( h3 I3 y    为了把collection切分成不同的chunks,从而存放到不同的shards中,我们需要制定一个切分的方式。
6 I5 F6 F* E7 ?& P0 f- |& [& A9 s, E
    如前所述,在 MongoDB 数据库中,一个表collection由多个行 documents 组成,而每个 document,有多个属性 fields。同一个 collection 中的不同的 documents,可能会有不同的 fields。例如,有个 collection 叫 Media,包含两条 documents,$ r& `5 {  W! R

: t8 P) u6 K- ~2 u7 ^: G0 M0 j{
3 {% l- ~- t; N/ A6 C: n  "ISBN": "987-30-3652-5130-82",
3 C5 j( k$ u; A2 m6 Q& N  "Type": "CD",
1 m5 N0 e3 ?$ t  "Author": "Nirvana",9 s8 |4 H) N: n/ T+ z7 u" i$ k
  "Title": "Nevermind",- O. b6 j( |4 q1 [2 c1 Z' o+ M
  "Genre": "Grunge",1 _& M& @3 |" u  r( T, Q
   "Releasedate": "1991.09.24",
% w2 S6 d! S& [   "Tracklist": [3 E; u* f5 V- X: L4 x
     {
8 r5 e# ^! v, S- `        "Track" : "1",: S8 h7 C& U4 {
        "Title" : "Smells like teen spirit",
7 J3 a1 S  Q# x1 g! H        "Length" : "5:02"
7 Y' D& J" b! J: Q     },
! k- q+ [2 r+ @& n7 v     {
" {# A3 n. {/ E. M& P, k8 j1 h        "Track" : "2",
2 x6 g$ v' f4 L( b3 H9 Y9 J% m. B        "Title" : "In Bloom",6 \! d* d; V4 e5 w+ Y
        "Length" : "4:15"
& m3 M0 P7 E# p! N     }( p$ p6 m! b7 [
   ]7 D( f/ s* v1 |# R8 D
}3 T" G/ O0 M( Y2 |
, `7 g0 r; b) _4 H( u+ `' G
{* A$ \( d3 J9 c/ V+ g1 k
  "ISBN": "987-1-4302-3051-9",4 T* m( A9 F2 @+ W# @
  "Type": "Book",' J% c& R  f  Z9 w
  "Title": "Definite Guide to MongoDB: The NoSQL Database",% h( w9 `2 @( {7 ]9 U; Q5 q% |
  "Publisher": "Apress",) [  c: A' b& b/ |* m) Y
  "Author": " Eelco Plugge",
( K- h: t: C1 L- L  "Releasedate": "2011.06.09"
" q* j8 J6 [9 |/ [1 s}8 Q8 L0 D3 b5 j; V2 M! j
& t2 @, M  l; T# ~! L
    假如,在同一个 collection 中的所有 document,都包含某个共同的 field,例如前例中的“ISBN”,那么我们就可以按照这个 field 的值,来分割 collection。这个 field 的值,又称为 shard key。
# u; q9 q& b1 J+ w6 w+ {5 M
1 E7 \# a5 Z$ ]4 k- Q. N    在选择shard key的时候,一定要确保这个key能够把collection均匀地切分成很多chunks。
' r% D4 R. J. P/ @: f0 w- ^# G/ o+ e/ J
    例如,如果我们选择“author”作为shard key,如果有大量的作者是重名的,那么就会有大量的数据聚集在同一个chunk中。当然,假设很少有作者同名同姓,那么“author”也可以作为一个shard key。换句话说,shard key 的选择,与使用场景密切相关。
) P  p+ [$ x8 H7 `- d0 X8 o* N; M# \
    很多情况下,无论选择哪一个单一的 field 作为shard key,都无法均匀分割 collection。在这种情况下,我们可以考虑,用多个 fields,构成一个复合的shard key。4 v' v0 }9 x0 u; y- p& E5 `' {

4 \% i& w* _3 H% w5 |    延续前例,假如有很多作者同名同姓,他们都叫“王二”。用 author 作为 shard key,显然无法均匀切割 collection。这时我们可以加上release-date,组成name-date的复合 shard key,例如“王二 2011”。
7 O# I/ Q$ s& H$ L8 A6 l. ^" {! w- f$ s+ P" Z' f; V
Chunks
: y0 b: p; b! J4 I        
4 `4 @# Z; G% ]    MongoDB按 shard key,把 collection切割成若干 chunks。每个 chunk 的数据结构,是一个三元组,{collection,minKey,maxKey},如图1-2 所示。
# `; i4 A# g7 Z- m# Y$ B: K* V
/ C* ^# l& H" {  }& z

* j8 q- L. B2 I6 h% y图1-2 chunk的三元组

4 z; l+ t5 K' R4 w" W0 S# V4 o3 E
3 C9 [5 j7 N$ C. l& a/ _    其中,collection 是数据库中某一个表的名称,而 minKey 和 maxKey 是 shard key的范围。每一个 document 的shard key 的值,决定了这条document应该存放在哪个chunk中。- d5 w! a4 z# F, k
4 F/ w; d5 U7 z
    如果两条 documents 的 shard keys 的值很接近,这两条 documents 很可能被存放在同一个 chunk 中。
- X1 |% Q+ v& Z* W# k1 Q& k+ F/ v1 _$ I/ ]3 E+ w
    Shard key 的值的顺序,决定了 document 存放的 chunk。在 MongoDB 的文献中,这种切割 collection 的方式,称为order-preserving。( {' M% H$ s3 h+ a: X9 ?$ D

' T2 F! j( V  w# Y. ?    一个 chunk最多能够存储64MB的数据。 当某个chunk存储的 documents包含的数据量,接近这个阈值时,一个chunk会被切分成两个新的chunks。
* I+ r, w& \5 P% |. l
4 F* S5 M. m2 r$ x1 u* l$ a    当一个shard存储了过多的chunks,这个shard中的某些chunks会被迁移到其它 shard中。; y6 _' s+ o9 A4 E4 o+ u0 J

. S8 I4 K, @* Q: Q    这里有个问题,假如某一条 document 包含的数据量很大,超过 64MB,一个 chunk 存放不下,怎么办?在后续章节介绍 GridFS 时,我们会详细讨论。& Q$ k- N# i$ h5 g/ a" U
7 j* ^$ j/ t; f/ w! {+ L0 d
Replica set8 O8 \- G' v8 b6 O' x
        
+ r, O5 N# k7 p9 e; A    在生产环境中,为了保证数据不丢失,为了提高系统的可用性(availability),每一个shard被存储多份,每个备份所在的servers,组成了一个replica set。
3 N1 F' ~2 g- `( v
% `! U3 v& N1 ^# D/ F% J# U    这个replica set包括一个primary DB和多个secondary DBs。为了数据的一致性,所有的修改(insert / update / deletes) 请求都交给primary处理。处理结束之后,再异步地备份到其他secondary中。- g( X7 q& G1 d0 r

/ A) r4 z9 z# q) o# T* u8 U/ J    Primary DB由replica set中的所有servers,共同选举产生。当这个primaryDB server出错的时候,可以从replica set中重新选举一个新的primaryDB,从而避免了单点故障。8 f- j1 w0 p. e; d; ~3 i
! g# Y5 y0 b0 F5 Q# \
    Replica set的选举策略和数据同步机制,确保了系统的数据的一致性。后文详述。
! I  s- X1 L& e6 d7 p) C. Z) P  V. [: [& C1 I- d8 M/ ~9 d0 }
Config Server
* T8 F! ?# d* B- m        5 C) X7 D. |+ R) z$ L+ ^
    Config servers用于存储MongoDB集群的元数据 metadata,这些元数据包括如下两个部分,每一个shard server包括哪些chunks,每个chunk存储了哪些 collections 的哪些 documents。" _4 I8 i% K: [0 ?" |3 ]
. B( `" |$ ~9 u# H- j
    每一个config server都包括了MongoDB中所有chunk的信息。
0 D8 I# K0 D0 w' L; A! H% [
1 u  `& @; v8 e' N    Config server也需要 replication。但是有趣的是,config server 采用了自己独特的replication模式,而没有沿用 replica set。+ m# ?8 l: E2 q* Y4 h8 t; f
& G6 |7 t$ }; A, h
    如果任何一台config server挂了,整个 config server 集群中,其它 config server变成只读状态。这样做的原因,是避免在系统不稳定的情况下,冒然对元数据做任何改动,导致在不同的 config servers 中,出现元数据不一致的情况。1 w9 x0 s: w. C; R7 v

; w4 R( F& |" z5 `    MongoDB的官方文档建议,配置3个config servers比较合适,既提供了足够的安全性,又避免了更多的config servers实例之间的数据同步,引起的元数据不一致的麻烦。, p5 X( k; N: S1 [4 c$ O
# N: I8 R  e$ l8 ?8 f
Mongos, n  F9 [# X8 r7 d$ j; O5 E

- Q' }% r& y& X/ G% Q* L) o    用户使用MongoDB 时,用户的操作请求,全部由mongos来转发。
- V" @& N& z$ B2 x; k2 \" l4 Z( q' ]+ S2 E, A- Z5 Z! S7 B
    当 mongos 接收到用户请求时,它先查询 config server,找到存放相应数据的shard servers。然后把用户请求,转发到这些 shard servers。当这些 shard servers完成操作后,它们把结果分别返回给 mongos。而当 mongos 汇总了所有的结果后,它把结果返回给用户。
" D' {* p+ ^8 s$ N2 j
, ~' \) h; }# X0 h0 {    Mongos每次启动的时候,都要到config servers中读取元数据,并缓存在本地。每当 config server中的元数据有改动,它都会通知所有的mongos。
; u6 _5 T# F- l) A; z, y$ K4 k, ~: M( |1 t6 c1 @. U
    Mongos之间,不存在彼此协同工作的问题。因此,MongoDB所需要配置的mongos server的数量,没有限制。
0 v: C$ t( [# h( a+ ~- h* c3 O9 k# R" X  c; r; B
    通过以上的介绍,我们对每个组成部分都有了基本的了解,但是涉及到工作的细节,我们尚有诸多疑问,例如,一个chunk的数据太大,如何切分?一个shard数据太多,如何迁移?在replica set中,如何选择primary?server挂了,怎么进行故障恢复?接下来的章节,我们逐个回答这些问题。
3 G0 d& Y  a8 C7 F2 L$ a( a; ]' e' k- ]7 n

" m+ x5 w6 M# O# o: X) \Reference,' A5 I. x& [! I) W! V9 N

6 S8 x6 C  Y/ Q9 O( c[0] Architectural Overview" u; R) F  J/ M
http://www.mongodb.org/display/DOCS/Sharding+Introduction( T/ c9 E  E. }9 _

评分

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

查看全部评分

该用户从未签到

沙发
发表于 2012-9-18 12:40:50 | 只看该作者
本帖最后由 PenPen 于 2012-9-18 12:44 编辑
/ @0 \" t7 a- g) U. K. O: s
  W" l5 m' ]5 s, @2 w8 b) g1 @0 I$ `- a/ |* W( A
您是和邓侃一起写文章的盛楠么?

该用户从未签到

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

该用户从未签到

地板
 楼主| 发表于 2012-9-18 12:44:45 | 只看该作者
PenPen 发表于 2012-9-18 12:40 - u9 `! `% m% a- g+ K7 ^% C: N
您是和邓侃一起写文章的盛楠么?
( b/ m( e0 p8 E: X  ]
是我啊。。。这都能被认出来。。。

该用户从未签到

5#
发表于 2012-9-18 12:47:20 | 只看该作者
shengnan007 发表于 2012-9-18 12:44 " Q& p/ }: U# H8 v
是我啊。。。这都能被认出来。。。

) W1 i- y+ [# {0 ]1 r- V* u这篇文章我读过。开始以为是转贴的,后来再一看id就发现真相了~

该用户从未签到

6#
 楼主| 发表于 2012-9-18 12:49:50 | 只看该作者
PenPen 发表于 2012-9-18 12:47 * K6 ^1 c: s7 l1 |( i0 ~
这篇文章我读过。开始以为是转贴的,后来再一看id就发现真相了~
( p/ T, |3 ]' _6 \; i. u: t
多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写,比较慢,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
    , c& v% |" n* W( J多谢支持。还有两篇一会帖过来。后续的还在写。边看源码边写,比较慢,hoho。这里是要推荐才能变成正式会 ...

    + b4 l2 ~6 H& B! D( r欢迎,欢迎,已经给你变成正式会员了。

    该用户从未签到

    8#
     楼主| 发表于 2012-9-18 12:57:15 | 只看该作者
    不爱吱声 发表于 2012-9-18 12:51 / r- U2 L% q" X/ d: ^
    欢迎,欢迎,已经给你变成正式会员了。
    - w3 x6 P6 V# e2 N. a7 ~" N
    多谢多谢啦~~
  • TA的每日心情
    慵懒
    2020-1-15 02:37
  • 签到天数: 1287 天

    [LV.10]大乘

    9#
    发表于 2012-9-19 03:38:34 | 只看该作者
    我们现在的 technology stack 就是 php + mongodb,涉及财务方面的东西用 postgres。* S2 K9 \8 ^  `0 P
    8 T7 @! x5 L. x% S. X0 G  R1 T

    该用户从未签到

    10#
    发表于 2012-9-19 04:21:40 | 只看该作者
    谢谢。
    7 B6 B" A% L$ P) J( L  r2 T( t8 C! [
    中文看得真累,大部分还是英文术语。
    ) z* M% s" q: n- B
    * C( V( F) N9 j9 I: p, {' S这应该是一个系列吧,后面怎样寻找,执行指令等开始入门,还是说的太简单了。
    9 C3 a* ?" j. s. K2 D8 ^4 B& B
    ; i7 B2 \4 E2 s+ {现在distributed DB在那些大网站很重要,现在开始有跟已有DB分庭抗礼的苗头,不过不是那里工作的话,其中的奥妙大概难说清楚。

    该用户从未签到

    11#
     楼主| 发表于 2012-9-19 08:40:52 | 只看该作者
    巴山 发表于 2012-9-19 03:38 ! h- l; j1 U& h' t& o+ X2 |
    我们现在的 technology stack 就是 php + mongodb,涉及财务方面的东西用 postgres。
    ) I# d- Z, c: z) D
    # Y9 A; Z9 a) }9 g ...
    : y5 F! ^  e5 S" e" i
    mongoDB作为存储是没有问题的,财务这种核心数据,还是不建议使用mongoDB的

    点评

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

    该用户从未签到

    12#
     楼主| 发表于 2012-9-19 08:44:52 | 只看该作者
    梦晓半生 发表于 2012-9-19 04:21 , @! I4 \2 D1 m9 Y1 D
    谢谢。
    ! [. H8 a' s6 b9 u4 i- i/ a" _
    ; h* i& j% g2 W$ ?中文看得真累,大部分还是英文术语。

    7 ^' ~5 d6 L# V/ `现在关于mongoDB的文章,大部分都是在告诉大家怎么用,涉及到内部运行机理的文章,数量不多,而且不成体系。这个系列文章的目的,是让大家了解mongoDB的基本的运行机理,这样以后使用的时候,可以知其所以然。但是由于这方面的资料很少,我也是到处找资料,写了这么几篇,再往后,就是边使用,边看源码,边写了。
  • TA的每日心情
    奋斗
    2018-1-6 00:24
  • 签到天数: 1 天

    [LV.1]炼气

    13#
    发表于 2012-9-19 14:16:01 | 只看该作者
    shengnan007 发表于 2012-9-18 12:44 9 Y+ U7 V; b$ [
    是我啊。。。这都能被认出来。。。

    4 s. h2 ~( i* W  Q是邓嫂么?

    该用户从未签到

    14#
     楼主| 发表于 2012-9-19 14:17:53 | 只看该作者
    profer 发表于 2012-9-19 14:16
    3 [5 @  F3 ]& X) Z! s4 Q是邓嫂么?

    ) M  g' V6 f( o# y& X5 W% [: x3 K是邓的小兵
  • 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 6 P- c- ]. V9 ]5 B$ [/ u: {5 S) Q
    现在关于mongoDB的文章,大部分都是在告诉大家怎么用,涉及到内部运行机理的文章,数量不多,而且不成体 ...

    $ w' ^* }# w1 @) M: X! K9 `3 D太好了,期待中,希望都带上英文reference。% g! ~, F0 @; r1 }! V% a
    3 u4 D2 K0 K2 n4 J: L: v# j
    现在这种新技术很多,Mongo是比较流行的一个,我这里附带一下一堆NoSQL的新系统,到最后估计会有几个胜出。* J+ B( ^# G2 s" H- ]
    ! w4 h: \0 ]8 Z) @9 T
    http://en.wikipedia.org/wiki/NoSQL

    该用户从未签到

    17#
     楼主| 发表于 2012-9-20 08:53:41 | 只看该作者
    梦晓半生 发表于 2012-9-20 00:57 " C# x& |8 g* F& j
    太好了,期待中,希望都带上英文reference。# ~2 [, ^' s8 L- t- `

    5 [: u) ^* l6 ]- a现在这种新技术很多,Mongo是比较流行的一个,我这里附带一 ...

    " r- l/ D. B( F& g5 L& A$ K9 ^5 ]现在写的也很纠结,资料太少了,哈哈

    该用户从未签到

    18#
    发表于 2012-9-21 11:52:33 | 只看该作者
    shengnan007 发表于 2012-9-20 08:53 ( z. A! O3 W; P+ ~, \$ Q
    现在写的也很纠结,资料太少了,哈哈
    8 @! W& Q  p$ `  j: |6 V6 ~
    建议从NoSQL写起,这是推动新数据库设计的需求关系,原始动力。
    ; c9 r6 ^- y- a: W
    9 w- l! W: [8 r; p5 hhttp://en.wikipedia.org/wiki/NoSQL7 \$ q0 d% P' O

    1 W9 s! P% k" i# S: K9 B* i
  • TA的每日心情
    郁闷
    2019-4-22 08:49
  • 签到天数: 38 天

    [LV.5]元婴

    19#
    发表于 2012-9-21 17:03:12 | 只看该作者
    恶魔吹笛来 发表于 2012-9-19 18:35
    & w. Y3 O/ V' c+ }: _: @& n* ~有点惊讶 居然在这里看到这篇文章 呵呵 静待大作

    . Z0 B; Q' U& q. r! t# v有什么可惊讶的邓侃在前一个爱坛版本是很早的注册用户呢,从开心网一块迁移的。。。

    该用户从未签到

    20#
     楼主| 发表于 2012-9-24 09:11:03 | 只看该作者
    梦晓半生 发表于 2012-9-21 11:52 - Y$ W0 c- s1 e% _; q1 h3 ]8 ?5 d
    建议从NoSQL写起,这是推动新数据库设计的需求关系,原始动力。
    ' {9 D2 ?, G, c, a( H* n# j# S+ \
    http://en.wikipedia.org/wiki/NoSQL

    - S5 T- Y3 g# W6 K* r好的好的,现在这个写完,然后开始写nosql

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

    GMT+8, 2026-6-28 10:11 , Processed in 0.079751 second(s), 21 queries , Gzip On.

    Powered by Discuz! X3.2

    © 2001-2013 Comsenz Inc.

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