海量数据的存储与访问瓶颈解决方案-数据切分

---

前言

当前时代背景之下，大众对互联网的依赖非常之高，也因此产生了海量的数据。对于企业来说，这些数据非常的有价值，但同时也带来了很多问题。比如海量数据的存储和访问成为了系统设计和使用的瓶颈。因此，我们迫切需要解决海量数据带来的问题。而数据的切分可以很好的解决这样的问题。

---

一、什么是数据切分？

数据切分，简单来理解就是把之前一台数据库上的数据，通过某种手段，切分到不同的服务器上，减少单台数据库的负载压力。数据切分根据切分的规则，可分为水平切分 和垂直切分

二、垂直切分

垂直切分即按照不同的表或者schema切分到不同的数据库。比如在经典的电商项目中，可以把商品相关的表和订单相关的表切分到不同的数据库中。如下：

垂直切分的特点就是规则简单，可根据不同的业务模块进行划分。
一个架构设计好的应用系统，其总体功能肯定是由不同的模块组合而成。而每一个模块都对应一系列的表，比如在之前的电商系统中，商品模块的表就有：分类，属性，属性值，品牌，商品，sku等。而订单模块则有：订单，订单明细，订单收货地址等，如下：

1.优点

·拆分后业务清晰，拆分规则明确；
·系统之间容易扩展和整合；
·数据维护简单

2.缺点

·部分业务表无法join，只能通过接口调用，提升了系统的复杂度；
·跨库事务难以处理；
·垂直切分后，某些业务数据过于庞大，仍然存在单体性能瓶颈；

三、水平切分

正如垂直切分的缺点的最后一条所提到的，当某个表的数据量过于庞大，垂直切分无法解决该情况下的性能问题。这时就需要使用水平切分了。
水平切分相较于垂直切分更为复杂，它需要根据某种规格，将一个表中的数据切分到不同的数据库中。
比如上面的订单表：可以根据订单尾号进行拆分，尾号为奇数的在order1中，偶数的在order2中。这样，原本存在一个数据库中的订单数据，被水平的切分成了两个数据库。在查询订单数据时，我们还要根据订单的尾号，判断这个订单在数据库1中，还是在数据库2中，然后将这条SQL语句发送到正确的数据库中，查出订单。水平切分的架构图如下：

水平拆分数据，要先订单拆分的规则，找到你要按哪个维度去拆分。
还是前面订单的例子，我们按照订单尾号的奇偶去拆分，那么这样拆分会有什么影响呢？
假如我是一个用户，我下了两个订单，一个订单尾号为奇数，一个订单尾号为偶数，这时，我去个人中心，订单列表页去查看我的订单。那么这个订单列表页要去怎么查，要根据我的用户id分别取订单1库和订单2库去查询出订单，然后再合并成一个列表，是不是很麻烦。
所以，咱们在拆分数据时，一定要结合业务，选择出适合当前业务场景的拆分规则。那么按照用户id去拆分数据就合理吗？也不一定，比如：咱们的身份变了，不是买家了，而是卖家，我这个卖家有很多的订单，卖家的后台系统也有订单列表页，那这个订单列表页要怎么样去查？是不是也要在所有的订单库中查一遍，然后再聚合成一个订单列表呀。那这样看，是不是按照用户id去拆分订单又不合理了。所以在做数据水平拆分时，是对架构师的真正考验。

几种水平切分分片规则

1.根据用户id求模进行切分；
2.根据日期切分；
3.根据其他字段求模进行切分

1.优点

·解决了单库大数据、高并发的性能瓶颈；
·拆分规则封装好，对应用端几乎透明，开发人员无需关心拆分细节；
·提高了系统的稳定性和负载能力；

2.缺点

·拆分规则很难抽象；
·分片事务一致性难以解决；
·二次扩展时，数据迁移、维护难度大。比如：开始我们按照用户id对2求模，但是随着业务的增长，2台数据库难以支撑，还是继续拆分成4个数据库，那么这时就需要做数据迁移了。

---

总结

世界上的万物没有完美的，有利就有弊，就像数据切分一样。无论是垂直切分，还是水平切分，它们解决了海量数据的存储和访问性能问题，但也随之而来的带来了很多新问题，它们的共同缺点有：
·分布式的事务问题；
·跨库join问题；
·多数据源的管理问题