分库分表那些事

一、什么时候选择分库分表？

     阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

      何时进行分库分表，与有多少条数据无关，要结合实际情况，数据库的硬件性能等也会影响数据库何时进行分库分表，观察实际场景，当发现数据库的慢查询变多，达到数据库瓶颈，就代表可以进行分库分表了。

       单表行数过大或者单表/单实例 访问量过大可能遇到的瓶颈如下： 

1.1、单表行数过大（亿级），面临的问题：

        * DDL变更耗时长（意味着 gh-ost 程序要更久的使用部分数据库资源(IO/CPU/MEM)）
        * DDL变更生成的 gh-ost 临时表，占用空间大，磁盘容量吃紧
        * 日常查询变慢（索引要扫描过滤的数据量增加）
        * 统计信息采样比例变小，可能会影响执行计划准确性，导致查询变慢
        * 备份恢复、故障后实例重建时间长

1.2、单表/单实例 访问量过大，面临的问题： 

        * CPU/MEM/IO等物理资源无法应对业务请求 

     不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1.2.1、IO瓶颈

第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。

第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。

1.2.2、CPU瓶颈

第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 ->，建立合适的索引，在业务Service层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，增加CPU运算的操作 -> 水平分表。

二、数据拆分的方式

数据拆分有两种方式：

垂直拆分： 根据业务的维度，将原本一个库中的表拆分多个表，每个库中表与原有的结构不同

水平拆分： 根据分片算法，将一个库拆分成多个库，每个库依旧保留原有的结构

在实际的开发过程中，通常是先进行维度拆分形成微服务结构，然后再进行水平拆分

三、分库分表引起的问题

      进行了分库分表以后，如果查询的标准是分片的主键，则可以通过分片规则再次路由并查询，但是对于其他主键的查询、范围查询、关联查询、查询结果排序等，并不是按照分库分表维度查询的；

这样的话，解决方案有以下三种：

1）在多个分片表中查询后合并数据集，这种方式的效率最低

2）冗余记录多份数据，方便查询， 缺点是需要额外维护一份数据，浪费资源

3）通过搜索引擎解决，但如果实时性要求很高，就需要实现实时搜索，可以利用大数据相关特性来解决

四、主流分库分表解决方案

ShardingJDBC、My cat

五、数据迁移的方式

     在分库分表中，如果涉及的分片已经达到了承载数据的最大值，就需要对集群进行扩容，通常包括以下的步骤

• 按照新旧分片规则，对新旧数据库进行双写
• 将双写前按照旧分片规则写入的历史数据，根据新分片规则迁移写入新的数据库
• 将按照旧的分片规则查询改为按照新的分片规则查询
• 将双写数据库逻辑从代码中下线，只按照新的分片规则写入数据
• 删除按照旧分片规则写入的历史数据

六、常见的分片策略

按照哈希切片

       对数据库的某个字段进行来求哈希，再除以分片总数后取模，取模后相同的数据为一个分片，这样将数据分成多个分片的方法叫做哈希分片。我们大多数在数据没有时效性的情况下使用哈希分片，就是数据不管是什么时候产生的，系统都需要处理或者查询；优点是数据切片比较均匀，数据压力分散的效果好。缺点是数据分散后，对于查询需求需要进行聚合处理。

按照时间切片

        按照时间的范围将数据分布到不同的分片上，比如我们可以将交易数据按照与进行切片，或者按照季度进行切片，由交易数据的多少来决定按照什么样的时间周期来进行切片

这种切片方式适合明显时间特点的数据，常见的就是订单历史查询

还可以按照业务主键来分片。