Mycat范围求模分片

讲解Myat范围求模分片规则之前，让我们先看如下这样的一个系统的特征：

比如一个系统，具备如下特点：

• 门店数量增长快，各集团内门店数量分布不均匀。
• 业务为统计类业务，都是基于某一段时间内，然后对某一集团内的门店进行数据统计。
• 数据规模较大，以一个集团，500个门店，主表，每天1000条数据计算的话，一天是50万条，一个月就是150万条数据。半年单表数据量为900万条。由于分为淡  旺季，故连续半年的数据量，不会超过1000万条数据。

结合系统的特点，提出如下两个重要观点。

1. 该系统的组织结构涉及集团与门店两个层级，当然不排除集团下面还有集团，在我认为，集团下面的集团，与门店概念一致，总的说来，就是顶层集团---》门店概念。个 人认为，集团与集团的数据最好应该做到逻辑、物理的隔离性。
2. 数据库分片的目的，就是要将数据较为均匀的分配到不同的节点，将查询请求分散到多个节点执行，然后汇聚，充分利用多台Mysql服务器（CPU）的运算能力提高查询的 效率；同时既然需要分片，说明单库的数据量肯定不少，未来的扩容必不可少。

根据上文提到的两个重要观点，现提出如下解决方案：

• 尽量做到逻辑，物理的相对隔离。我建议按照集团来组织数据，可以为每个集团，单独创建一个数据库用户，然后再在该用户下创建数据库(也就是scheme)，这里的 schema也就是后面Mycat分片中的DataNode。这样存储主要基于如下几点考虑：
  • 管理方便，如果是一个用户的话，会看到很多的逻辑schema。
  • 每个门店的规模、特点相差太多，统一管理需要考虑太多的要素，不如分而治之，根据不同的集团，制定不同的分库，存储规则，灵活性较大，适应变化的需求的能力较强。
• 根据这个系统的特点，每个集团下的数据分片，考虑的应该就是数据分布均匀，增加分片后，数据迁移是考虑的重点，并且该系统的数据具有时效性，系统关心的数据基本上以1年为周期，1年前的数据可以当成是历史数据，不占用该系统的数据库资源。所以，我推荐数据库分片采用【范围求模分片】。

接下来阐述一下范围求模分片：

分片字段，表的主键如果是是Long类型的话，可以直接用主键ID,如不是Long类型的话，可以增加一个字段，名字为 dcol,取创建时间的Long值。下面我重点阐述一下范围求模分片的思想。

• 分片分组思想
• 范围分片，兼顾了范围查询。

该分片方法，有个非常大的优势，就是对扩容，原数据无需迁移，具体分片方法如下：

首先先贴上Mycat官方给出的配置信息：

<tableRule name="auto-sharding-rang-mod">

        <rule>

            <columns>dcol</columns>

            <algorithm>rang-mod</algorithm>

        </rule>

    </tableRule>

<function name="rang-mod"class="io.mycat.route.function.PartitionByRangeMod">

        <propertyname="mapFile">partition-range-mod.txt</property>

        <propertyname="defaultNode">0</property>

    </function>

partition-range-mod.txt 文件中的内容：

#  1451577600000 是 2016-01-01 00:00:00 的long值

#  1467302399000 是 2016-06-30 23:59:59 的long值

#  1483199999000 是 2016-12-31 26:59:59 的long值

    1451577600000-1467302399000=2

1467302399001-1483199999000=2

上面的一个条目[1451577600000-1467302399000=2]代表一个分片组，开始范围--结束范围=该分片组有多少个分片(DataNode)。也就是我给出的方案是，2016上半年的数据存入分片组1，分片组1包含（dn1,dn2）两个节点，2016年下半年的数据，存入分片组2,（dn3,dn4），那2017年的数据怎么办呢，我们可以增加分片组来实现，也可修改配置文件，使用原来的1,2,3,4这样来配置，实现扩容时，不需要对原数据进行迁移。

范围求模分片，主要是要根据数据量，规划一下单个分片组的分片数量；采用Mysql数据库，主表的数据单个分片数据保持在500万--1000万条数据，关联表（1对多）字表数据尽量保证在（1000万）的规模，在这样的数据集下，结合Mysql索引是可以达到性能上的要求。

欢迎加笔者微信号(dingwpmz)，加群探讨，笔者优质专栏目录：

1、源码分析RocketMQ专栏(40篇+)
2、源码分析Sentinel专栏(12篇+)
3、源码分析Dubbo专栏(28篇+)
4、源码分析Mybatis专栏
5、源码分析Netty专栏(18篇+)
6、源码分析JUC专栏
7、源码分析Elasticjob专栏
8、Elasticsearch专栏
9、源码分析Mycat专栏