Mycat常用规则术语

全局表

如果你的业务中有些数据类似于数据字典,比如配置文件的配置,常用业务的配置或数据量不是很大,很少变动的表,这些表往往不是特别大,而且大部分的业务场景都会用到,那么这种表适合于MyCat全局表,无须对数据进行切分。只要在所有的分片上保存一份数据即可,MyCat在Join操作中,业务表与全局表进行Join聚合会优先选择相同分片内的全局表join,避免跨库Join,在进行数据插入操作时,mycat 将把数据分发到全局表对应的 所有分片执行,在进行数据读取时候将会随机获取一个节点读取数据。

type=”gloab”

<table name=”t_area” primaryKey=”id” type=”gloab” dataNode=”dn1,dn2”/>

ER分片表

有一类业务,例如订单(order)跟订单明细(order_detail),明细表会依赖于订单,也就是说会存在表的主从关系,这类似业务的切分可以抽象出合适的切分规则,比如根据用户ID切分,其它相关的表都依赖于用户ID,再或者根据订单ID切分,总之部分业务总会可以抽象出父子关系的表。这类表适用于ER分片表,子表的记录与所有关联的父表记录存放在同一个数据分片上,避免数据Join跨库操作。 以order与order_detail例子为例,schema.xml中定义如下的分片配置,order,order_detail根据order_id进行数据切分,保证相同order_id的数据分到同一分片上,在进行数据插入操作时,MyCat会获取order所在的分片,然后将order_detail也插入到order所在的分片。

而如果我们不设置这个,在执行关联join的查询的时候会发生跨片操作,解决办法是使用全局类型,但是因为随着修改变更增加,这种方式其实不适合,我们如果增加沉余数据,而有浪费,所以这个时候ER分片就显得重要了,他就是把相关表分散在一个分片中。

<table name=”order” dataNode=”dn$1-32” rule=”mod-long”>
    <childTable name="order_detail" primaryKey="id" joinKey=”order_id” parentKey=”order_id”/>
</table>

备注:这样不需要在定义子表的table了!

多对多关联(Mycat弱项)

有一类业务场景是”主表A + 关系表 + 主表B”,举例来说就是商户会员 + 订单 + 商户,对应这类业务,如果切分: 从会员的角度,如果需要查询会员购买的订单,那按照会员进行切分即可,但是如果查询商户当天售出的订单,那又需要按照商户做切分,可以是如果按照会员又要按照商户切分,几乎是无法实现,这类业务如何选择切分规则非常难。目前还暂时无法很好支持这种模式下的3个表之间的关联。目前总的原则是需要从业务角度来看,关系表更偏向哪个表,即”A的关系”还是”B的关系”,来决定关系表跟从那个方向来存储。

备注:这种问题使用视图可以暂时解决!

主键分片vs非主键分片

当你没有任何字段可以作为分片字段的时候,主键分片就是唯一选择,其优点是按照主键的查询最快,当采用自动增长的序号作为主键时,还能比较均匀的将数据分片在不同的节点上。 若有某个合适的业务字段比较适合作为分片字段,则建议采用此业务字段分片,选择分片字段的条件如下: 1、 尽可能的比较均匀分布数据到各个节点上。 2、 该业务字段是最频繁的或者最重要的查询条件。 常见的除了主键之外的其他可能分片字段有”订单创建时间”、”店铺类别”或”所在省”等。当你找到某个合适的业务字段作为分片字段以后,不必纠结于”牺牲了按主键查询记录的性能”,因为在这种情况下,Mycat提供了”主键到分片”的内存缓存机制,热点数据按照主键查询,丝毫不损失性能。

<table name=”t_user” primaryKey=”user_id” dataNode=”dn$1-32” rule=”mod-long”>
    <childTable name= "t_user_detail" primaryKey=”id” joinKey=”user_id” parentKey=”user_id”/>
</table>

对于非主键分片的table,填写属性primaryKey,此时MyCat会将你根据主键查询的SQL语句的第一次执行结果进行分析,确定该Table的某个主键在什么分片上,并进行主键到分片ID的缓存。第二次或后续查询mycat会优先从缓存中查询是否有idnode即主键到分片的映射,如果有直接查询,通过此种方法提高了非主键分片的查询性能。

分片枚举

通过在配置文件中配置可能的枚举id,自己的配置分片,本规则适用于特定的场景,比如有些业务需要按照省 份或区县来做保存,而全国省份区县固定的,这类业务使用本条规则,配置如下:

<tableRule name=”sharding-by-intfile”>
<rule>
    <columns>user_id</columns>
    <algorithm>hash-int</algorithm>
</rule>
</tableRule>
<function name=”hash-int” class=”org.opencloudb.route.function.PartitionByFileMap”>
<property name=”mapFile”>partition-hash-int.txt</property>
<property name=”type”>0</property>
<property name=”defaultNode”>0</property>
</function>

