一、分表键的抉择

什么是分表键

分表键即分库/分表字段，zebra外面叫做维度，是在程度拆分过程中用于生成拆分规定的数据表字段。Zebra 依据分表键的值将数据表程度拆分到每个物理分库中。

数据表拆分的首要准则，就是要尽可能找到数据表中的数据在业务逻辑上的主体，并确定大部分（或外围的）数据库操作都是围绕这个主体的数据进行，而后可应用该主体对应的字段作为分表键，进行分库分表。

业务逻辑上的主体，通常与业务的利用场景相干，上面的一些典型利用场景都有明确的业务逻辑主体，可用于分表键：

  • 面向用户的互联网利用，都是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可应用用户对应的字段作为分表键；                   
  • 侧重于卖家的电商利用，都是围绕卖家维度来进行各种操作，那么业务逻辑主体就是卖家，可应用卖家对应的字段作为分表键；

以此类推，其它类型的利用场景，大多也能找到适合的业务逻辑主体作为分表键的抉择。

如果的确找不到适合的业务逻辑主体作为分表键，那么能够思考上面的办法来抉择分表键：

  • 依据数据分布和拜访的平衡度来思考分表键，尽量将数据表中的数据绝对平均地散布在不同的物理分库/分表中，实用于大量剖析型查问的利用场景（查问并发度大部分能维持为1）；
  • 依照数字（字符串）类型与工夫类型字段相结合作为分表键，进行分库和分表，实用于日志检索类的利用场景。

留神：无论抉择什么拆分键，采纳何种拆分策略，都要留神拆分值是否存在热点的问题，尽量躲避热点数据来抉择拆分键。

留神：不肯定须要拿数据库主键当做分表键，也能够拿其余业务值当分表键。拿主键当分表键的益处是能够散列平衡，缩小热点问题。

多个分表键如何解决

大部分场景下，一张表的查问条件比拟繁多，只须要一个分表键即可；然而有的时候，业务必须要有多个分表键，没有方法归一成一个。此时个别有四种解决形式：

名词定义：

  • 主分表键=主维度，在主维度上，数据可能增删改查；
  • 辅助分表键=辅维度，在辅助维度上，只能进行数据查问

在主维度上全表扫描

因为SQL中没有主维度，所以在对辅助维度进行查问时，只能在所有的主维度的表进行查问一遍，而后聚合。目前zebra的并发粒度是在数据库级别的，也就是说如果分了4个库，32张表，最终会以4个线程去并发查问32张表，最终把后果合并输入。

实用场景：辅助维度的查问申请的量很小，并且是经营查问，对性能要求不高

多维度数据进行冗余同步

主维度的数据，通过binlog的形式，同步到辅助维度一份。那么在查问辅助维度时，会落到辅助维度的数据上进行查问。

实用场景：辅助维度的查问申请的量也很可观，不能间接应用第一种全表扫描的形式

二维奇妙归一维

辅助维度其实有的时候也是主维度，比方在订单表Order中，OrderID和UserID其实是一一对应的，Order表的主维度是UserID，OrderID是辅助维度，然而因为OrderID其中的6位和UserID完全一致，也就是说，在OrderID中会把UserID打进去。

在路由的时候，如果SQL中带有UserID，那么间接拿UserID进行Hash取模路由；如果SQL中带有的OrderID维度，那么取出OrderID中的6位UserID进行Hash取模路由，后果是统一的。

实用场景：辅助维度和主维度其实能够通过将主维度和辅助维度的值进行信息共享

建设索引表

对于辅助维度能够建一张辅助维度和主维度的映射表。

举例来说，表A有两个维度，主维度a，辅助维度b，目前只有主维度的一份数据。

此时，如果有SQL： select * from A where b = ？过去，那么势必会在主维度上进行全表扫描。

那么建一张新表B_A_Index，外面就只有两个字段，a和b的值，这张表能够分表，也能够不分表，倡议分表这张表的主维度就是b。

所以能够先查：select  a  from B_A_Index where b = ?，取得到a的值，而后 查问 select * from A where a = 查问到的值 and b = ? 进行查问。

试用场景：主副维度是一一对应的。劣势是，无需数据冗余，只须要冗余一份索引数据。毛病是，须要业务进行稍微的革新。

二、分片数的抉择

zebra 中的程度拆分有两个档次：分库和分表。

表数目决策

