分库分表的基基基础知识

一、导论

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

5、跨库多表 join 问题

大厂 DBA 的建议是，线上服务尽可能不要有表的 join 操作

6、跨库聚合查询问题

分库分表会导致常规聚合查询操作，如 group by，order by 等变的异常复杂。

7、数据迁移、扩容问题

这里需要专门再学习…