加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

从分库分表后遗症,总结数据库表拆分计策

发布时间:2018-08-15 15:55:32 所属栏目:编程 来源:王清培(沪江)
导读:技能沙龙 | 邀您于8月25日与国美/AWS/转转三位专家配合切磋小措施电商拭魅战 本文将首要从配景、分库分表带来的后遗症、分表计策以及一些留意事项等方面临数据库分表来举办小结。 一、配景 最近一段时刻内竣事了数据库表拆分项目,本次拆分首要包罗订单和优惠

我们假设上面是一个订单列表,orderID订单号各人就不要在意次序性了。由于Sharding之后全部的orderID城市由发号器同一发放,多个集群多个斲丧者同时获取,可是建设订单的速率是纷歧样的,以是次序性已经不存在了。

上面的两个Sharding node根基上订单号是交错的,假如凭证时刻排序node 1和node 2是要瓜代获取数据。

好比我们的查询前提和分页参数:

  1. where createDateTime>'2018-01-11 00:00:00'  
  2. pageParameter:pageSize:5、currentPage:1 

获取的功效集为:

  1. orderID     createDateTime  
  2. 100000      2018-01-10 10:10:10  
  3. 200000      2018-01-10 10:10:11  
  4. 300000      2018-01-10 10:10:12  
  5. 400000      2018-01-10 10:10:13  
  6. 110000      2018-01-11 10:10:10 

前面4笔记录来自node 1后头1条数据来自node 2 ,整个排序荟萃为:

  1. Sharding node 1:orderID     createDateTime  
  2. 100000      2018-01-10 10:10:10  
  3. 200000      2018-01-10 10:10:11  
  4. 300000      2018-01-10 10:10:12  
  5. 400000      2018-01-10 10:10:13  
  6. 500000      2018-01-20 10:10:10  
  7.  
  8. Sharding node 2:orderID     createDateTime  
  9. 110000      2018-01-11 10:10:10  
  10. 220000      2018-01-11 10:10:11  
  11. 320000      2018-01-11 10:10:12  
  12. 420000      2018-01-11 10:10:13  
  13. 520000      2018-01-21 10:10:10 

凭证这样一向翻页下去每翻页一次就必要在node 1 、node 2多获取5条数据。这里我们可以通过修改查询前提来让整个翻页变为从头查询。

  1. where createDateTime>'2018-01-11 10:10:13' 

由于我们可以确定在‘2018-01-11 10:10:13’时刻之前全部的数据都已经查询过,可是为什么时刻不是从‘2018-01-21 10:10:10’开始,由于我们要思量并发环境,在1s内会有多个订单进来。

这种方法是实现最简朴,不必要借助外部的计较来支撑。这种方法有一个题目就是要想从头计较分页的时辰不丢失数据就必要保存原本一条数据,这样才气知道开始的时刻在那边,这样就会在下次的分页中看到这条时刻。可是从真实的深分页场景来看也可以忽略,由于很少有人会一页一页一向到翻到500页,而是直接跳到最后几页,这个时辰就不存在谁人题目。

假如非要精准节制这个毛病就必要记着区间,可能用其他方法来实现了,好比全量查询表、Sharding索引表、最大下单tps值之类的,用来帮助计较。(可以操作数据同步中间件成立单表多级索引、多表多维度索引来帮助计较。我们行使到的数据同步中间件有datax、yugong、otter、canal可以办理全量、增量同步题目)。

三、分表计策

分表有多种方法,mod、rang、preSharding、自界说路由,每种方法都有必然的偏重。

我们首要行使mod + preSharding的方法,这种方法带来的最大的一个题目就是后期的节点变换数据迁徙题目,可以通过参考同等性Hash算法的假造节点来办理。

数据表拆分和Cache Sharding有一些区别,cache能接管cache miss ,通过被动缓存的方法可以维护起cache数据。可是数据库不存在select miss这种场景。

在Cache Sharding场景下同等性Hash可以用来消除镌汰、增进Sharding node时相邻分片压力题目。可是数据库一旦呈现数据迁徙,必然是不能接管数据查询不出来的。以是我们为了未来数据的滑腻迁徙,做了一个假造节点 + 真实节点mapping 。

  1. physics node : node 1 node 2 node 3 node 4  
  2. virtual node : node 1 node 2 node 3.....node 20  
  3. node mapping :  
  4. virtual node 1 ~ node 5 {physics node 1}  
  5. virtual node 6 ~ node 10 {physics node 2}  
  6. virtual node 11 ~ node 15 {physics node 3}  
  7. virtual node 16 ~ node 20 {physics node 4} 

为了镌汰未来迁徙数据时rehash的本钱和耽误的开销,将Hash后的值生涯在内外,未来迁徙直接查询出来快速导入。

Hash片2的次方题目

(编辑:湖南网)

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

热点阅读