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中国
相关推荐
-
Notre Dame对云端SQL Server性能基准的探索实践
确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。
-
DBA必须掌握的数据库恢复管理技术
如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。
-
2017年1月数据库流行度排行榜 新年新气象
新年新气象,数据库知识网站DB-engines最近更新了2017年1月份数据库流行度榜单。TechTarget数据库网站将与您分享1月份的榜单排名情况,让我们拭目以待。
-
创建NoSQL数据建模符号 企业架构师亲自上阵
新兴的NoSQL数据风格促使创新的应用程序快速发展,但NoSQL同时也带来了挑战。NoSQL系统能够快速投入生产,有时甚至根本不用创建任何的前期模式。