分库分表

Posted roadlandscape

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分库分表相关的知识,希望对你有一定的参考价值。

分库分表的方式:分库分表包括分库和分表两个部分,通常包括:垂直分库、水平分库、垂直分表、水平分表四种方式。

  垂直分表:

    垂直分表定义:将一个表按照字段分成多表,每个表存储其中一部分字段。

    一般来说,某业务实体中的各个数据项的访问频次是不一样的,部分数据项可能是占用存储空间比较大的BLOB或是TEXT。当表数据量很大时,可以将表按字段切开,将热门字段、冷门字段分开放置在不同库中,这些库可以放在不同的存储设备上,避免IO争抢。垂直切分带来的性能提升主要集中在热门数据的操作效率上,而且磁盘争用情况减少。
    通常我们按以下原则进行垂直拆分:
      1. 把不常用的字段单独放在一张表;
      2. 把text,blob等大字段拆分出来放在附表中;
      3. 经常组合查询的列放在一张表中;

  垂直分库:

    通过垂直分表性能得到了一定程度的提升,但是还没有达到要求,并且磁盘空间也快不够了,因为数据还是始终限制在一台服务器,库内垂直分表只解决了单一表数据量过大的问题,但没有将表分布到不同的服务器上,因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

    垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。
    带来的提升是:
      解决业务层面的耦合,业务清晰
      能对不同业务的数据进行分级管理、维护、监控、扩展等
      高并发场景下,垂直分库一定程度的提升 IO、数据库连接数、降低单机硬件资源的瓶颈
    垂直分库通过将表按业务分类,然后分布在不同数据库,并且可以将这些数据库部署在不同服务器上,从而达到多个服务器共同分摊压力的效果,但是依然没有解决单表数据量过大的问题。

  水平分库:

    经过垂直分库后,数据库性能问题得到一定程度的解决,但是随着业务量的增长,数据量越来越大,库的访问非常频繁的资源,单台服务器已经无法支撑。此时该如何
优化?再次分库?如果从业务角度分析,目前情况已经无法再次垂直分库呢。
    尝试水平分库,例如将表的ID为单数的和表的ID为双数的数据分别放在两个库中,要操作某条数据,先分析这条数据所属的ID,根据ID访问不同的库。

    水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。
    带来的提升是:
      解决了单库大数据,高并发的性能瓶颈。
      提高了系统的稳定性及可用性。
    当一个应用难以再细粒度的垂直切分,或切分后数据量行数巨大,存在单库读写、存储性能瓶颈,这时候就需要进行水平分库了,经过水平切分的优化,往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据库,需要额外进行数据操作的路由工作,因此大大提升了系统复杂度。

  水平分表:

    进行水平拆分表,其目的也是为解决单表数据量大的问题。
    水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。

    带来的提升是:
      优化单一表数据量过大而产生的性能问题
      避免 IO争抢并减少锁表的几率
    库内的水平分表,解决了单一表数据量过大的问题,分出来的小表中只包含一部分数据,从而使得单个表的数据量变小,提高检索性能。

  一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案,在数据量及访问压力不是特别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表方案。

分库分表带来的问题:分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力,突破网络 IO、硬件资源、连接数的瓶颈,同时也带来了一些问题。

  1.事务一致性问题

    由于分库分表把数据分布在不同库甚至不同服务器,不可避免会带来分布式事务问题。

  2.跨节点关联查询

    垂直分库后当需要关联查询的表不在同一个数据库,甚至不在一台服务器,将无法进行关联查询

    可将原关联查询分为两次查询,第一次查询的结果集中找出关联数据id,然后根据id发起第二次请求得到关联数据,最后将获得到的数据进行拼装。
  3.跨节点分页、排序函数

    跨节点多库进行查询时,limit分页、order by排序等问题,就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序。
    如,进行水平分库后的商品库,按ID倒序排序分页,取第一页,可以将每个节点第一页数据返回,汇总后整体排序,取需要的数据。

    以上流程是取第一页的数据,性能影响不大,但由于商品信息的分布在各数据库的数据可能是随机的,如果是取第N页,需要将所有节点前N页数据都取出来合并,再进行整体的排序,操作效率可想而知。所以请求页数越大,系统的性能也会越差。
    在使用Max、Min、Sum、Count之类的函数进行计算的时候,与排序分页同理,也需要先在每个分片上执行相应的函数,然后将各个分片的结果集进行汇总和再次计算,最终将结果返回。

  4.主键避重

    在分库分表环境中,由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地,某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键,以避免跨库主键重复问题。

  5.公共表

    实际的应用场景中,参数表、数据字典表等都是数据量较小,变动少,而且属于高频联合查询的依赖表。
    可以将这类表在每个数据库都保存一份,所有对公共表的更新操作都同时发送到所有分库执行。

以上是关于分库分表的主要内容,如果未能解决你的问题,请参考以下文章

分库分表 ---SpringBoot + ShardingSphere 实现分表

.netcore分库分表的问题

分库分表--- SpringBoot+ShardingSphere实现分表+ 读写分离

分库分表最佳实践

[精选]彻底搞清分库分表(垂直分库,垂直分表,水平分库,水平分表)

分库分表 ---SpringBoot + ShardingSphere 实现分表