1,什么时候需要分片？
MongoDB的分片很是火热，但是问题是，我们什么时候才真的需要使用分片呢？当你需要使用到如下的几个标志性的事件时，就意味着该考虑使用分片了！
1、你用光了当前机器的磁盘空间
2、单个的Mongod已经无法提供你要的写入性能了
3、你想把大部分数据驻留在内存中籍此来提供更好的性能
一般意义而言，我们应该从非分片安装开始，只是到了非需要不可的时候才将Mongod转变为分片集群。
2,
Mongodb中一个被分片的Collection的所有数据都存放在众多的Chunk中。一个Chunk存放分片字段的一个区间范围的数据。选择一个好的分片字段非常重要，否则就会遭遇到不能被拆分的大Chunk。
用上述的日志为例，如果选择{server:1}来作为一个分片Key的话，一个server上的所有数据都是在同一个Chunk中，很容易想到一个Server上的日志数据会超过200MB（默认Chunk大小）。如果分片Key是{server:1,time:1}，那么能够将一个Server上的日志信息进行分片，直至毫秒级别，绝对不会存在不可被拆分的Chunk。
将Chunk的规模维持在一个合理的大小是非常重要的，只有这样数据才能均匀分布，并且移动Chunk的代价也不会过大。
3,
使用分片的一个主要原因之一是分散写操作。为了实现这个目标，尽可能的将写操作分散到多个Chunk就尤为重要了。
用上述的日志实例，选择{time：1}来作为分片key将导致所有的写操作都会落在最新的一个Chunk上去，这样就形成了一个热点区域。如果选择{server:1,application:1,time:1}来作为分片Key的话，那么每一个Server上的应用的日志信息将会写在不同的地方，如果有100个Server和应用对，有10台Server，那么每一台Server将会分担1/10的写操作。
4,
另外一个需要考虑的是任何一个查询操作将会由多少个分片来来提供服务。最理想的情况是，一个查询操作直接从Mongos进程路由到一个Mongodb上去，并且这个Mongodb拥有该次查询的全部数据。因此，如果你知道最为通用的查询操作的都以server作为一个查询条件的话，以Server作为一个起始的分片Key会使整个集群更加高效。
任何一个查询都能执行，不管使用什么来作为分片Key，但是，如果Mongos进程不知道是哪一个Mongodb的分片拥有要查询的数据的话，Mongos将会让所有的Mongod分片去执行查询操作，再将结果信息汇总起来返回。显而易见，这回增加服务器的响应时间，会增加网络成本，也会无谓的增加了Load。
5,
正如在别的章节中提到索引的一样，如果只有一部分的索引被读或者更新的话，通常会有更好的性能，因为“活跃”的部分在大多数时间内能驻留在内存中。本文上述的所描述的选择分片Key的方法都是为了最终数据能够均匀的分布，与此同时，每一个Mongod的索引信息也被均匀分布了。相反，使用时间戳作为分片key的起始字段会有利于将常用索引限定在较小的一部分。
6,
（1）Mongodb的不足之处
1、在集群分片中的数据分布不均匀
2、单机可靠性比较差
3、大数据量持续插入，写入性能有较大波动
4、磁盘空间占用比较大
（2）Mongodb的过人之处
1、无模式
2、查询与索引方式灵活，是最像SQL的Nosql
2、支持复制集、主备、互为主备、自动分片等特性
7,