分库分表(1) --- 理论

分库分表---理论

当一张表的数据达到几千万时，查询一次所花的时间会变长。业界公认MySQL单表容量在 1千万 如下是最佳状态，由于这时它的BTREE索引树高在3~5之间。

数据切分能够分为：垂直切分和水平切分。

1、垂直切分

垂直切分又能够分为: 垂直分库和垂直分表。

一、垂直分库

概念 就是根据业务耦合性，将关联度低的不一样表存储在不一样的数据库。作法与大系统拆分为多个小系统相似，按业务分类进行独立划分。与"微服务治理"的作法类似，

每一个微服务使用单独的一个数据库。

如图：

说明

一开始咱们是单体服务，因此只有一个数据库，全部的表都在这个库里。

后来由于业务需求,单体服务变成微服务治理。因此将以前的一个商品库，拆分红多个数据库。每一个微服务对于一个数据库。

二、垂直分表

概念 把一个表的多个字段分别拆成多个表，通常按字段的冷热拆分，热字段一个表，冷字段一个表。从而提高了数据库性能。

如图：

说明

一开始商品表中包含商品的全部字段，可是咱们发现:

1.商品详情和商品属性字段较长。2.商品列表的时候咱们是不须要显示商品详情和商品属性信息，只有在点进商品商品的时候才会展现商品详情信息。

因此能够考虑把商品详情和商品属性单独切分一张表，提升查询效率。

三、垂直切分优缺点

优势

- 解决业务系统层面的耦合，业务清晰
- 与微服务的治理相似，也能对不一样业务的数据进行分级管理、维护、监控、扩展等
- 高并发场景下，垂直切分必定程度的提高IO、数据库链接数、单机硬件资源的瓶颈

缺点

- 分库后没法Join，只能经过接口聚合方式解决，提高了开发的复杂度
- 分库后分布式事务处理复杂
- 依然存在单表数据量过大的问题（须要水平切分）

2、水平切分

当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大,存在单库读写、存储性能瓶颈，这时候就须要进行水平切分了。

水平切分也能够分为：水平分库和水平分表。

一、水平分库

水平分库的缘由

上面虽然已经把商品库分红3个库，可是随着业务的增长一个订单库也出现QPS太高，数据库响应速度来不及,通常mysql单机也就1000左右的QPS，若是超过1000就要考虑分库。

如图

二、水平分表

概念 通常咱们一张表的数据不要超过1千万,若是表数据超过1千万，而且还在不断增长数据，那就能够考虑分表。

如图

三、垂直切分优缺点

优势

- 不存在单库数据量过大、高并发的性能瓶颈，提高系统稳定性和负载能力
- 应用端改造较小，不须要拆分业务模块

缺点

- 跨分片的事务一致性难以保证
- 跨库的Join关联查询性能较差
- 数据屡次扩展难度和维护量极大

3、数据分片规则

咱们咱们考虑去水平切分表，将一张表水平切分红多张表，这就涉及到数据分片的规则，比较常见的有：Hash取模分表、数值Range分表、一致性Hash算法分表。

一、Hash取模分表

概念 通常采用Hash取模的切分方式，例如：假设按goods_id分4张表。（goods_id%4 取整肯定表）

优势

- 数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈。

缺点

- 后期分片集群扩容时，须要迁移旧的数据很难。
- 容易面临跨分片查询的复杂问题。好比上例中，若是频繁用到的查询条件中不带goods_id时,将会致使没法定位数据库,从而须要同时向4个库发起查询，
再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。

二、数值Range分表

概念 按照时间区间或ID区间来切分。例如：将goods_id为1~1000的记录分到第一个表，1001~2000的分到第二个表，以此类推。

如图

优势

- 单表大小可控
- 自然便于水平扩展，后期若是想对整个分片集群扩容时，只须要添加节点便可，无需对其余分片的数据进行迁移
- 使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。

缺点

- 热点数据成为性能瓶颈。
例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则不多被查询

三、一致性Hash算法

一致性Hash算法能很好的解决由于Hash取模而产生的分片集群扩容时，须要迁移旧的数据的难题。至于具体原理这里就不详细说，

能够参考一篇博客：一致性哈希算法(分库分表，负载均衡等)

4、分库分表带来的问题

任何事情都有两面性，分库分表也不例外，若是采用分库分表，会引入新的的问题

一、分布式事务问题

使用分布式事务中间件解决，具体是经过最终一致性仍是强一致性分布式事务，看业务需求，这里就很少说。

二、跨节点关联查询 Join 问题

切分以前，咱们能够经过Join来完成。而切分以后，数据可能分布在不一样的节点上，此时Join带来的问题就比较麻烦了，考虑到性能，尽可能避免使用Join查询。

解决这个问题的一些方法：

全局表

全局表，也可看作是 "数据字典表"，就是系统中全部模块均可能依赖的一些表，为了不跨库Join查询，能够将 这类表在每一个数据库中都保存一份。这些数据一般

不多会进行修改，因此也不担忧一致性的问题。

字段冗余

利用空间换时间，为了性能而避免join查询。例：订单表保存userId时候,也将userName冗余保存一份，这样查询订单详情时就不须要再去查询"买家user表"了。

数据组装

在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，而后根据id发起第二次请求获得关联数据。最后将得到到的数据进行字段拼装。

三、跨节点分页、排序、函数问题

跨节点多库进行查询时，会出现Limit分页、Order by排序等问题。分页须要按照指定字段进行排序，当排序字段就是分片字段时，经过分片规则就比较容易定位到指定的分片；

当排序字段非分片字段时，就变得比较复杂了。须要先在不一样的分片节点中将数据进行排序并返回，而后将不一样分片返回的结果集进行汇总和再次排序，最终返回给用户。

四、全局主键避重问题

若是都用主键自增确定不合理，若是用UUID那么没法作到根据主键排序，因此咱们能够考虑经过雪花ID来做为数据库的主键，

有关雪花ID能够参考我以前写的博客：静态内部类单例模式实现雪花算法

五、数据迁移问题

采用双写的方式，修改代码，全部涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，

边写边按时间比较数据是否是最新的。

参考

一、分库分表

二、谈谈分库分表吧？

三、数据库分库分表思路

我相信，不管从此的道路多么坎坷，只要抓住今天，早晚会在奋斗中尝到人生的甘甜。抓住人生中的一分一秒，赛过虚度中的一月一年！(16）