紧急出个差，但是又不能不继续写，少写点，先把Shard key和Hash的一些小概念继续写一写。

Shard Keys

mongoDB的Sharding最重要的就是Shard Key。用Shard Key进行分片，并且按照指定的Chunk的大小进行Chunk的分割和移动(后面细说)。Shard Key的一些特点：

Shard Key不可以是multikey index

何为mutikey index？途中的addr[]这个数组就是所谓的mutikey index。Shard key可以是复数个字段，但是不可以是一个数组形的multikey类型的index。

Hash Shard Key

任何带有hash字样的东东就为一个目的：平均打散，高度聚合。

通过hash算法进行散装分配，通过key再迅速找回value。

对于写的横向扩展

Shard key有两个比较重要的指标，一个是分布的基数要广，即每一个collection中都要有；另外一个是要保持“单调性”，比如timestamp，比如mongoDB自己的ObjectId等等。假设我们使用的是一个timestamp来作为Shard Key，可能保证了单调性和基数广，但是这种连续存储的Shard Key很有可能使得所有的数据都是连续存储在同一个Chunk，也就是同一个Shard中，我们可能会有10个Shard节点，但是结果就是可着第一个节点一直在存储，而其余的节点都在休息。

所以，Shard Key还应该有一定的随机性，也就是说在写操作的时候应该能够发挥所有的Shard一起动作，进行类似LB一样的负载。

关于Shard中的查询

对于查询来讲，mongos是提供interface供application进行调用的。程序进行调用后，mongo会在config Server中查找相应的metadata来定位Shard，然后进行查找的工作。所以我们的Shard Key会直接影响到查询的效果和速度。

关于Shard中的独立查找

一般来讲，最快的查询操作是让mongos查找一个Shard。如果一个查询中没有包含Shard Key，那么mongos就会遍历所有的Shards。和我们普通的RDB中没有索引的全表扫描一个效果。而且因为Shard有很多，所以这个查询类似于一个分散操作后再次进行聚合操作的过程，非常费时间。而如果你的Shard Key在检索条件中有体现，那么即便是需要分散查找几个Shard，因为mongos有直接性，会知道到哪里去找，效果也会好得多。所以为collection选定一个Shard key的话，首先要确定查找的时候会经常用到哪些项目，找到这些操作中最有效的依赖关系，比如一个项目可能不是那种很好识别不是可以单独利用充分简单能把数据pick up出来的，那么是否可以增加另一个项目组合起来来扩大可选性，扩大其作为“key”的纯度等等。

关于排序

Shards中的排序其实是有一个merge后的sort的过程。其实很好想，各个Shards返回结果后，merge到一起再进行一个sort。

不可分的Chunk

后面还会细说，有些Chunk可能出现不可进行分解的情况，这很大程度上是是由于Shard key的选定的粒度不好所造成的。

明天要坐高铁。(-?-;) 。。。 后面继续写继续写。

ps，今天给mongo的jira又提Bug了。。

之前傻了吧唧的搞错了一个命令给人家提了人家还挺客气回复说是我搞错了，但是今天看文档看到一个文档的简单miss，哈哈，这次我不会错了。

つづく???