分片集群-Sharded Cluster

分片概念

分片（sharding）是一种跨多台机器分布数据的方法， MongoDB使用分片来支持具有非常大的数据集
和高吞吐量操作的部署。
换句话说：分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区
(partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存
更多的数据，处理更多的负载。
具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如，高查询率会耗
尽服务器的CPU容量。工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。
有两种解决系统增长的方法：垂直扩展和水平扩展。
垂直扩展意味着增加单个服务器的容量，例如使用更强大的CPU，添加更多RAM或增加存储空间量。可
用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。此外，基于云的提供商基于可用
的硬件配置具有硬性上限。结果，垂直缩放有实际的最大值。
水平扩展意味着划分系统数据集并加载多个服务器，添加其他服务器以根据需要增加容量。虽然单个机
器的总体速度或容量可能不高，但每台机器处理整个工作负载的子集，可能提供比单个高速大容量服务
器更高的效率。扩展部署容量只需要根据需要添加额外的服务器，这可能比单个机器的高端硬件的总体
成本更低。权衡是基础架构和部署维护的复杂性增加。
MongoDB支持通过分片进行水平扩展。

分片集群包含的组件

MongoDB分片群集包含以下组件：
分片（存储）：每个分片包含分片数据的子集。 每个分片都可以部署为副本集。
mongos（路由）：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
config servers（“调度”的配置）：配置服务器存储群集的元数据和配置设置。 从MongoDB 3.4开
始，必须将配置服务器部署为副本集（CSRS）。
下图描述了分片集群中组件的交互：

分片集群架构目标
两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共11个服务节点。

在路由节点上进行分片配置操作

使用命令添加分片：
（1）添加分片：
语法：sh.addShard(“IP:Port”)
将第一套分片副本集添加进来：
sh.addShard(“myshardrs01/192.168.0.2:27018,180.76.159.126:27118,180.76.159.126:2 7218”)
查看分片状态情况：sh.status()
（2）开启分片功能：sh.enableSharding(“库名”)、sh.shardCollection(“库名.集合名”,{“key”:1})
在mongos上的articledb数据库配置sharding:
sh.enableSharding(“articledb”)
（3）集合分片
对集合分片，你必须使用 sh.shardCollection() 方法指定集合和分片键。
语法：sh.shardCollection(namespace, key, unique)

对集合进行分片时,你需要选择一个 片键（Shard Key） , shard key 是每条记录都必须包含的,且建立了
索引的单个字段或复合字段,MongoDB按照片键将数据划分到不同的 数据块 中,并将 数据块 均衡地分布
到所有分片中.为了按照片键划分数据块,MongoDB使用 基于哈希的分片方式（随机平均分配）或者基
于范围的分片方式（数值大小分配） 。
用什么字段当片键都可以，如：nickname作为片键，但一定是必填字段。
分片规则一：哈希策略
对于 基于哈希的分片 ,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块.
在使用基于哈希分片的系统中,拥有”相近”片键的文档 很可能不会 存储在同一个数据块中,因此数据的分
离性更好一些.
使用nickname作为片键，根据其值的哈希值进行数据分片
sh.shardCollection(“articledb.comment”,{“nickname”:“hashed”})
查看分片状态：sh.status()
分片规则二：范围策略
对于 基于范围的分片 ,MongoDB按照片键的范围把数据分成不同部分.假设有一个数字的片键:想象一个
从负无穷到正无穷的直线,每一个片键的值都在直线上画了一个点.MongoDB把这条直线划分为更短的不
重叠的片段,并称之为 数据块 ,每个数据块包含了片键在一定范围内的数据.
在使用片键做范围划分的系统中,拥有”相近”片键的文档很可能存储在同一个数据块中,因此也会存储在同
一个分片中.
如使用作者年龄字段作为片键，按照点赞数的值进行分片：
sh.shardCollection(“articledb.author”,{“age”:1})
注意的是：
1）一个集合只能指定一个片键，否则报错。
2）一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新
分片键的值。
3）根据age索引进行分配数据。

基于范围的分片方式与基于哈希的分片方式性能对比：
基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数
据块存储了请求需要的数据,并将请求转发到相应的分片中.
不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极
作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终
导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行
扩展.
与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性
使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难
确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.
如无特殊情况，一般推荐使用 Hash Sharding。
而使用 _id 作为片键是一个不错的选择，因为它是必有的，你可以使用数据文档 _id 的哈希作为片键。
这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很
精细。
似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较
好的方案了。
理想化的 shard key 可以让 documents 均匀地在集群中分布：

显示集群的详细信息：
mongos> db.printShardingStatus()
查看均衡器是否工作（需要重新均衡时系统才会自动启动，不用管它）：
mongos> sh.isBalancerRunning() false
查看当前Balancer状态：
mongos> sh.getBalancerState() true

再增加一个路由节点：
使用mongo客户端登录27117，发现，第二个路由无需配置，因为分片配置都保存到了配置服务器中
了。