文章目录
一、导论
1、问题的产生
随着规模的增大,数据库可能会遇到的问题?
- 读压力:并发 QPS、索引不合理、SQL 语句不合理、锁粒度
- 写压力:并发 QPS、事务、锁粒度
- 物理性能:磁盘瓶颈、CPU 瓶颈、内存瓶颈、IO 瓶颈
- 其他:宕机、网络异常
面对上述问题,常见的优化手段有:索引优化、主从同步、缓存、分库分表
-
单机的存储能力、连接数是有限的,自身就很容易会成为系统的瓶颈。
-
当单表数据量在百万以内时,可以通过添加从库、优化索引提升性能。
-
如果数据量朝着千万级以上趋势增长,或者突破千万级,那么即使再怎么优化单个数据库实例,很多数据操作的性能仍严重下降。这时候,为了减少数据库的负担,提升数据库响应速度,缩短查询时间,就需要进行分库分表。
2、什么是分库分表?
- 分表:将一个表中的数据按照某种规则分拆到多张表中,降低锁粒度以及索引树,提升数据查询效率。
- 分库:将一个数据库中的数据按照某种规则分拆到多个数据库中,以缓解单服务器的压力(CPU、内存、磁盘、IO)。
3、为什么分库分表?
- 性能角度:CPU、内存、磁盘、IO 瓶颈
- 随着业务体量扩大,数据规模达到百万行,数据库索引树庞大,查询性能出现瓶颈。
- 用户并发流量规模扩大,由于单库(单服务器)物理性能限制也无法承载大流量。
- 可用性角度:单机故障率影响面
- 如果是单库,数据库宕机会导致100%服务不可用,N 库则可以将影响面降低N倍。
二、如何分库分表?
-
分库分表,就是要将大量数据分散到多个数据库的多个表中,使每个数据库中数据量小,响应速度快,以此来提升数据库整体性能。
-
核心理念就是对数据进行切分(
Sharding
),以及切分后如何对数据快速定位与整合。 -
针对数据切分类型,可以分为:垂直(纵向)切分和水平(横向)切分两种。
1、垂直切分
垂直拆分就是对数据内容进行拆分,将一条记录拆分到多个表或是将多个业务信息拆分到多个库中。垂直拆分的原则一般按照业务类型来拆分,核心思想是专库专用,将业务耦合度比较高的表拆分到单独的库中
-
垂直分库:垂直分库是基于业务划分数据库。与微服务治理观念很相似,每个独立的服务都拥有自己的数据库,通过接口调用获取不同业务的数据。
-
垂直分表:垂直分表是基于数据表的列进行切分,是一种大表拆小表的模式。
数据库是以行为单位将数据加载到内存中,这样拆分以后,核心表大多是访问频率较高的字段,而且字段长度也都较短,可以加载更多数据到内存中,增加查询的命中率,减少磁盘IO,以此来提升数据库性能。
优点:
- 业务间解耦,不同业务的数据进行独立的维护、监控、扩展。
- 在高并发场景下,一定程度上缓解了数据库的压力。
缺点:
- 提升了开发的复杂度,由于业务的隔离性,很多表无法直接访问,必须通过接口方式聚合数据。
- 分布式事务管理难度增加。
- 垂直切分数据库还是存在单表数据量过大的问题,并未根本上解决,需要配合水平切分。
2、水平切分
将一张大数据量的表,切分成多个表结构相同的小表,而每个小表只占原表一部分数据,然后按不同的条件分散到单个或多个数据库中。
- 库内分表:虽然将表拆分,但是子表都还在同一个数据库实例中,只解决了单一表数据量过大的问题,并没有将拆分后的子表分布到不同机器的库上,还在竞争同一个物理机的CPU、内存、网络IO。
- 分库分表:将切分出的子表,分散到不同的数据库中,从而使得单个表的数据量变小,达到分布式的效果。
优点:
- 解决高并发时单库数据量过大的问题,提升系统稳定性和负载能力。
- 业务系统改造的工作量不是很大。
缺点:
- 跨分片的事务一致性难以保证。
- 跨库的 join 关联查询性能较差。
- 扩容的难度和维护量较大。
三、产生的问题及解决方式
1、数据该存到哪个库的哪张表?
-
Range 区间:对于水平切分,根据时间区间或者是 ID 范围来确定访问哪一个库哪一个表
- 优点:
- 单表数据量是可控的。
- 水平扩展简单,只需增加节点即可,无需对其他分片的数据进行迁移。
- 能快速定位要查询的数据在哪个库。
- 缺点:
- 由于连续分片,可能存在数据热点问题。假如按时间字段分片,有些分片存储最近时间段内的数据,可能会被频繁的读写;而有些分片存储历史数据,则很少被查询。
- 优点:
-
Hash 取模:Hash 取模(对hash结果取余数 (hash() mod N))的切分方式比较常见。
-
优点:
- 数据分片相对比较均匀,不易出现某个库并发访问的问题。
-
缺点:
- 当某一台机器宕机,本应该落在该数据库的请求就无法得到正确的处理。这时,宕掉的实例会被踢出集群,算法变成hash(userId) mod N-1,用户信息可能就不再在同一个库中。
-
2、事务一致性问题
- 由于数据表分布在不同库中,不可避免会带来跨库事务问题。一般可使用"XA协议"和"两阶段提交"处理,但是这种方式性能较差,代码开发量也比较大。
- 通常是做到最终一致性即可,不苛求系统的实时一致性;只要求在允许的时间段内达到最终一致性,可采用事务补偿的方式。
3、分页、排序的坑
使用多库进行查询时,limit分页、order by 排序着实让人比较头疼。
4、全局唯一主键问题
- 分库分表后,表中的数据同时存在于多个数据库,某个分区数据库的自增主键无法满足全局唯一。
- 一个能够生成全局唯一 ID 的系统是非常必要的。
- 全局唯一 ID 的实现方案有如下几个:
- UUID:最方便快捷的方式。比较长的字符串,连续性差,如果作为主键使用,性能相对来说会比较差。
- 雪花算法
- 高并发分布式环境下生成不重复 ID,每秒可生成百万个不重复 ID。
- 基于时间戳,以及同一时间戳下序列号自增,基本保证 id 有序递增。
- 不依赖第三方库或者中间件。
- 算法简单,在内存中进行,效率高。
- 缺点:依赖服务器时间,服务器时钟回拨时可能会生成重复 ID。但可通过记录最后一个生成 ID 的时间戳来解决,每次生成 ID 之前比较当前服务器时钟是否被回拨,避免生成重复 ID。
- 号段模式
- Redis/Zookeeper:分布式 ID
- 全局唯一 ID 的实现方案有如下几个:
5、跨库多表 join 问题
大厂 DBA 的建议是,线上服务尽可能不要有表的 join 操作
6、跨库聚合查询问题
分库分表会导致常规聚合查询操作,如 group by,order by 等变的异常复杂。
7、数据迁移、扩容问题
这里需要专门再学习…