上期说了说搭建MongoDB Sharding 的问题，分片好搭建，其实大部分失败的MongoDB 分片的问题在于分片键选错了。
主要产生这样的事情有两个方面
1 开发人员对MONGODB 分片的逻辑不清晰，仅仅考虑方便查询，选择的分片键更偏向于通过 1个 分片 或更少的分片来查询数据，最终导致的结果就是，分片中，只有少数分片上有数据，而大多数分片上数据量较少，甚至没有数据。
2 DBA 或运维人员，他们更倾向于将数据打散,让数据更有效的分散到不同的分片中。但导致的问题是查询时，由于分片键不是查询中经常使用的而造成查询会遍历所有的分片，导致查询性能的问题。
所以我们有必要来看看分片的问题，以及一些概念
What's the chunk ?
Chunk 是分片中必须要懂的一个东西，chunk 本身不是一个快，而指的是一个范围以及我们怎么来划分这个数据。
这个信息是保存在config server中的，算是metadata信息，其中的信息可以描述为
chunk_id : Minimum value : Maximum value : shard
这标识出这个chunk 的块的名字，以及他存储的最小值和最大值， 及他们存储的位置 shard， 有了chunk下面就会提到balance，平衡，为什么要平衡，不是我选择分片键后，根据不同的值，去不同的sharding 了，怎么还平衡，这里我们选择分片键的时候，很可能使用的是hash ，即使不是HASH分片也会存在不均衡的可能性，而这样的分片，是根据hash值来进行数据的划分的，所以如果我们有两个分片，那每个分片获得的数据chunk 会进行比较，如果某一个chunk 的数据量比另一个chunk的差异较大，则MONGO 会进行一个自动化的balance 保证chunk 的均衡。
举例：我们建立一个hash 的分片键，下图我们建立一个info 数据库，并确认此数据库进行确认分片，并用code 的字段建立hash 索引，然后我们插入一些数据
我们再次确认info 是否是 shard
同时我们可以查看当前的collection的分片情况
大家可以看到，图中的分片将这些数据也是分布的比较均匀。（这和你的HASH 键的选择是有关的）
我们可以去相关的每个分片中看看到底数据存储了什么
分片1
分片2
分片 3
这里又产生另一个话题就是hash 分片这么好，是不是我们全部的分片都使用hash 分片就OK 了，不在需要range 分片了。其实不然，通过hash 分片也是有弊病的，就是你选择的片键如果值比较单一，不多元化，那结果很可能就是，几个片键，有的存有大量的数据，有的很少。所以一般建立hash 片键的时候，可以符合片键来达到数据分布的多态和平均性。
如果是使用range 的方式来建立分片键，有什么好处，或者为什么要有range 的方式。
range 的方式你可以理解为你使用DBLE 来进行MYSQL 的分库，通过中间件来让你的每个MYSQL 表的数据大致数量相当的，通过已知的逻辑和人为的手段让你的分片数据，均衡，并更容易进行查找。
例如我们对一个range collection 进行 range分区
我们先建立一个分区键code 索引
db.range.createIndex(code:1})
然后我们根据rang的 code 来进行分片的设置
sh.shardCollection("test.range",{code:1})
我们将我们的范围与物理的片键进行绑定，当然这之前你的进行物理的片键和你的简写字母的绑定
sh.addTagRange("test.range",{code:1},{code:3},"A")
sh.addTagRange("test.range",{code:4},{code:6},"B")
sh.addTagRange("test.range",{code:7},{code:9},"C")
（生产上这样的做法应该是不大常见的）
然后我们查看我们的设置是否生效，从下图我们可以清晰的看到我们的设置是OK 的，没有问题。
我们插入数据，根据我们之前的分片来进行
最后我们查看一下当下的range 的分片，
数据的分布是平均的，当然这和你输入的数据有关。
MONGODB 的分片在设计之初就是为了大型数据的输入和查询准备的，并且现在又有完备的大数据方案做依靠，MONGODB 的数据库存在不仅仅是NOSQL 场景，大数据分析的场景也是可以进行使用和利用的。