用Pre-Splitting提升MongoDB Auto-Sharding效率

日期: 2011-03-09 作者:Jeremy Zawodny 来源:TechTarget中国 英文

  MongoDB 的 Auto-Sharding 一直是一个颇受争议的特性。其理论描述非常完美,但是实际应用上却出了很多问题,本文深入分析了Auto-Sharding的数据迁移过程,找出了影响性能的原因,并提出了作者自己的解决方案。

  Auto-Sharding的内部机制

  MongoDB 的 Sharding在存储数据时将数据进行了分块存储(Chunk),每一块的大小默认为200M。而Sharding 中每一次数据迁移的最小单元就是数据块。

  MongoDB 后台有一个叫做Balancer的后台程序,会检查各个Sharding结点的分布情况,当发现不同结点间Chunk数相差达到一定大小时,就开始时行数据迁移,以平衡数据在各个Sharding结点的分布。

  Balancer 迁移数据的过程是,先把要迁移的数据从磁盘读到内存,再进行迁移。

  但是当数据量比较大时,通常你需要迁移的数据可能并没有被加载到内存里,这时候问题就出现了,你会先把内存中的热数据踢除,以加载从磁盘读取的需要迁移的数据,然后在迁移完数据后再删除掉原来结点上的数据。在这过程中,由于热数据被踢回磁盘中,可能会严重影响性能。

  解决方案-预先划分数据区间

  最后的解决方案其实相当于放弃了Auto-Sharding,而是通过MongoDB提供的 Pre-splitting 功能对数据进行预先的划分,这需要你对自己的数据分布有一个充分的了解(我相信对数据量做一个半年到一年左右的预估来做规划还是比较靠谱的做法),在这个基础上为每台机器划分出其合适大小的sharding-key范围,这样就能有效的避免过多的数据迁移工作。其实这已经相当于放弃了Auto-Sharding转而使用Manual-Sharding。

  Hash Sharding

  另外根据作者透露,10gen 的CTO Eliot 还表示他们正在开发一种基于Hash的Sharding策略(当前的策略基于范围值,可以理解为btree方式),这样可以使数据更均匀的分布,但是因为利用了Hash算法,当然也就不能提供范围查询这样的功能了。想像一下相当于一个分布式的key-value存储。好像也没什么吸引力。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