数据切分核心思想
数据切分核心思想
jwang为什么要进行数据切分
当前微服务架构非常流行，很多都会采用微服务架构对其系统进行拆分。 而虽然产生了多个微服务，但因为其用户量和数据量的问题，很有可能仍然使用的是同一个数据库。
但是随着用户量和数据量增加，就会出现很多影响数据库性能的因素，如：数据存储量、IO瓶颈、访问量瓶颈等。此时就需要将数据进行拆分，从一个库拆分成多个库。
数据拆分方式
垂直拆分
垂直拆分是按照业务将表进行分类并分布到不同的数据节点上。在初始进行数据拆分时，使用垂直拆分是非常直观的一种方式。
垂直拆分的优点：
- 拆分规则明确，按照不同的功能模块或服务分配不同的数据库。
- 数据维护与定位简单。
垂直拆分的缺点：
- 对于读写极其频繁且数据量超大的表，仍然存在存储与性能瓶颈。简单的索引此时已经无法解决问题。
- 会出现跨库join。
- 需要对代码进行重构，修改原有的事务操作。
- 某个表数据量达到一定程度后扩展起来较为困难
水平拆分
为了解决垂直拆分出现的问题，可以使用水平拆分继续横向扩展，首先，可以如果当前数据库的容量没有问题的话，可以对读写极其频繁且数据量超大的表进行分表操作。由一张表拆分出多张表。
在一个库中，拆分出多张表，每张表存储不同的数据，这样对于其操作效率会有明显的提升。而且因为处于同一个库中，也不会出现分布式事务的问题。
而拆分出多张表后，如果当前数据库的容量已经不够了，但是还要继续拆分的话，就可以进行分库操作，产生多个数据库，然后在扩展出的数据库中继续扩展表。
水平拆分的优点：
- 尽量的避免了跨库join操作。
- 不会存在超大型表的性能瓶颈问题。
- 事务处理相对简单。
- 只要拆分规则定义好，很难出现扩展性的限制。
水平拆分的缺点：
- 拆分规则不好明确，规则一定会和业务挂钩，如根据id、根据时间等。
- 不好明确数据位置，难以进行维护。
- 多数据源管理难度加大，代码复杂度增加。
- 也会存在分布式事务问题
- 数据库维护成本增加
数据切分带来的问题
- 按照用户ID求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。
- 按照日期，将不同月甚至日的数据分散到不同的库中。
- 按照某个特定的字段求模，或者根据特定范围段分散到不同的库中。
数据切分带来的核心问题
- 产生引入分布式事务的问题。
- 跨节点 Join 的问题。
- 跨节点合并排序分页问题。
