分库在数据量较大的项目中使用得很多,每个人都有各自的经验和心得。但要系统的说清楚分库是怎么回事,有哪些注意事项及问题,感觉不是那么容易。本文主要摘录了mycat中间件帮助文档的部分内容,说一下分库的相关概念。
一、何为数据切分
简单来说,就是指通过某种特定的条件,将存放在同一个数据库中的数据分散存放到多个数据库(主机)上,以达到分散单台设备负载的效果。
数据的切分(Sharding)根据其切分规则的类型,分为两种切分模式。一种是按照不同的表(或者 Schema)来切分到不同的数据库(主机)之上,这种切可以称之为数据的垂直(纵向)切分;另外一种则是根据表中的数据的逻辑关系,将同一个表中的数据按照某种条件拆分到多台数据库(主机)上面,这种切分称之为数据的水平(横向)切分。
垂直切分的最大特点就是规则简单,实施也更为方便,尤其适合各业务之间的耦合度非常低,相互影响很小,业务逻辑非常清晰的系统。在这种系统中,可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分,对应用程序的影响也更小,拆分规则也会比较简单清晰。
按照业务把数据库拆开就已经属于分库了
水平切分于垂直切分相比,相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中,对于应用程序来说,拆分规则本身就较根据表名来拆分更为复杂,后期的数据维护也会更为复杂一些。
水平切分估计才是大家心目中的分库吧
二、垂直切分
一个数据库由很多表的构成,每个表对应着不同的业务,垂直切分是指按照业务将表进行分类,分布到不同的数据库上面,这样也就将数据或者说压力分担到不同的库上面,如下图:
系统被切分成了,用户、订单交易、支付几个模块。
大家好像都是这么做的
架构设计较好的应用系统,总体功能是由很多个功能模块所组成,而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好。这样的系统,实现数据的垂直切分也就越容易。
这点就是指的高内聚、低耦合吧
但是往往系统之有些表难以做到完全的独立,存在这扩库 join 的情况,对于这类的表,就需要去做平衡,是数据库让步业务,共用一个数据源,还是分成多个库,业务之间通过接口来做调用。在系统初期,数据量比较少,或者资源有限的情况下,会选择共用数据源,但是当数据发展到了一定的规模,负载很大的情况,就需要必须去做分割。
这就是程序员总觉的前任给自己挖坑的原因
一般来讲业务存在着复杂 join 的场景是难以切分的,往往业务独立的易于切分。如何切分,切分到何种程度是考验技术架构的一个难题。
说实话,我业务做得少,看这篇文章之前根本没想到过跨库join的问题
垂直切分的优缺点:
优点:
缺点:
支付等强事务的业务,垂直切分会不会很麻烦
三、水平切分
相对于垂直拆分,水平拆分不是将表做分类,而是按照某个字段的某种规则来分散到多个库之中,每个表中包含一部分数据。简单来说,可以将数据的水平切分理解为是按照数据行的切分,就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其他的数据库中,如图:
拆分数据就需要定义分片规则。关系型数据库是行列的二维模型,拆分的第一原则是找到拆分维度。比如:从会员的角度来分析,商户订单交易类系统中查询会员某天某月某个订单,那么就需要按照会员结合日期来拆分,不同的数据按照会员 ID 做分组,这样所有的数据查询 join 都会在单库内解决;如果从商户的角度来讲,要查询某个商家某天所有的订单数,就需要按照商户 ID 做拆分;但是如果系统既想按会员拆分,又想按商家数据,则会有一定的困难。如何找到合适的分片规则需要综合考虑衡量。
这个点能够很好体现程序员的水平,微信搜“架构师之路”,这个公众号上有好几篇介绍这方面技巧的文章。
几种典型的分片规则包括:
如图,切分原则都是根据业务找到适合的切分规则分散到不同的库,下面用用户 ID 求模举例:
既然数据做了拆分有优点也就优缺点。
优点:
缺点:
四、数据切分共同缺点
前面讲了垂直切分跟水平切分的不同跟优缺点,会发现每种切分方式都有缺点,但共同的特点缺点有:
看来自己做的项目业务上确实太简单,这么多缺点,真正遇到的并不多。找做支付的同学聊了聊,分库缺点条条命中!这些问题怎么解决呢?