赞
踩
但是想要使用的得心应手,首先应该搞清楚三个问题?
答案很简单:当数据库出现性能瓶颈。顾名思义就是数据库扛不住了。
数据库出现瓶颈,对外表现有以下几个方面?
SQL
操作变慢(慢SQL
增多)如果数据库中存在一张上亿数据量的表,一条 SQL 没有命中索引会全表扫描,这个查询耗时会非常久。从机器角度,性能瓶颈不外乎就是CPU
、磁盘、内存、网络这些,要解决性能瓶颈最简单粗暴的方式就是提升机器性能,但是通过这种方式投入产出比往往不高,也不划算,所以重点还是要从软件层面去解决问题。
数据库相关优化方案
数据库优化方案很多,主要分为两大类:软件层面、硬件层面。
软件层面包括:SQL 调优、表结构优化、读写分离、数据库集群、分库分表等;
硬件层面主要是增加机器性能。
分库分表其实不是数据库优化方案的最终解决办法,一般来说说能用优化SQL、表结构优化、读写分离等手段解决问题,就不要分库分表,因为分库分表会带来更多需要解决的问题,比如说分布式事务,查询难度增大等。
什么时候我们才会选择分库分表?前面已经说了,除了分库分表以外那些软件手段搞不定的时候,我们才会选择分库分表。
我们心中可能会有这些疑问?
阿里巴巴开发手册有推荐的思路:单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。
注意:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。
当前针对分库分表有很多解决方案。这里分两个方面来展开说说:分库 和 分表。
很多项目前期为了快速迭代,多个应用公用一套数据库,随着业务量增加,系统访问压力增大,系统拆分就势在必行。
为了保证业务平滑,系统架构重构也是分了几个阶段进行。
多应用单数据库
第一个阶段将商城系统单体架构按照功能模块拆分为子服务,比如:Portal 服务、用户服务、订单服务、库存服务等。
多应用单数据库如上图,多个服务共享一个数据库,这样做的目的是底层数据库访问逻辑可以不用动,将影响降到最低。
多应用多数据库
随着业务推广力度加大,数据库终于成为了瓶颈,这个时候多个服务共享一个数据库基本不可行了。我们需要将每个服务相关的表拆出来单独建立一个数据库,这其实就是“分库”了。
单数据库的能够支撑的并发量是有限的,拆成多个库可以使服务间不用竞争,提升服务的性能。
从一个大的数据中分出多个小的数据库,每个服务都对应一个数据库,这就是系统发展到一定阶段必要要做的“分库”操作。
说完了分库,那什么时候才会分表呢?
如果系统处于高速发展阶段,拿商城系统来说,一天下单量可能几十万,那数据库中的订单表增长就特别快,增长到一定阶段数据库查询效率就会出现明显下降。
因此当表数据增长过快,根据阿里巴巴开发规范中超过500w的数据就要考虑分表了,当然这只是一个经验值,具体要不要分表还要看业务考虑未来三年的一个业务增量。
如何分表?
分表有几个维度,一是水平切分和垂直切分,二是单库内分表和多库内分表。
水平拆分和垂直拆分
拿商品表来说,表中分为几类属性:一类是基础属性,例如:商品名称、通用名,商品编码等信息。二类是规格属性:尺寸、型号等信息。三类是拓展属性:描述商品特征的一些属性。我们可以将其拆分为基础信息表、拓展属性表、属性信息表等。这几张表结构不同并且相互独立。但是从这个角度没有解决因为数据量过大而带来的性能问题,因此我们还需要继续做水平拆分。
水平拆分表的方法很多种,比如说1w条数据,我们拆分为两个表,id 为基数的放在user1
,id为偶数的放在user2
中,这样的拆分方式就是水平拆分。
其他水平拆分的方式也很多,除了上面按照 id
来拆分,还可以按照时间维度拆分,比如订单表,可以按照每日、每月等进行拆分。
总结一下水平拆分和垂直拆分的特点:
水平拆分也分两种拆分方式。单库内拆分和多库内拆分
单库内拆分和多库内拆分
拿针对用户表的拆分来举例,之前的单个用户表按照某种规则拆分为多个子表,多个子表存在于同一数据库中。比如下面用户表拆分为用户1表、用户2表。
单库内拆分是在一个数据库中,将一张表拆分为多个子表,一定程度上可以解决单表查询的性能问题,但是也会遇到另外一个问题:但数据库的数据瓶颈。
所以在行业内更多的将子表拆分到多个数据库中,如下图,用户表拆分为4个子表,4个子表分两批存在两个不同的数据库中,根据一定的规则进行路由。
多库拆分用一句话概括:主要是为了减少单张表数据量大小,解决单表数据量过大带来的性能问题。
但是分库分表也带来许多问题。
既然分库分表方案那么好,那我们是不是在项目初期就应该采用这种方案呢?莫慌,虽然分库分表解决了很多性能问题,但是同时也给系统带来了很多复杂性。下面我展开说说
1. 跨库关联查询
之前单体项目,我们想查询一些数据,无脑join
就好了,只要数据模型设计没啥问题,关联查询起来其实还是很简单的。现在不一样了,分库分表后的数据可能不在一个数据库,那我们如何关联查询呢?
下面推荐几种方式去解决这个问题:
join
操作,但是关联字段更新,也会引发冗余字段的更新;ETL
等将数据汇总聚合,生成新的表;id
进行分表,订单主表、订单拓展信息表、跟订单有关联查询的表都按照用户id 进行分表,那么同一个用户的订单数据肯定在同一个数据库中,订单维度的关联查询就不存在跨库的问题了。2. 分布式事务
单数据库我们可以用本地事务搞定,使用多数据库就只能通过分布式事务解决了。
常用的解决方案有:基于可靠消息(MQ
)的最终一致性方案、二段式提交(XA
)、柔性事务。
3. 排序、分表、函数计算问题
使用SQL
时,order by
、limit
等关键字需要特殊处理,一般都是采用数据分片的思路:现在每个分片路由上执行函数、然后将每个分片路由的结果汇总再计算,然后得出最终结果。
4. 分布式ID
既然分库分表了,主键id已经不能唯一确定我们的业务数据了,随之而来的就是分布式id,顾名思义就是在多个数据库多张表中唯一确定的ID。
常见的分布式Id 解决方案有:
UUID
Redis
缓存生成全局IDSnowflake
)uid-generator
(雪花算法的变种)Leaf
(雪花算法的变种)Tinyid
这些解决方案后面有专门的文章去介绍,这里不过多展开。
5. 多数据源
分库分表之后可能面临从多个数据库中获取数据,一般的解决方案有,基于 client 适配 和 基于 proxy 适配。
比较成熟并且常用的中间件有:
如果遇到数据库问题,建议不要着急分库分表。原则是:能不分库分表就不要做。先看下能否通过常规优化手段解决问题。
如上所述,引入分库分表虽然可以解决数据库瓶颈问题,但是也给系统带来巨大的复杂性,不是非必须不要使用。设计系统我们一向要本着高可拓展去设计,但是不要过度设计和超前设计。适合当前系统的设计才是最好的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。