数据库怎么分库分表？

数据库瓶颈

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

IO瓶颈

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

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

CPU瓶颈

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

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

分库分表

水平分库

1、概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
2、结果：

  • 每个库的结构都一样

  • 每个库中的数据不一样，没有交集

  • 所有库的数据并集是全量数据

3、场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库的情况下。
4、分析：库多了，io和cpu的压力自然可以成倍缓解

 

水平分表

1、概念：以字段为依据，按照一定策略（hash、range等），讲一个表中的数据拆分到多个表中。
2、结果：

  • 每个表的结构都一样

  • 每个表的数据不一样，没有交集，所有表的并集是全量数据。

3、场景：系统绝对并发量没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈，可以考虑水平分表。
4、分析：单表的数据量少了，单次执行SQL执行效率高了，自然减轻了CPU的负担。

垂直分库

1、概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
2、结果：

  • 每个库的结构都不一样

  • 每个库的数据也不一样，没有交集

  • 所有库的并集是全量数据

3、场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块的情况下。
4、分析：到这一步，基本上就可以服务化了。例如：随着业务的发展，一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再者，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

分库分表工具

  • sharding-jdbc（当当）

  • TSharding（蘑菇街）

  • Atlas（奇虎360）

  • Cobar（阿里巴巴）

  • MyCAT（基于Cobar）

  • Oceanus（58同城）

  • Vitess（谷歌） 各种工具的利弊自查

分库分表带来的问题

分库分表能有效缓解单机和单表带来的性能瓶颈和压力，***IO、硬件资源、连接数的瓶颈，同时也带来一些问题，下面将描述这些问题和解决思路。

事务一致性问题

分布式事务

当更新内容同时存在于不同库找那个，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用“XA协议”和“两阶段提交”处理。
分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平扩展的枷锁。

最终一致性

对于那些性能要求很高，但对一致性要求不高的系统，往往不苛求系统的实时一致性，只要在允许的时间段内达到最终一致性即可，可采用事务补偿的方式。与事务在执行中发生错误立刻回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等。

 

https://blog.csdn.net/tianmingwei/article/details/103372466

 

数据迁移、扩容问题

当业务高速发展、面临性能和存储瓶颈时，才会考虑分片设计，此时就不可避免的需要考虑历史数据的迁移问题。一般做法是先读出历史数据，然后按照指定的分片规则再将数据写入到各分片节点中。此外还需要根据当前的数据量个QPS，以及业务发展速度，进行容量规划，推算出大概需要多少分片（一般建议单个分片的单表数据量不超过1000W）

 

什么时候考虑分库分表

能不分就不分

并不是所有表都需要切分，主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。

数据量过大，正常运维影响业务访问

这里的运维是指：

  • 对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO

  • 对一个很大的表做DDL，MYSQL会锁住整个表，这个时间会很长，这段时间业务不能访问此表，影响很大。

  • 大表经常访问和更新，就更有可能出现锁等待。

随着业务发展，需要对某些字段垂直拆分

这里就不举例了。在实际业务中都可能会碰到，有些不经常访问或者更新频率低的字段应该从大表中分离出去。

数据量快速增长

随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。

 

参考链接