partition-hash-int.txt 配置:
10000=0
10010=1
DEFAULT_NODE=1
/**
 *defaultNode默认节点:小于0表示不设置默认节点,大于等于0表示设置默认节点
 *默认节点的作用:枚举分片时,如果碰到不识别的枚举值,就让它路由到默认节点。
 *如果不配置默认节点(defaultNode值小于0表示不配置默认节点),碰到不识别的枚*举值就会报错。
*like this:can’t find datanode for sharding column:column_name val:fffffff
 */

上面columns标识将要分片的表字段,algorithm分片函数。 其中分片函数配置中,mapFile标识配置文件名称,type默认值为0,0表示Integer,非零表示String,所有的节点配置都是从0开始,以及0代表节点1。

固定分片hash算法

本条规则类似于十进制的求模运算,在连续插入1-10时候,1-10会被分到1-10个分片,增大了插入的事务控制难度,而此算法根据二进制则可能会分到连续的分片,减少插入事务控制难度。

<tableRule name=”rule1”>
<rule>
    <columns>user_id</columns>
    <algorithm>func1</algorithm>
</rule>
</tableRule>
<function name=”func1” class="org.opencloudb.route.function.PartitionByLong">
<property name=”partitionCount”>2,1</property>
<property name=”partitionLength”>256,512</property>
</function>

配置说明: 上面 columns 标识将要分片的表字段,algorithm 分片函数,partitionCount 分片个数列表,partitionLength分片范围列表分区长度:默认为最大2^n=1024,即最大支持1024分区。 约束: count,length两个数组的长度必须是一致的。 1024 = sum((count[i] * length[i])).count和length两个向量的点积恒等于1024

用法例子: 本例的分区策略:希望将数据水平分成3份,前两份各占25%,第三份占50%。(故本利非均匀分区)

// |<————————–1024———————————–>| // |<——256—–>|<——256—–>|<————–512————–>| // | partition0 | partition1 | partition2 | // | 共 2 份,故 count[0]=2 | 共 1 份,故 count[1]=1 | int[] count = new int[] { 2, 1 }; int[] length = new int[] { 256, 512 }; PartitionUtil pu = new PartitionUtil(count, length); //下面代码演示分别以offerId字段或memberId字段根据上述分区策略拆分的分配结果 int DEFAULT_STR_HEAD_LEN = 8; // cobar默认会配置为此值 long offerId = 12345; String memberId = “qiushuo”; //若根据offerId分配,partNo1将等于0,即按照上述分区策略,offerId为12345时将会被分配到partition0中 int partNo1 = pu.partition(offerId); //若根据memberId分配,partNo2将等于2,即按照上述分区策略,memberId为qiushuo时将会被分到partition2中 int partNo2 = pu.partition(memberId, 0, DEFAULT_STR_HEAD_LEN);

如果需要平均分配设置:平均分为 4 分片,partitionCount*partitionLength=1024

4 256

范围约定

此分片适用于提前规划好分片字段某个范围属于哪个分片

start <= range <= end.
    range start-end ,data node index
K=1000,M=10000. 
<tableRule name="auto-sharding-long">
<rule>
    <columns>user_id</columns>
    <algorithm>rang-long</algorithm>
</rule>
</tableRule>
<function name="rang-long" class="org.opencloudb.route.function.AutoPartitionByLong">
<property name="mapFile">autopartition-long.txt</property>
<property name="defaultNode">0</property>
</function>

配置说明: 上面 columns 标识将要分片的表字段,algorithm 分片函数, rang-long 函数中 mapFile 代表配置文件路径 defaultNode 超过范围后的默认节点。 所有的节点配置都是从 0 开始,及 0 代表节点 1,此配置非常简单,即预先制定可能的 id 范围到某个分片 0-500M=0 500M-1000M=1 1000M-1500M=2 或 0-10000000=0 10000001-20000000=1

取模

此规则为对分片字段求模运算

<tableRule name="mod-long">
<rule>
<columns>user_id</columns>
<algorithm>mod-long</algorithm>
</rule>
</tableRule>
<function name="mod-long" class="org.opencloudb.route.function.PartitionByMod">
<!-- how many data nodes  -->
<property name="count">3</property>
</function>

配置说明: 上面 columns 标识将要分片的表字段,algorithm 分片函数,此种配置非常明确即根据 id 进行十进制求模预算,相比固定分片 hash,此种在批量插入时可能存在批量插入单 事务插入多数据分片,增大事务一致性难度。

按日期(天)分片

此规则为按天分片

