当前位置: 主页 > 大数据 >

几种海量数据分库分表

Key可认为主键,也可认为订单号,也可认为用户id,这个需求依据场景决议,哪个作为查询条件概率多用哪个。

 

  • 按需添加库、表,逐渐添加
  • 散布均匀,每一片差异不多

 

  • 许多时分会先从2开始分两个库逐级递增,然后分3个、4个、5个。如在mod 3 变 mod 5的状况下,取模后的大部分的数据的取模成果会改变,如key=3时,mod 3=0,突然改变为mod 5=3,则将会从第0表搬迁到第3表,将会构成许多数据多重复移动方位。
  • 会重复搬迁数据,当分2个时,有数据A在第0号表,分3个时数据A去了第1号表、到分4个时数据A会回到第0号表

能够按日、按月、按季度。

tb_20190101 tb_20190102
tb_20190103
……

长处:

    缺陷:

  • 表0 [0,10000000) 
    表1 [10000000,20000000)
    表2 [20000000,30000000)
    表3 [30000000,40000000)
    ……

     

     

    先说一下一致性hash,有些文章说一致性Hash是一种算法,我认为它并不是详细的核算公式,而是一个设定的思路。

     2. 规划一个公式函数 value = hash(key),这个公式将会有最大值和最小值,如 key mod 64 = value; 这个公式最大为64,最小为0。然后把数据都落在环上。

    这里不详细阐明这个理论,它首要表达的意思是固定好最大值,就不再修正最大值到最小值规模,后续只修正节点node的方位和添加node来到达减少每个node要管的数据,以到达减少压力。

    补白: * 不引荐对ip进行hash,由于可能会导致hash(ip)得出的成果很大,例如得出60,若这个节点的前面没有节点,则60号方位的这个节点需求管大部分的数据了。 * 最好生成key的办法用雪花算法snowFlake来做,至少要是不重复的数字,也不要用自增的形式。 * 引荐阅览铜板街的计划 订单号结尾添加user%64

    利用一致性hash理论,分库挑选hash(key)的公式基准为 value= key mod 64,分表公式value= key / 64 mod 64,key为订单号或许userId等这类经常查询的首要字段。(后续会对这个公式有改变) 咱们假定上述公式,则能够分64个库,每个库64个表,假设一个表1千万行记载。则最大64 * 64 * 1000万数据,我相信不会有这一天的到来,所以咱们以这个作为最大值比较合理,乃至挑选32 * 32都能够。

    以下举例为16组,也便是16个库,group=16 这个时分库的公式为value = key mode 64 / 4 * 4,除以4后,会截取小数位得出一个整数,然后 * 4倍,便是数据地点方位。

    // 按4个为一组,分两个表 count = 4:
    Integer dbValue = userId % 64 / count * count ;

     

    补白:其实一开始能够64个为一组便是一个库,后续改变32个为一组便是两个库,从一个库到两个库,再到4个库,逐渐递进。

      引荐运用场景:日志记载
      • 散布均匀
      • 由于未知最大值,所以无法用时刻戳作为key,这个办法不能用表的自增主键,由于每个表都自增数量不是一致保护。所以需求有一个发号器或发号体系做一致保护key自增的当地。

能够看到当需求进行扩容一倍时需求搬迁一半的数据量,以2^n递增,所以进行影响规模会比较大。

 

  • 假如直接拆分32组,那么就比较一了百了
  • 假如数据量比较大,未做过分表能够用一了百了办法。
  • 散布均匀
  • 搬迁数据时不需求像计划一那样大部分的数据都需求进行搬迁并有重复搬迁,只需求搬迁一半

 

  • 能够扩展,但是影响规模大。
  • 搬迁的数据量比较大,虽然不像计划一那样大部分数据搬迁,当时计划每个表或库都需求一半数据的搬迁。
  • 若要一了百了,则需求全体停机来搬迁数据

(我认为比较好的计划)

解析计划四问题地点

计划四对应搬迁计划:

咱们基于现已发生过1次迭代分了两个库的状况来做后续迭代演示,首先看看现已拆分两个库的状况:


 在代码中,咱们先把分组从32个一组改为16个一组,再给代码特别处理 0~16的去到新的节点 16~32走回本来的32号节点 32~63走回本来64号节点 所以下面就要对节点特别if else

// 按32改为16个为一组,分两变为4个库 count = 16;
Integer dbValue = userId  % 64 / count * count ; if(dbValue<16){ // 上一个迭代这些数据落在db32中,现在走新增节点名为db16号的那个库 dbValue = 16; return dbValue;
} else { // 按本来规则走 return dbValue;
}

 这样就能够分迭代完结计划四种的一轮的搬迁

 

如此类推,下一轮一共8个节点时,每次搬迁只需求搬迁1/8。

长处:

    计划五详解
    • 缺陷:
    •  

      userId % 64 / count * count

      当然规模能够自定义,看取模后落入哪个值的数量比较多,就切某一片数据就好了,详细就不画图了,跟计划四相似。

        计划六:一致性Hash理念——按规模分库(迭代搬迁)<p font-size:16px;background-color:#ffffff;"="" style="overflow-wrap: break-word; margin: 5px 0px; color: rgb(51, 51, 51);">由于搬迁数据的原因,计划四中,假如数据量大,到达1000万行记载,每次搬迁都需求搬迁许多的数据,所以许多公司会尽早分库分表。
  • 发表于: