MongoDB分片原理篇

素颜马尾好姑娘i 2022-03-17 09:58 171阅读 0赞

## MongoDB分片 ##

### 为什么需要Sharded cluster？ ###

MongoDB目前3大核心优势：『灵活模式』+ 『高可用性』 + 『可扩展性』，通过json文档来实现灵活模式，通过复制集来保证高可用，通过Sharded cluster来保证可扩展性。

**何时使用分片技术**

> 存储容量需求超出单机磁盘容量  
> 活跃的数据集超出单机内存容量，导致很多请求都要从磁盘读取数据，影响性能  
> 写IOPS超出单个MongoDB节点的写服务能力  
> ![758999-20170530143430508-594951232.png][]

分片技术，使得集合中的数据分散到多个分片集中。使得MongoDB具备横向的发展。

### Sharded cluster 分片架构 ###

**Sharded cluster**由**Shard**、**Mongos**和**Config server** 3个组件构成。  
![758999-20170530143454852-456379210.png][]

**Mongos**是**Sharded cluster**的访问入口，  
**Mongos**本身并不持久化数据，**Sharded cluster**所有的元数据都会存储到**Config Server**  
而用户的数据则会分散存储到各个**shard**。**Mongos**启动后，会从**config server**加载元数据，开始提供服务，将用户的请求正确路由到对应的**Shard**。

### 数据分布策略 ###

分片支持单个集合的数据分散在多个分片上。目前主要有两种数据分片的策略。

*  范围分片（Range based sharding）
 *  hash分片（Hash based sharding）

范围分片

![758999-20170530143518430-1430214923.png][]

如图，集合是根据字段来进行分片。根据字段的范围不同将一个集合的数据存储在不同的分片中。  
在同一个**Shard**上，每个**Shard**可以存储很多个**chunk**，**chunk**存储在哪个shard的信息会存储在**Config server**种，**mongos**也会根据各个shard上的chunk的数量来自动做**负载均衡**。  
**范围分片**适合满足在一定范围内的查找，例如查找X的值在【100-200】之间的数据，mongo 路由根据**Config server**中存储的元数据，可以直接定位到**指定的shard的Chunk中**  
**缺点** 如果shardkey有明显递增（或者递减）趋势，则新插入的文档多会分布到同一个chunk，无法扩展写的能力

Hash分片

**Hash分片是根据用户的shard key计算hash值（64bit整型），根据hash值按照『范围分片』的策略将文档分布到不同的chunk**

![758999-20170530143529836-1433560500.png][]

**优点**Hash分片与范围分片互补，能将文档随机的分散到各个chunk，充分的扩展写能力，弥补了范围分片的不足，  
**缺点**但不能高效的服务范围查询，所有的范围查询要分发到后端所有的Shard才能找出满足条件的文档。

合理的选择shard key

选择shard key时，要根据业务的需求及『范围分片』和『Hash分片』2种方式的优缺点合理选择，要根据字段的实际原因对数据进行分片，否则会产生过大的Chunk

Mongos

Mongos作为Sharded cluster的访问入口，所有的请求都由mongos来路由、分发、合并，这些动作对客户端driver透明，用户连接mongos就像连接mongod一样使用。

查询请求

*  查询请求不包含shard key，则必须将查询分发到所有的shard，然后合并查询结果返回给客户端
 *  查询请求包含shard key，则直接根据shard key计算出需要查询的chunk，向对应的shard发送查询请求
    
    写请求
    
    写操作必须包含shard key，mongos根据shard key算出文档应该存储到哪个chunk，然后将写请求发送到chunk所在的shard。
    
    更新/删除请求
    
    更新、删除请求的查询条件必须包含shard key或者\_id，如果是包含shard key，则直接路由到指定的chunk，如果只包含\_id，则需将请求发送至所有的shard。
    
    其他命令请求
    
     
    
    ### Config Server ###
    
    config database
    
    Config server存储Sharded cluster的所有元数据，所有的元数据都存储在config数据库  
    Config Server可部署为一个独立的复制集，极大的方便了Sharded cluster的运维管理。
    
    config.shards
    
    config.shards集合存储各个Shard的信息，可通过addShard、removeShard命令来动态的从Sharded cluster里增加或移除shard
    
    config.databases
    
    config.databases集合存储所有数据库的信息，包括DB是否开启分片，primary shard信息，对于数据库内没有开启分片的集合，所有的数据都会存储在数据库的primary shard上。
    
    config.colletions
    
    数据分片是针对集合维度的，某个数据库开启分片功能后，如果需要让其中的集合分片存储，则需调用shardCollection命令来针对集合开启分片。
    
    config.chunks
    
    集合分片开启后，默认会创建一个新的chunk，shard key取值\[minKey, maxKey\]内的文档（即所有的文档）都会存储到这个chunk。当使用Hash分片策略时，也可以预先创建多个chunk，以减少chunk的迁移。
    
    config.settings
    
    config.settings集合里主要存储sharded cluster的配置信息，比如chunk size，是否开启balancer等
    
    其他集合
 *  config.tags主要存储sharding cluster标签（tag）相关的你洗
 *  config.changelog主要存储sharding cluster里的所有变更操作，比如balancer迁移chunk的动作就会记录到changelog里
 *  config.mongos存储当前集群所有mongos的信息
 *  config.locks存储锁相关的信息，对某个集合进行操作时，比如moveChunk，需要先获取锁，避免多个mongos同时迁移同一个集合的chunk。
 *  **要更多干货、技术猛料的孩子，快点拿起手机扫码关注我，我在这里等你哦~**
 *                                                         ![70][]

[758999-20170530143430508-594951232.png]: /images/20220317/fe00a859a7c44e8193ef296ef7973823.png
[758999-20170530143454852-456379210.png]: /images/20220317/0538776d3e1944a2bdf7d6ee19f5d15a.png
[758999-20170530143518430-1430214923.png]: /images/20220317/aac56c41b08945079625b59c47a65e4a.png
[758999-20170530143529836-1433560500.png]: /images/20220317/f1a390e810d9492db996110cd6a9d638.png
[70]: /images/20220317/dc97a466c64542a3befe4aa24e5ad31d.png