分库分表

标签：性问题   数据操作   定义   可用性   不可   合并   内存   order   方式   

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

　　垂直分表：

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

　　　　一般来说，某业务实体中的各个数据项的访问频次是不一样的，部分数据项可能是占用存储空间比较大的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.公共表

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

分库分表

标签：性问题   数据操作   定义   可用性   不可   合并   内存   order   方式   

原文地址：https://www.cnblogs.com/roadlandscape/p/12817880.html