<tableRule name="sharding-by-date">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-date</algorithm>
</rule>
</tableRule>
<function name="sharding-by-date"
class="org.opencloudb.route.function.PartitionByDate">
<property name="dateFormat">yyyy-MM-dd</property> 
<property name="sBeginDate">2014-01-01</property>
<property name="sEndDate">2014-01-02</property>
<property name="sPartionDay">10</property>
</function>

配置说明: columns :标识将要分片的表字段 algorithm :分片函数 dateFormat :日期格式 sBeginDate :开始日期 sEndDate:结束日期 sPartionDay :分区天数,即默认从开始日期算起,分隔 10 天一个分区 如果配置了 sEndDate 则代表数据达到了这个日期的分片后后循环从开始分片插入。

Assert.assertEquals(true, 0 == partition.calculate(“2014-01-01”)); 
Assert.assertEquals(true, 0 == partition.calculate(“2014-01-10”)); 
Assert.assertEquals(true, 1 == partition.calculate(“2014-01-11”)); 
Assert.assertEquals(true, 12 == partition.calculate(“2014-05-01”));

取模范围约束

此种规则是取模运算与范围约束的结合,主要为了后续数据迁移做准备,即可以自主决定取模后数据的节点分布。

<tableRule name="sharding-by-pattern">
<rule>
<columns>user_id</columns>
<algorithm>sharding-by-pattern</algorithm>
</rule>
</tableRule>
<function name="sharding-by-pattern"
class="org.opencloudb.route.function.PartitionByPattern">
<property name="patternValue">256</property>
<property name="defaultNode">2</property>
<property name="mapFile">partition-pattern.txt</property>
</function>

partition-pattern.txt

# id partition range start-end ,data node index
###### first host configuration
1-32=0
33-64=1
121

65-96=2
97-128=3
######## second host configuration
129-160=4
161-192=5
193-224=6
225-256=7
0-0=7

配置说明: 上面 columns 标识将要分片的表字段,algorithm 分片函数,patternValue 即求模基数,defaoultNode 默认节点,如果配置了默认,则不会按照求模运算 mapFile 配置文件路径 配置文件中,1-32 即代表 id%256 后分布的范围,如果在 1-32 则在分区 1,其他类推,如果 id 非数据,则 会分配在 defaoultNode 默认节点.

String idVal = “0”; 
Assert.assertEquals(true, 7 == autoPartition.calculate(idVal)); 
idVal = “45a”; 
Assert.assertEquals(true, 2 == autoPartition.calculate(idVal));

一致性hash

一致性 hash 预算有效解决了分布式数据的扩容问题。

<tableRule name="sharding-by-murmur">
<rule>
<columns>user_id</columns>
<algorithm>murmur</algorithm>
</rule>
</tableRule>
<function name="murmur" class="org.opencloudb.route.function.PartitionByMurmurHash">
<property name="seed">0</property><!--默认是0-->
<property name="count">2</property><!--要分片的数据库节点数量,必须指定,否则没法分片-->
<property name="virtualBucketTimes">160</property><!--一个实际的数据库节点被映射为这么多虚拟
节点,默认是160倍,也就是虚拟节点数是物理节点数的160倍-->
<!--
<property name="weightMapFile">weightMapFile</property>
节点的权重,没有指定权重的节点默认是1。以properties文件的格式填写,以从0开始到count-1的整数值也就
是节点索引为key,以节点权重值为值。所有权重值必须是正整数,否则以1代替   -->
<!--
<property name="bucketMapPath">/etc/mycat/bucketMapPath</property>
用于测试时观察各物理节点与虚拟节点的分布情况,如果指定了这个属性,会把虚拟节点的murmur hash值与物理节
点的映射按行输出到这个文件,没有默认值,如果不指定,就不会输出任何东西  -->
</function>

按单月小时拆分

此规则是单月内按照小时拆分,最小粒度是小时,可以一天最多 24 个分片,最少 1 个分片,一个月完后下月 从头开始循环。 每个月内按照小时拆分,最小粒度是小时,可以一天最多24个分片,一个月完后下月开始循环。 每个月月尾,需要手工清理数据。

<tableRule name="sharding-by-hour">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-hour</algorithm>
</rule>
</tableRule>
<function name="sharding-by-hour"
class="org.opencloudb.route.function.LatestMonthPartion">
<property name="splitOneDay">24</property>
</function>

配置说明:

columns: 拆分字段,字符串类型(yyyymmddHH) splitOneDay : 一天切分的分片数 LatestMonthPartion partion = new LatestMonthPartion(); partion.setSplitOneDay(24); Integer val = partion.calculate(“2015020100”); assertTrue(val == 0); val = partion.calculate(“2015020216”); assertTrue(val == 40); val = partion.calculate(“2015022823”); assertTrue(val == 27 * 24 + 23);

Integer[] span = partion.calculateRange(“2015020100”, “2015022823”); assertTrue(span.length == 27 * 24 + 23 + 1);