个别状况下，倡议单个物理分表的容量不超过1000万行数据。通常能够预估2到5年的数据增长量，用估算出的总数据量除以总的物理分库数，再除以倡议的最大数据量1000万，即可得出每个物理分库上须要创立的物理分表数：

  • （将来3到5年内总共的记录行数)  /  单张表倡议记录行数              （单张表倡议记录行数  =  1000万）

表的数量不宜过多，波及到聚合查问或者分表键在多个表上的SQL语句，就会并发到更多的表上进行查问。举个例子，分了4个表和分了2个表两种状况，一种须要并发到4表上执行，一种只须要并发到2张表上执行，显然后者效率更高。

表的数目不宜过少，少的害处在于一旦容量不够就又要扩容了，而分库分表的库想要扩容是比拟麻烦的。个别倡议一次分够。

倡议表的数目是2的幂次个数，不便将来可能的迁徙。

库数目决策

  • 计算公式：依照存储容量来计算 = （3到5年内的存储容量）/  单个库倡议存储容量                    （单个库倡议存储容量  <300G以内）

DBA的操作，个别状况下，会把若干个分库放到一台实例下来。将来一旦容量不够，要产生迁徙，通常是对数据库进行迁徙。所以库的数目才是最终决定容量大小。

最差状况，所有的分库都共享数据库机器。最优状况，每个分库都独占一台数据库机器。个别倡议一个数据库机器上寄存8个数据库分库。

三、分表策略的抉择

分表形式解释长处毛病试用场景版本要求
Hash拿分表键的值Hash取模进行路由。最罕用的分表形式。数据量散列平衡，每个表的数据量大致相同 申请压力散列平衡，不存在拜访热点一旦现有的表数据量须要再次扩容时，须要波及到数据挪动，比拟麻烦。所以个别倡议是一次性分够。在线服务。个别均以UserID或者ShopID等进行hash。任意版本
Range拿分表键依照ID范畴进行路由，比方id在1-10000的在第一个表中，10001-20000的在第二个表中，顺次类推。这种状况下，分表键只能是数值类型。1.数据量可控，能够平衡，也能够不平衡. 2.扩容比拟不便，因为如果ID范畴不够了，只须要调整规定，而后建好新表即可。无奈解决热点问题，如果某一段数据拜访QPS特地高，就会落到单表上进行操作。离线服务。2.9.4以上
工夫拿分表键依照工夫范畴进行路由，比方工夫在1月的在第一个表中，在2月的在第二个表中，顺次类推。这种状况下，分表键只能是工夫类型。扩容比拟不便，因为如果工夫范畴不够了，只须要调整规定，而后建好新表即可1.数据量不可控，有可能单表数据量特地大，有可能单表数据量特地小 2.无奈解决热点问题，如果某一段数据拜访QPS特地高，就会落到单表上进行操作。离线服务。比方线下经营应用的表、日志表等等

1.依照UserID进行Hash分表，依据UserID进行查问

XML格局

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="id">  <shard-dimension dbRule="#UserID#.toInteger()%32" dbIndexes="order_test[0-31]"  tbRule="#UserID#.toInteger().intdiv(32)%32" tbSuffix="alldb:[0,1023]"  isMaster="true">  </shard-dimension>  </table-shard-rule></router-rule>

Order表的UserID维度一共分了32个库，别离是order_test0到order_test31。一共分了1024张表，表名分表是Order0到Order1023，平均分到了32个库中，每个库32张表。

2.依照UserID进行Hash分表，依据UserID和ShopID进行查问

XML格局

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="OrderID"> <shard-dimension dbRule="#UserID#.toInteger()%10000%32" dbIndexes="order_test[0-31]"  tbRule="(#UserID#.toInteger()%10000).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="true"> </shard-dimension> <shard-dimension dbRule="#ShopID# == null ? SKIP : (#ShopID#.toInteger()%16)" dbIndexes="order_shop_test[0-15]"  tbRule="(#ShopID#.toInteger()).intdiv(16) %16" tbSuffix="alldb:[0,255]" needSync="true" isMaster="false"> </shard-dimension> </table-shard-rule></router-rule>

Order表的ShopID维度的数据是依据UserID的数据从新通过binlog同步了一份。该份数据分了16个库，别离是order_shop_test0到order_shop_test15。一共分了256张表，每个库16张表，表名分表是Order0到Order255。

