sharding设计须考虑的几个因素
Sharding Key的选择
在片键的选择上，最好是能够在字段中选择混合型的片键，大范围的递增健、和随机分布的健组合，如按月份递增、按用户名随机。
递增的sharding key
优点：数据文件移动相对较少；
缺点：对于不断写入的业务，会造成最后一个分片变成写热点，导致最后的一块分片chunk数量比其他的多，最终chunk不断移动；
随机的sharding key
优点：数据分布相对均匀、写入的数据基本上能够分布在多个分片上；
缺点：随机的片键本身就会给磁盘带来巨大的IO读写；
ChunkSize的大小问题
ChunkSize的默认大小为64M，但是需要根据业务情况、不同硬盘型号、不同文件系统指定合适的chunksize，单个chunkSize一般为100M-200M之间，ChunkSize的大小应该在设计阶段、业务上线之前就要确定。
较大的ChunkSize
优点：chunk分裂少；
缺点：存在数据分布不太均衡；以及chunk移动时，会消耗大量的IO写资源；
较小的ChunkSize
优点：迁移速度快、数据分布更均衡；
缺点：chunk分裂更频繁，同样也会消耗大量的IO写资源；
Balancer的时间选择
需要在业务当天的低谷时段进行数据的自动均衡，如在业务高峰时段设置数据均衡，业务和均衡都在抢占磁盘IO，系统的吞吐量会一下子下降，一般的业务凌晨的业务量会稍微小一些。
count值不准确
由于sharding环境下，写入时，chunk都在不断迁移，所以查询出来的数量往往会大于实际写入的数量，用db.collection.aggregate([{$group: {_id: null,count: {$sum: 1}}}])，可以看到实际的写入值。
库设计
1. 生产环境中，库尽量不要开启auto-sharding功能；
2. 在业务量不是很大的情况下，可以将库手动指定在某个分片上；
3. 集群内存的大小总和应该要大于索引+oplog+数据热点；
4. 将更新频繁的collection放在同一个库中，将更新不是很平凡的表也归类到一个库中；
collection设计
1. 虽然MongoDB为文档型数据库，无须制定schema，但是也意味着每个文档都有重复的字段，会带来空间的浪费，可以通过以下两种办法解决：
1.1 减小字段名，如将address用a来替代，可读性问题在应用层用字段名映射进行解决；
1.2 利用现有wiredtiger引擎中的zlib压缩，可以减小存储空间，也可以减小IO压力；
2. MongoDB自带的_id值默认就是12个字节，可以考虑用其他主键替代，如用户的UID等，可以减小MongoDB的计算压力和存储空间；
3. 对于大表必须要考虑分配的，可以根据主键进行分类，按每个分片的子表不要超过1000条记录计算。