assertTrue(span[0] == 0 && span[span.length - 1] == 27 * 24 + 23); span = partion.calculateRange(“2015020100”, “2015020123”); assertTrue(span.length == 24); assertTrue(span[0] == 0 && span[span.length - 1] == 23);

范围求模分片

先进行范围分片计算出分片组,组内再求模 优点可以避免扩容时的数据迁移,又可以一定程度上避免范围分片的热点问题 综合了范围分片和求模分片的优点,分片组内使用求模可以保证组内数据比较均匀,分片组之间是范围分片可以兼顾范围查询。 最好事先规划好分片的数量,数据扩容时按分片组扩容,则原有分片组的数据不需要迁移。由于分片组内数据比较均匀,所以分片组内可以避免热点数据问题。

<tableRule name="auto-sharding-rang-mod">
<rule>
    <columns>id</columns>
    <algorithm>rang-mod</algorithm>
</rule>
</tableRule>
<function name="rang-mod"
class="org.opencloudb.route.function.PartitionByRangeMod">
    <property name="mapFile">partition-range-mod.txt</property>
    <property name="defaultNode">21</property>
</function>

配置说明: 上面 columns 标识将要分片的表字段,algorithm 分片函数 rang-mod 函数中 mapFile 代表配置文件路径 defaultNode 超过范围后的默认节点顺序号,节点从 0 开始。

partition-range-mod.txt range start-end ,data node group size 以下配置一个范围代表一个分片组,=号后面的数字代表该分片组所拥有的分片的数量。 0-200M=5 //代表有 5 个分片节点

200M1-400M=1 400M1-600M=4 600M1-800M=4 800M1-1000M=6

日期范围hash分片

思想与范围求模一致,当由于日期在取模会有数据集中问题,所以改成 hash 方法。 先根据日期分组,再根据时间 hash 使得短期内数据分布的更均匀

优点可以避免扩容时的数据迁移,又可以一定程度上避免范围分片的热点问题 要求日期格式尽量精确些,不然达不到局部均匀的目的

<tableRule name="rangeDateHash">
<rule>
    <columns>col_date</columns>
    <algorithm>range-date-hash</algorithm>
</rule>
</tableRule>
<function name="range-date-hash"
class="org.opencloudb.route.function.PartitionByRangeDateHash">
    <property name="sBeginDate">2014-01-01 00:00:00</property>
    <property name="sPartionDay">3</property>
    <property name="dateFormat">yyyy-MM-dd HH:mm:ss</property>
    <property name="groupPartionSize">6</property>
</function>

sPartionDay 代表多少天分一个分片 groupPartionSize 代表分片组的大小

冷热数据分片

根据日期查询日志数据 冷热数据分布 ,最近 n 个月的到实时交易库查询,超过 n 个月的按照 m 天分片。

<tableRule name="sharding-by-date"> 
      <rule> 
        <columns>create_time</columns> 
        <algorithm>sharding-by-hotdate</algorithm> 
      </rule> 
   </tableRule>   
<function name="sharding-by-hotdate" class="org.opencloudb.route.function.PartitionByHotDate"> 
    <property name="dateFormat">yyyy-MM-dd</property> 
    <property name="sLastDay">10</property> 
    <property name="sPartionDay">30</property> 
</function>

自然月分片

按月份列分区 ,每个自然月一个分片,格式 between 操作解析的范例。

<tableRule name="sharding-by-month">
<rule>
<columns>create_time</columns>
<algorithm>sharding-by-month</algorithm>
</rule>
</tableRule>
<function name="sharding-by-month"
class="org.opencloudb.route.function.PartitionByMonth">
<property name="dateFormat">yyyy-MM-dd</property>
<property name="sBeginDate">2014-01-01</property>
</function>

配置说明: columns: 分片字段,字符串类型 dateFormat : 日期字符串格式 sBeginDate : 开始日期

PartitionByMonth partition = new PartitionByMonth(); partition.setDateFormat(“yyyy-MM-dd”); partition.setsBeginDate(“2014-01-01”); partition.init(); Assert.assertEquals(true, 0 == partition.calculate(“2014-01-01”)); Assert.assertEquals(true, 0 == partition.calculate(“2014-01-10”)); Assert.assertEquals(true, 0 == partition.calculate(“2014-01-31”)); Assert.assertEquals(true, 1 == partition.calculate(“2014-02-01”)); Assert.assertEquals(true, 1 == partition.calculate(“2014-02-28”)); Assert.assertEquals(true, 2 == partition.calculate(“2014-03-1”)); Assert.assertEquals(true, 11 == partition.calculate(“2014-12-31”)); Assert.assertEquals(true, 12 == partition.calculate(“2015-01-31”)); Assert.assertEquals(true, 23 == partition.calculate(“2015-12-31”));