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存储。好像也没什么吸引力。