一、为什么要进行分库分表
当MySQL单表数据量过大,比如超过5千万条的时候,读写性能变得很差。而且常规的优化手段已经不起作用了,比如:SQL调优、添加索引、主从复制、读写分离。这时候就需要用到MySQL终极优化方案 — 分库分表。
二、怎么判断项目是需要分库还是要分表?是先分库还是先分表
-
当数据库的QPS过高,数据库连接数不足的时候,就需要分库。(比如一个库的连接数支持2K,分成两个库就能支持4K)
-
微服务架构中,为了业务隔离,一般也做分库处理。
-
当单表数据量过大,读写性能较差,就需要分表。
-
当两者都有的时候,就需要分库分表。
至于先分库还是先分表?建议先分表,如果分表能解决问题,就不需要分库了,毕竟需要单独服务器资源,成本更高。
三、分库分表有哪些拆分方案
分库分表有垂直拆分和水平拆分,垂直拆分又有垂直分库、垂直分表。
-
垂直分库:不同的业务拆分到不同的数据库(比如微服务分库)。
-
水平分库:单张表QPS过高,把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。(解决了单库大数据,高并发的性能瓶颈)
-
垂直分表:把长度较大或者访问频次较低的字段,拆分到扩展表中。
-
水平分表:单表数据量过大时,按照订单ID拆分到多张表中。
垂直分库
垂直分表
四、分库分表的缺点及解决方案
4.1 缺点
-
垂直分库: 不同库多表之间无法join关联查询,只能通过接口聚合(MySQL有另外一种方式:MySQL跨库查询),复杂度直线上升。 横跨多个数据库导致无法使用本地事务,数据强一致性就别想了,只能引入更为复杂的分布式事务,勉强实现数据的最终一致性,可用性直线下降。
-
垂直分表: 本来一张表能查出来的数据,现在需要多张表join关联查询,增加复杂度。
-
水平分表: 多张表关联查询时,无法实现分页、排序功能。
4.2 解决方案
1、跨库查询问题:
采用字段冗余方案,比如订单表存储店铺ID、店铺名称,就不需要再查询商户数据库了。 不过这种方案要求冗余字段要很少变动,就算变动后,也能容忍返回旧数据。
2、多表分页查询问题:
这个处理起来就很需要技术含量了,比如:订单表按照订单ID分片,(order_id % 128),分成了128张表。同一个用户的订单散落在不同的表,用户想查询自己的订单,根本无法做到分页查询。难道一次全部查询该用户的所有订单,然后做内存分页,多大的机器内存都让你搞挂。
想要实现用户订单分页查询,可以采用按照用户ID分片,(user_id % 128),这样同一个用户的订单只会存储在一张表中,咋分页展示都行。
4.2.1 如果商户想要分页查看自己店铺的订单怎么办?
那就把订单再冗余存储一份,按照店铺ID分片,(shop_id % 128)。不过由于商户数量较少,可以搞个异步线程往商户订单分片表同步。
4.2.2 订单按照用户ID分片后,发生数据倾斜怎么办?
因为不同用户的订单量是不同的,一个爱好购物的小姐姐的订单量抵得上几十个老爷们,导致一张表数据几百条,另一张表数据量千万级,这该咋整?做冷热数据分离,基础库只存储3个月内的订单,其他的移动到历史订单库。这个要跟产品商量好,3个月前的订单需要单独的查询页面。
五、跨库事务问题
跨库事务问题
下一个订单需要调用多个服务,只能使用分布式事务。 分布式事务的实现非常复杂,常用的有以下几种解决方案:
-
二阶段提交
-
TCC
-
本地消息表
-
MQ事务消息
-
分布式事务中间件
原文地址:https://www.jianshu.com/p/919a8f9f0282
标签:方案,分库,查询,垂直,订单,分表,ID From: https://www.cnblogs.com/songjuntao/p/17065159.html