数据库中间件的分片规则如何选择，这篇文章告诉你

前言

在做数据的分库分表时，选择合适分片规则是一件很重要的事情，如果分片规则选择不合理，可能会导致以下两种情况：

因此本文对常用数据分片规则进行优缺点以及适应场景的介绍，希望对读者朋友们有所帮助！

时间范围分片

时间范围分片要求分片键为时间类型字段，可以支持按年、按月、按日、按小时等范围进行数据分片

优点

此分片规则在扩容时只需要添加节点MySQL 选择数据库，指定日期范围，可以避免扩容时的数据迁移

缺点

负载不均衡，容易导致单节点故障，假设：2016.1->2016.6这个时间段（上图DB2节点），公司在做产品推广，那么这个时间段的数据量会比较大，会导致DB2节点负载会比较高，而节点负载又比较低。

适应场景

具有时间属性的数据，适合做范围分片，比如日志数据，前期查询频率比较高，可以按照季度或者月份进行范围分割，后期不需要直接把整个节点迁移走或者进行数据清空，如下图，假如DB1所在数据不需要，直接迁移走即可。

如下图是一个数据扩容示例，假设之前的分片规则规划至2016年底，那么为了支持2017年的数据，只需要增加对应节点、并修改分片规则即可（DB4节点），不需要迁移原有数据

数值范围分片

数值范围分片与时间范围分片类似，唯一不同就是每个分片数据量相对均衡，热点数据存在但是相对较少。

比如时间范围分片2016.1-2016.6为一个分片，在此分片上产生数据是不可控的，假如这个时间段公司不搞促销，那么这个分片数据可能为1w条，如果搞可能为1千万。

但是数值范围分片没有此问题，因为在设置分片时，已规定了每个分片的数据量，所以数据分布比较均衡。

优点

1. 此分片规则在扩容时只需要添加节点，指定数值范围，可以避免扩容时的数据迁移。

2. 数据量可控，可以均衡，也可以不均衡。

缺点

无法解决热点问题，如果某一段数据访问QPS特别高，就会落到单节点上进行操作。

适应场景

业务场景中热点数据比较少的业务都可以使用，比如用户系统，以用户ID进行分片，用户Id采用全局递增模式。

取模分片

取模顾名思义就是对分片键值与对应的节点数进行取余，如下图，假如分片键为6，节点数为3，那么6%3=0，那么此分片键应该保存在DB1节点

取模分片扩展又分为基础分片和hash取模分片，具体如下：

优点

节点负载均衡，假设key是按照全局递增，每次保存数据时与节点数进行取模，保存至对应的节点。

缺点

在扩容时需要全量迁移，因前期是按照规定的节点数取模存储到各个节点的，如果后期新增节点，导致老数据按照新的节点数取模无法匹配到对应的节点，如下图：

因此所有的数据需要全部迁移重新分片，如下图：

适应场景

适用于需要将数据均匀分布的场景，例如：银行类客户业务应用，业务逻辑主体是客户，可使用客户对应的表字段（例如客户号）作为拆分键

一致性hash分片

之前文章介绍过一致性hash分片各种特性，具体可查看，这里只做简单介绍

一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，增加或者移除一个节点，只影响该节点在哈希环上顺时针相邻的后继节点，其它数据不会受到影响

但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应，如下图

优点

通过增加虚拟节点后数据分布相对均衡，节点不存在热点问题

缺点

数据扩容相对复杂，理论上一致性Hash在扩容时只需要迁移相邻节点部分数据即可，但是为了保证节点的数据均衡，增加了虚拟节点，导致相邻过多，那么数据扩容变得就没那么简单，假设增加DB4节点的虚拟节点（红色标识），那么相邻的DB1和DB3数据都需要迁移

适应场景

适用于需要将数据均匀分布并且在扩容时不需要大量迁移数据的场景

------我创建了一个高质量的技术交流群，与优秀的人在一起，自己也会优秀起来，赶紧，享受一起成长的快乐！推荐阅读

如果本文对你有帮助的话，欢迎点赞&在看&分享，这对我继续分享&创作优质文章非常重要。非常感谢！

（编辑：财气旺网 - 财气网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!