Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >一些补充的知识点-MySQL大表分库分表基因法

一些补充的知识点-MySQL大表分库分表基因法

作者头像
用户4283147
发布于 2023-12-28 08:57:09
发布于 2023-12-28 08:57:09
3391
举报
文章被收录于专栏:对线JAVA面试对线JAVA面试
场景

1.确认需求:一张订单表,三个字段:user_id,order_id,amount;假设一天会产生10亿的数据,现在需要根据user_id 和 order_id查询数据;

2.需求分析:数据库磁盘、cpu必然压力巨大,需要分库+分表;

索引表法
  1. 10个库+每个库100张表,平均每张表每天会产生100w的数据,这样每张表每个月就会产生3000w的数据,在这个表中我们可以至保留一个月的数据,其余的数据归档数据仓库,比如我们需要olap场景,就归档至clickhouse、es等;
  2. 我们需要根据user_id、order_id,这两个字段对订单进行查询,我们先对order_id进行分片键设计;
  3. hash(order_id) % 10 得到库,hash(order_id) % 100 的到表
  4. 为了能通过user_id查询order_id,需要额外建一张user_id->order_id的索引表,这个索引表也需要根据user_id作为分片键进行相应的分库分表;
  5. 这样我们通过order_id能够直接定位数据库的表进行查询,通过user_id先查order_id再通过order_id再查具体内容,满足需求;
  6. 上面的做法可以实现需求,但是通过user_id查询订单时,需要多进行一次查询,效率降低了一倍;并且索引表也需要进行分库分表,当然索引也可以考虑其他存储介质,如Hbase,或者增加缓存来提高索引效率;如果需要某个用户订单列表的话,还需要在应用层做数据整合,很麻烦;
基因法
  1. 我们考虑有没有一种做法,可以把一个用户的所有订单数据都落到同一个库同一个表中,这样不管是通过user_id定位,还是通过order_id都能准确定位到数据,解决了引入索引表的复杂性,并且解决了应用层整合数据的麻烦;
  2. 解析一下基因法的思想,我们希望达到的效果是,一个用户的所有数据都落到同一个库中的同一个表,那么我们可以先对user_id进行取余,落库,然后在生成order_id时就不能随便生成了,需要从user_id中提取基因,在生成order_id的时候,把这个基因放到order_id的生成过程中,这样生成出来的order_id通过取余等运算就能得到和user_id一致的结果了,也就是达到了同一个用户的所有数据都落到同一个库的同一个表中的效果;
  3. 现在我们把焦点集中在了“基因”这个点上,我们先来看看一个数a对另外一个数b(数b为2^n)进行取余时,其实本质上最后的结果就是a这个数二进制的最后(n+1)位,举个例子:9%4 = 1(1001 % 100 = 001)/ 10 % 4 = 2 (1010 % 100 = 010),那么我们在生成订单id 的时候,只要把order_id二进制的最后(n+1)位的二进制数设置为user_id的最后(n+1)位,那么我们对user_id/order_id取余都能得到相同的结果了。(原理:比n+1位高的值,都是b数的倍数,取余时直接归零,所以取余就是取二进制最后n+1位)
  4. 了解原理后,我们只需要重新合理设计分库分表的数量,让其都是 2^n,我们重设 16个库每个库64张表 ;
  5. hash(user_id)% 16 定位库的位置, hash(user_id)% 64 定位表的位置
  6. 生成order_id ,对user_id提取一个基因 % 64 也就是二进制最后 7位,把这个最后7位二进制也作为order_id的二进制最后7位,这样就能保证order_id的路由结果与user_id完全一致;
  7. 通过基因法,不管是通过order_id查询数据,还是通过user_id查询数据,都能准确定位到具体的表,效率高;
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-12-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 对线JAVA面试 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
1 条评论
热度
最新
a对b(数b为2^n)进行取余时,结果的二进制形式,等于a写成二进制的后n位,不是n+1位吧
a对b(数b为2^n)进行取余时,结果的二进制形式,等于a写成二进制的后n位,不是n+1位吧
回复回复点赞举报
推荐阅读
编辑精选文章
换一批
分库分表方案(下)
根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。
陈不成i
2021/06/08
1.2K0
分库分表经典15连问
大家好,我是田螺。我们去面试的时候,几乎都会被问到分库分表。田螺哥整理了分库分表的15道经典面试题,大家看完肯定会有帮助的。
捡田螺的小男孩
2022/12/29
1.8K0
分库分表经典15连问
数据库之分库分表 - 垂直?水平?
第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。
物流IT圈
2019/07/16
7760
数据库之分库分表 - 垂直?水平?
基因分库分表
    数据存储中,相互关系的表,尽量分库时落到同一个库中,避免遍历多个库查询,而且还能避免分布式事务。
