mongo分片集

分片集的架构说明

名称	解释	作用
Shard	分片集存储实例	用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组个一个replica set承担，防止单机节点故障
config server	分片集配置器	存储了整个ClusterMetadata，其中包括 chunk信息
mongos	分片集路由器	客户端由此接入，且让整个集群看上去像单一数据库，前端应用可以透明使用

为什么要使用分片集？

一般有如下几个原因：

• 数据容量日益增大，副本集维护吃力
• 增加集群的吞吐量
• 单库数据超过10TB
• 地理容灾

使用分片集的优劣势

优势	劣势
1.海量数据存储有方案 2.增加数据库的访问并发和集群的iops 3.跨机房灾备 4.单库数据量有限	1.成本高昂，一个高可用的分片集至少需要3台configServer，2个shardServer，每个shardServer都是为副本集，至少2个mongos组成。 2.分片集本身结构复杂，运维复杂。

1.如何进行分片？

1.1 分片的基本标准

• 1.数据角度:数据量不超过3TB，尽可能保持在2TB一个分片
• 2.索引角度:常用的索引必须能容纳进系统内存之中

1.2 分片的预估标准

A=(所需存储量/单服务可挂载容量)
B=(工作集大小/服务器内存MongoDB可用内存率)
C=(并发量总数/单服务器损耗系数)分片的数量=max(A,B,C)
举个例子：
A=30TB/2TB=15
B=1TB/(64G0.6)=27
C=200000/(80000.7)=36
分片数量=36

1.3 分片的基本概念

名称	解释
分片键 shardkey	文档中的一个字段
文档doc	包含分片键的一行数据
块chunk	包含N个文档
分片shard	包含N个chunk
分片集群Cluster	包含N个分片shard

1.4 选择合适的分片键

基于范围的分片

MongoDB按照片键的值的范围将数据拆分为不同的块(chunk)，每个块包含了一段范围内的数据。

• 优点： mongos可以快速定位请求需要的数据，并将请求转发到相应的Shard节点中。
• 缺点： 可能导致数据在Shard节点上分布不均衡，容易造成读写热点，且不具备写分散性。

适用场景：

• 片键的值不是单调递增或单调递减、片键的值基数大且重复的频率低、需要范围查询等业务场景。

基于hash值的分片

MongoDB计算单个字段的哈希值作为索引值，并以哈希值的范围将数据拆分为不同的块。

• 优点：可以将数据更加均衡地分布在各Shard节点中，具备写分散性。
• 缺点：不适合进行范围查询，进行范围查询时，需要将读请求分发到所有的Shard节点。

适用场景：

• 片键的值存在单调递增或递减、片键的值基数大且重复的频率低、需要写入的数据随机分发、数据读取随机性较大等业务场景。

注意

• 在4.0之前片键一经设置，不可修改，不可删除。在4.2之后可以对分片完的Collection进行修改分片键
• 执行了数据分片操作后，均衡器会对满足条件的数据进行拆分，这将占用实例的资源，请在业务低峰期操作。

1.5 分片操作

1>确认使用的实例为分片集群(执行sh.status())
2>切换数据库(执行 use 数据库名>
3>允许此库进行分片(执行 sh.enableSharding(“数据库名”))
4>创建或使用已有的collection
5>对collection中已创建索引的字段进行分片

1	sh.shardCollection("数据库名.表名",{"_id":1})

6.经过一段时间查看一下数据在每个节点的分布

1	db.stats()