君子博学而日参省乎己 则知明而行无过矣

博客园 首页 新随笔 联系 订阅 管理

转载自 http://www.cnblogs.com/spnt/

当MongoDB整个架构已经部署好以后,真正考验架构者能力的时候就到了:该如何选择片键。

如果选择了一个不恰当的片键,他可能会在访问量变大的时候,使你的整个应用系统崩溃,同样好的片键可以构成一个良性的生态系统,根据需要增删服务器,MongoDB会确保系统一直正确的运行下去。

咱们先看看几种不恰当的片键

1,小基数片键

    假设我们有一个存储用户信息的应用程序,每个文档有一个continent的字段,存储用户所在地区,其值有:africa,antarctica,asia,australia,europe,north america,south america。考虑到我们在每个州都有一个数据中心,并且想从人们所在地的数据中心为其提供数据,我们决定按该字段分片。

     集合开始于某个数据中心的一个分片的初始块(-∞,∞),所有的插入和读取都落在这一块上,一旦他变得足够大,就会被分成两个块(-∞,europe)和[europe,∞),这样一来,所有来自africa,antarctica,asia和australia的文档都会被分到第一块,其他的都会被分到第二块,随着更多的文档被添加到数据库,集合最终会变成7个块,如下

   (-∞,antarctica)

   [anrarctica,asia)

   [asia,australia)

   [australia,europe)

   [europe,north america)

   [north america,south america)

   [south america,∞)

然后呢?

MongoDB不能再进一步分割这些块了,快会越来越大,虽然暂时不会出问题,但是当服务器硬盘空间被用完的时候,你就没办法了,只能购买新的硬盘,悲剧的是硬盘是有极限的。

  由于片键数量有限,因此这种片键称为小基数片键,如果选择了一个基数很小的片键,到头来肯定会得到一堆巨大无法移动也不能分割的块,这时候做维护做扩展是什么感觉,你懂得。

 如果是因为需要在某个字段上做大量查询而采用小基数片键,那就需要使用组合片键了,一个片键包含两个字段,并确保第二个字段有非常多不同的值供MongoDB用来进行分割,比如大部分的查询都和时间关联,可以用时间字段做第二个字段,又可以减轻负载。

2,升序片键

从RAM中读取数据要比磁盘取快,所以目标是尽可能多的访问内存中的数据。一次,如果有些数据总是被一起访问,我们就希望能够把他们保持在一起。对大部分应用来说,新数据被访问的次数总比老的多,所以往往会使用如时间戳或者objectId一类的字段来分片,但是这并不想我们期望的那样可行。

 比如我们有一个类似微博的服务,其中每个文档都包含一条消息,发送人和发送时间,我们按时间来分片,让我们看看MongoDB会如何运行

  首先还是一个大块(-∞,∞),文档会全部插入到这个分片上,然后开始分裂,比如(-∞,1294516901),[1294516901,-∞)----(使用的是时间戳),由于是从片键中点把块分开,所以在分割开快的那一刻开始,说有数据都会插入到第二个块上,不会在插入带第一个块上,一旦块二被插满,他会在分割成两块,但同样的只会在最后一块插入数据,这种情况会一直持续下去,这就造成了一个单一且不可分散的热点。在网站高峰期可见这个点上的压力。

3,随机片键

    有时为了避免热点,会采用一个取值随机的字段来做分片,采用这种片键一开始还不错,但是随着数据量越来越大,他会越来越慢。

     比如我们在分片集合中存储照片缩略图,每个文档包含了照片的二进制数据,二进制数据的md5散列值,以及描述等字段,我们决定在md5散列值上做分片。

    随着集合的增长,我们最终会得到一组均匀分布于各分片的数据块。目前一起正常。现在假设我们非常忙而分片2上的一个块填满并分裂了,配置服务器注意到分片2比分片1多出了10个块并判定应该抹平分片间的差距,这样MongoDB就需要随机加载5个块的数据到内存中并发给片1,考虑到数据序列的随机性,一般情况下这些数据可能不会出现在内存中,所以此时的MongoDB会给RAM带来更大的压力,而且还会引发大量的磁盘IO。

   另外,片键上必须有索引,因此如果选择了从不依据索引查询的随机键,基本上可以说浪费了一个索引,另一方面索引的增加会降低写操作的速度,所以降低索引量也是非常必要的。

那么怎么样的片键才是好的片键呢?

从上面的分析可得出一个好的片键应该具备良好的数据局部性,但又不会因为太局部而导致热点出现。

1,准升序键加搜索键

     许多应用程序都是访问新数据更频繁,所以我们希望数据大致按时间排序,但是同时也要均匀分布,这样一来既能把我们正在读写的数据保持在内存中,又可以均衡的分散在集群中。

     我们可以通过像{coarselyAscending:1,search:1}这样的组合片键来实现,其中coarselyAscending的每个值最好能对应几十到几百个数据块,而search则应当是应用程序通常都会一句其进行查询的字段。

  举个例子:有个分析程序,用户定期通过他访问过去一个月的数据,而我们希望能尽量保持数据易于使用,因此可以使用{month:1,user:1}来做分片,现在来说说运行过程

   首先一个大数据块((-∞,-∞),(∞,∞)),当他被填满,MongoDB将自动分割成两块,比如:

     ((-∞,-∞),("2012-07","susan"))

    [("2012-07","susan"),(∞,∞))

假设现在还是7月,则所有写操作会被均匀的分布到两个块上。所有用户名小于susan的数据被写入块1中,所有大于susan的数据被写入块2,然后整个生态系统就良性运行了,等到8月,MongoDB又开始创建2012-08的块,分布还是均衡的(这里不是时时均衡,肯定有个抹平的过程),等到9月,7月的数据无人访问就开始退出内存,不再占用资源。

 

--------------------------------------------------------------------------------------------------------------------------------------

当然场景不同,应用就不同,上面也只是基本的东西,具体选择片键还应该根据自己的程序来做,选键的时候多考虑以下问题。

   1,写操作是怎么样的,有多大?

   2,系统没小时会写多少数据,每天呢,高峰期呢

   3,那些字段是随机的,那些是增长的

   4,读操作是怎么样的,用户在访问那些数据

   5,数据索引做了吗?应不应该索引呢?

  6,数据总量有多少

 总的来说,在进行分片前,你需要清楚的了解你的数据。

 

 以上内容参考了“深入学习MongoDB” 一书,如果需了解更多MongoDB优化的知识,这本数绝对值得一读,这本书还列出了50例MongoDB优化,维护等等需要注意的地方

posted on 2012-12-23 22:33  刺猬的温驯  阅读(653)  评论(0编辑  收藏  举报