其中zebra会负责依据该配置，把UserID维度的数据主动的同步到ShopID维度，背地是通过binlog形式，所以会有needSync的属性。**然而，该性能目前曾经永久性停用，如果须要应用，请自行接入DTS/DataBus。

3.依据UserID进行Hash分表，依据UserID和OrderID进行查问

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="OrderID"> <shard-dimension dbRule="#UserID#.toInteger()%10000%32" dbIndexes="order_test[0-31]"  tbRule="(#UserID#.toInteger()%10000).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="true"> </shard-dimension> <shard-dimension dbRule="#OrderID#[13..16].toInteger() % 32" dbIndexes="order_test[0-31]"  tbRule="(#OrderID#[13..16].toInteger()).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="false"> </shard-dimension> </table-shard-rule></router-rule>

Order表的OrderID维度的数据和UserID的数据是统一的，并没有冗余。然而因为OrderID中的13到16位就是UserID，所以能够应用UserID的数据进行查问。实质上，OrderID和UserID必定能一一对应，其实是一个维度。

4.依据UserID进行Hash分表，依据AddTime汇总大表供线下经营查问

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="OrderID"> <shard-dimension dbRule="#UserID#.toInteger()%10000%32" dbIndexes="order_test[0-31]"  tbRule="(#UserID#.toInteger()%10000).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="true"> </shard-dimension> <shard-dimension dbRule="#AddTime# == null ? SKIP : 0" dbIndexes="order_one"  tbRule="#AddTime# == null ? SKIP : 0" tbSuffix="alldb:[]" needSync="true" isMaster="false"> </shard-dimension> </table-shard-rule></router-rule>

Order表的AddTime维度，其实是通过binlog的形式把UserID的数据汇总到了order_one这个库，表名为Order这个表。这个汇总的过程是主动的。needSync=true。

线上服务应用ShardDataSource，对UserID的数据进行增删改查。经营服务在拜访经营库order_one时，无需应用ShardDataSource，间接应用GroupDataSource进行拜访，仅做查问应用。

5.依据UserID的crc32值进行Hash分表

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="OrderID"> <shard-dimension dbRule="crc32(#UserID#.toInteger())%10000%32" dbIndexes="order_test[0-31]"  tbRule="(crc32(#UserID#.toInteger())%10000).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="true"> </shard-dimension> </table-shard-rule></router-rule>

crc32是目前zebra的一个内置函数。

内置HASH函数

  • crc32(Object value)
  • crc32(Object value,String encode)
  • md5(String value)

6.主维度依据UserID进行Hash分表，辅助维度依据AddTime进行工夫分表

<?xml version="1.0" encoding="UTF-8"?><router-rule> <table-shard-rule table="Order" generatedPK="OrderID"> <shard-dimension dbRule="#UserID#.toInteger()%10000%32" dbIndexes="order_test[0-31]"  tbRule="(#UserID#.toInteger()%10000).intdiv(32) %32" tbSuffix="alldb:[0,1023]" isMaster="true"> </shard-dimension> <shard-dimension dbRule="shardByMonth(#AddTime#,"yyyy-MM-dd", "2017-01-01","2027-01-31",3,0) % 4" dbIndexes="order_time[0-3]"  tbRule="shardByMonth(#AddTime#,"yyyy-MM-dd", "2017-01-01","2027-01-31",3,0).intdiv(4)% 10" tbSuffix="alldb:[0,39]" needSync="true" isMaster="false"> </shard-dimension> </table-shard-rule></router-rule>

Order表的AddTime维度，其实是通过binlog的形式把UserID的数据从新依据工夫进行分表的，上述例子中，一共分了4个库，40张表，3个月一张表，涵盖10年的量。

线上零碎间接应用ShardDataSource应用UserID维度，线下经营零碎也是用ShardDataSource，如果带了AddTime，都会落到AddTime维度的数据上进行查问。反对>,<,>=,<=,between and等范畴查问；不反对Join。

内置工夫函数

  • shardByMonth("#CreateTime",String timeFormat, String startTime, String end, int monthPerTable, int defaultTableIndex)
    该函数是依据月份进行计算路由的。其中，startTime和endTime表明起始工夫和完结工夫，monthPerTable是指从起始工夫开始几个月一张表，defaultTableIndex是指如果超出了起始工夫和完结工夫时到一张默认的表的Index。