之前学分布式数据库的时候了解过mongodb，用了下它的分片，当时没有记录下来，现在想想很亏。。。现在再来复习下吧。
mongodb分片组件架构如图所示 config Server(配置服务器)：存储了集群的元信息，元信息主要存储了数据块对分片的一个映射，通过元信息来决定查询访问那些分片 router(路由服务器)：每个路由都是 mongos的一个实例 ,应用将请求发送给路由服务器，然后路由服务器将读写请求分发到分片中.应用并不直接访问分片。 shard(分片)：分片是存储了一个集合部分数据的MongoDB实例,每个分片是单独的 mongod 或者是 replica set .在生产环境中,所有的分片都应该是复制集。 replica set（复制集）：分片的一个复制，为分片提供了冗余和高可靠性，当某个配置服务器或者分片损坏时，复制集可以取而代之。
片键决定了集合中的文档在分片中的一个分布情况。mongodb中规定片键字段必须被索引,且在集合中的每条记录都不能为空,可以是单个字段或复合字段，片键在写入后不能被改变。 mongodb提供了两种分片方式来对片键进行划分，一种是Hashed Sharding（基于hash的分片），另一种是Ranged Sharding（基于范围的分片） Hashed Sharding：通过计算片键的hash值作为分片键来决定数据划分到某个分片中。其中的hash值计算过程有mongodb自己完成，不需要应用参与，如下图所示 Ranged Sharding：通过对片键的范围进行划分，对每个分段设置一个对应的分片，如下图所示，对片键从minKey到maxKey划分为4段，其中(minkey, -75)对应于分片1，（-75， 25）对应于分片2，依次类推，如果来了片键20，则将其划分至分片1中： 基于hash分片和基于范围分片的一个比较： 基于范围的分片方式提供了更高效的范围查询。因为数据是片键是按序划分的，给定一个片键的范围,分发路由可以很简单地确定哪个数据块存储了请求需要的数据,并将请求转发到相应的分片中. 不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极作用.比如,如果片键所在的字段大部分都集中于某个较小区间中,最终导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行扩展. 与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有的分片。 参考mongodb中文社区：http://docs.mongoing.com/manual-zh/core/sharded-cluster-components.html
