分库分表
我们经常把分库分表放在一起说,理论上其实分库和分表达到的效果是相同的,分库分表是为了减轻数据库压力,提高效率。
现代业务越来越复杂,数据量也越来越大,关系型数据库本身就比较容易形成系统瓶颈,单机存储容量,连接数,处理能力都有限。同理单库,单表的处理能力更加有限,所以分库分表中心思想都是将数据分散,使得单一数据库/表的数据量变小来缓解单一数据库的性能问题,从而达到提升数据库性能的目的。
垂直分表/分库
垂直分表定义:将一个表按照字段分为多表,每个表里面都存储其中一部分字段。
垂直分库定义:专库专用,按照业务将表进行分类,分布在不同的数据库中,每个库可以放在不同的服务器上
从描述上直接理解,其实就是把一张表,从上往下切开,把不同的字段分布到不同的表里,因为从业务上,可以区分热点字段和非热点字段,可以依照这个来分。
意义
解决了热点数据的效率问题,分页等操作方便,但是对于大数据量无效。
水平分表分库
水平分表定义:同一个数据库内,对数据行拆分,不影响表结构。
水平分库定义:同一个表的数据按一定规则拆到不同的数据库中,库放在不同的服务器上。
从描述上直接理解,就是把一张表,从左到右切开,分完之后的表字段仍旧相同,但是数据内容是不同的,所有这些水平分表之后的表数据加在一起,才是完整的一份数据。
意义
解决了单库/单表的存储量和性能问题,但是对于一些查询操作增加了难度,对分页也有影响。
实例
假设这样一种情况,有一个订单表,目前有1亿数据,日增量为500万,我们的常用查询为,根据订单id查某条数据,或者根据用户id查用户的订单数据,我们应该如何进行分库分表操作呢?
分析
单表500w - 800w 数据,2G数据; 单库100G, 1w QPS , 5k TPS
这里我们假设该表有10个字段,每个字段100字节,一条数据共1000个字节。
1KB x 1亿约为100G左右。
假设我们本次进行分库分表,想要解决3年内的数据增长,也就是
365天 x 3年 x 500万 x 1KB 数据,约为5221G数据,55亿条左右。
首先我们先明确几个数据,目前我们常用的数据库服务器,按照8G内存来算,每个表大概存800万数据。55亿/800万约为688张表,按照700张表来算。
那么每个库里多少张表呢?这个涉及到qps,可以根据qps来计算一下。这里就不举例了。
计算方法大概就是上面这样
方案
也就是说,我们要进行水平分库分表,有两种方案,一种是按照用户hash,某个用户的所有订单数据都存到一个表里,另一种是按照订单id来hash,这样便于直接通过订单id来查询数据。
第一种
按照用户id来hash进行分表,当我们想要查询某个用户的所有订单,是很方便定位的,但是此时如果我们想通过某个订单id来查,会发现无从查起,所以我们需要另一张用户和订单的关联表(这个表也可以是分库分表的)来进行订单id的辅助查询。
第二种
按照订单id来hash进行分表,当我们使用某个订单id来查询时,很方便定位,但是查用户的订单会很麻烦,从我们表的数量来说,所有表都查一遍不太现实,所以也需要另一张用户和订单的关联表(这个表也可以是分库分表的)来进行用户订单的辅助查询。
其他
另外,需要注意的是,随着时间的流逝,我们可能没有必要把所有数据都存到mysql里,毕竟它不是分析型的数据库,我们可以根据时间,把老的数据放到一些其他适合查询场景的库里,比如淘宝使用的是X-Engine引擎的PolarDB-X集群(虽然我也没研究这是个啥呢)。
以上
不过实际上我也没见过这么多数据,我好没经验,有经验的大佬希望可以评论里分享下实际业务里都咋分,谢谢。
参考
轻松理解分库分表,大佬把分库分表讲解得通俗易懂
终于有大佬把分库分表的最佳实践讲清楚了
订单表的分库分表方案设计(大数据)
淘宝万亿级交易订单背后的存储引擎
我说MySQL每张表最好不超过2000万数据,面试官让我回去等通知?