mysql多字段分库分表基因码_分布式存储--Mysql--序列1--分库分表策略

分库分表是存储层设计中一个广泛而重大的问题,何时分?怎么分?分完以后引起的新问题,好比不能Join、分布式事务? 本篇将从最基本的策略出发,逐步深刻讲解这里面涉及的一序列策略。mysql

分库-业务分拆 & 数据隔离

分库的首先目的就是作“业务分拆“,关于业务分拆,在前面的序列文章“分布式系统--基本思想汇总“中已经有阐述。经过业务分拆,把一个大的复杂系统拆成多个业务子系统,之间经过RPC或消息中间件通讯。这样作既便于团队成员的职责分工,也便于对将来某个系统作扩展。sql

另一个考虑角度是“数据隔离”。若是你把核心业务的数据和非核心业务数据放在一个库里面,不分轻重,同等对待。这样若是由于非核心业务把DB搞挂了,核心业务也受到牵连。分开以后,区别对待,投入的开发和运维人力也不同。缓存

读多写少 vs. 读少写多

对于业务来说,读多写少/读少写多,所对应的策略是不同的。app

若是是读多写少,那你能够经过加从库、加缓存来解决,不必定要分库分表。运维

若是是读少写多,或者说写入的QPS已经达到了DB的瓶颈,这个时候就得考虑分库分表了。异步

对于Mysql来说,通常写入的QPS有3k/s左右,读写的QPS能够达到2万/s。可见写入和查询的吞吐量区别是很大的。分布式

分表/分库

考虑了上面2个策略以后,最后万不得已,再作分库分表。由于分库分表的代价是很大的,意味着代码要大规模重构,之前能用的join,事务可能都不能用了,须要用新的办法解决。优化

垂直切分

垂直切分通常主要用于表的字段太多(好比上百个字段),这种情形一般就对应着上层业务没有很好的分拆,解耦。若是作好了上面的“业务分拆”,须要这种“垂直切分”的场景可能就会变得不多。下面主要讲“水平切分”。搜索引擎

水平切分

当表的记录数太多,几千万,上亿,而且有很高的写入QPS,这个时候就得考虑水平切分了。设计

通常思路是:保证单表的记录条数不要超过千万,而后根据总数据量估算出要拆多少个表,再考虑把这些表分散到多少个库里面。

水平切分的最关键问题就是:拆分维度的选择。

拆分维度(字段)的选择

好比电商的订单表,至少有3个查询维度:订单id,用户id,商户id。那你拆分的时候,根据哪一个维度进行拆分呢?

假设你按用户id拆分,同一个用户的全部订单记录都落到同1个库的同1张表里面。那查询的时候,按user id查,就很容易;

但若是按订单id,或者商户id呢?拆分以后,同1个商户id的订单,可能被分到了不一样的库、不一样的表里面,根本没办法查。

对于这种分库分表以后,其余维度的查询,通常有如下几个办法:

(1)创建一个映射表,创建辅助维度和主维度之间的映射关系(也就是商户id和用户id之间的映射关系)。

查询的时候,根据商户id,查出用户id。再根据用户id,来查

(2)业务双写

同1份数据,2套分库分表。1套按user id切分,1套按商户id 切分。这个其实也就是我在”分布式系统--基本思想汇总“中所用的“重写轻读”

(3)异步双写

仍是2套表,只是业务单写。而后经过binlog同步(好比阿里的canal,点评的puma),同步到另一套表上。

(4)2个维度统一到1个维度

这个在特殊的场景下可使用。好比order id和user id就能够统一成1个维度,把user id做为order id中的某几位,这样order id中就包含了user id信息。

而后按照user id 分库,当按照order id查询的时候,截取出user id,在按user id查询。但反过来就不行,按order id分库了,再按user id就不能查了。

Join问题

分库分表以后,有些Join就不能用了,针对这种状况,通常有下面几种解决办法:

(1)把Join拆成多个单表查询,上层业务代码进行结果拼装

(2)提早作宽边,重写轻读

不少时候,你有这样的状况:须要把Join的结果分页,这个须要利用mysql自己的分页功能。对于这种不得不用Join的状况,能够另外作一个Join表,提早把结果Join好。这是“重读轻写”,其实也是“空间换时间”的思路。

(3)利用搜索引擎

对于(2)当中提到的场景,还能够利用Lucence,ES这种搜索引擎,把DB中数据导入到搜索引擎中来查询,从而解决Join问题。

分布式事务

作了分库以后,纯DB的事务就搞不了了。通常解决办法都是:经过精心选择维度,优化业务,避免跨库的事务,保证全部事务都落到单库上面。

若是实在没法避免,那就须要分布式事务的解决方案了。关于分布式事务,又是一个系统化的课题,没有一个标准答案。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值