sdcuike
2020/01/26
1.9K0
分库分表初探
面试官:这边有个数据库-单表1千万数据,未来1年还会增长多500万,性能比较慢,说下你的优化思路
Joseph_青椒
2023/08/02
5920
分库分表初探
分库分表下ID如何设计??
例如数据库有一条数据生成的时间为2024年9月12日 , 数据库有三个 , 每个数据库中数据表也有三个, 那么这条数据应该放在第三个数据库(2024 % 3 = 2)中的第一个表(12 % 3 = 0)中
天下之猴
2024/09/14
1690
分库分表下ID如何设计??
分库分表的正确姿势,你GET到了么?
以支付宝用户为例,8亿;微信用户更是10亿。订单表更夸张,比如美团外卖,每天都是几千万的订单。淘宝的历史订单总量应该百亿,甚至千亿级别,这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。
kirito-moe
2019/11/05
6510
分库分表的正确姿势,你GET到了么?
数据库分库分表思路
关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间。
lyb-geek
2019/06/17
7260
java多用户商城系统架构篇——分库分表
目前公司数据量已经上来,单表最大已经5千万,之前使用分区表,用起来有很多需要注意的地方,以及坑等。
数商云
2019/07/03
8100
分库分表核心理念
首先,我们需要知道所谓的"分库分表",根本就不是一件事,而是三件事,它们要解决的问题也都不一样。
BookSea
2024/09/11
1720
分库分表核心理念
分库分表的正确姿势,你GET到了么?
以支付宝用户为例,8亿;微信用户更是10亿。订单表更夸张,比如美团外卖,每天都是几千万的订单。淘宝的历史订单总量应该百亿,甚至千亿级别,这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。
java进阶架构师
2018/12/25
9640
分库分表的正确姿势,你GET到了么?
MySQL:分库分表知识点盘点
不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。
栗筝i
2022/12/01
4310
MySQL:分库分表知识点盘点
好好的系统,为什么要分库分表?
今天是《分库分表 ShardingSphere 原理与实战》系列的开篇文章,之前写过几篇关于分库分表的文章反响都还不错,到现在公众号:程序员小富后台不断的有人留言、咨询分库分表的问题,我也没想到大家对于分库分表的话题会这么感兴趣,可能很多人的工作内容业务量较小很难接触到这方面的技能。这个系列在我脑子里筹划了挺久的,奈何手说啥也不干活,就一直拖到了现在。
程序员小富
2022/11/25
9260
前任都能看懂的分库分表方案
我们都知道,随着业务量的增长,数据量也会随之增加,这个时候就需要关注业务大表,因为大表会影响查询性能,DDL变更时间很长,影响业务的可用性,同时导致从库延迟很大,如果业务做了读写分离,导致用户重复操作产生脏数据,例如重复下单。
敖丙
2020/12/08
1.6K0
前任都能看懂的分库分表方案
一文读懂数据库优化之分库分表
作者:tayroctang,腾讯 PCG 后台开发工程师 本文从 5W1H 角度介绍了分库分表手段,其在解决如 IO 瓶颈、读写性能、物理存储瓶颈、内存瓶颈、单机故障影响面等问题的同时也带来如事务性、主键冲突、跨库 join、跨库聚合查询等问题。anyway,在综合业务场景考虑,正如缓存的使用一样,本着非必须勿使用原则。如数据库确实成为性能瓶颈时,在设计分库分表方案时也应充分考虑方案的扩展性,或者考虑采用成熟热门的分布式数据库解决方案,如 TiDB。 阅读此文你将了解: 什么是分库分表以及为什么分库分表 如
腾讯技术工程官方号
2022/12/21
1.8K0
一文读懂数据库优化之分库分表
Mysql分库分表(1) --- 概念篇
前两篇文章重点讲到了Mysql数据库的主从同步和读写分离,使用主从同步实现从数据库从主数据同步数据保持主从数据一致性,读写分离使用主数据库负责写操作,多个从数据库负责读操作,由于从库可以进行拓展,所以处理更多的读请求也没问题。但是如果业务比较多,写请求越来越多要如何处理呢?可能有人说我可以再加一个master分担写操作,但是两个master数据肯定是需要同步的,主主同步 + 主从同步很显然会让我们的系统架构变得更为的复杂。所以本篇文章主要讨论一个对写操作进行切分的技术:分库分表。
创译科技
2019/10/24
1.1K0
你分库分表的姿势对么?——详谈水平分库分表
提起分库分表,对于大部分服务器开发来说,其实并不是一个新鲜的名词。随着业务的发展,我们表中的数据量会变的越来越大,字段也可能随着业务复杂度的升高而逐渐增多,我们为了解决单表的查询性能问题,一般会进行分表操作。
2020labs小助手
2021/10/25
3.2K0
你分库分表的姿势对么?——详谈水平分库分表
【MySQL】MySQL分库分表详解[通俗易懂]
在互联网还未崛起的时代,我们的传统应用都有这样一个特点:访问量、数据量都比较小,单库单表都完全可以支撑整个业务。随着互联网的发展和用户规模的迅速扩大,对系统的要求也越来越高。因此传统的MySQL单库单表架构的性能问题就暴露出来了。而有下面几个因素会影响数据库性能:
全栈程序员站长
2022/07/22
15K0
【MySQL】MySQL分库分表详解[通俗易懂]
相关推荐
分库分表方案(下)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档