垂直切分
- 按照业务切分
我们的数据库中有很多表，将数据库中的数据以表的维度切分出去；以前我们的订单、商品、用户都在一个数据库里，垂直切分后可以分别将订单、商品、用户分别拆分到各自单独的数据库中 - 每种业务一个数据库
- 不同业务之间，禁止跨库join联查
比如一个用户查询订单的操作，通常在单库查询的情况下，订单表和用户表联合查询是可以带出订单和用户信息的；但是在做数据库切分后，我们就要禁止跨库的联查，因为跨库的查询是非常消耗性能的；一般是通过调用服务的形式去查询其他库（用户库）的信息，在set到订单数据中，这是在切分数据库后操作比较麻烦的地方；
以下是垂直切分的架构图：
上面是业务系统，订单库和商品库垂直切分相互独立，订单库只存订单数据，商品库只存商品数据，如果订单里面要查询商品，就必须要通过调用服务的形式去查询；禁止跨库join联查；
垂直切分-优点
- 拆分后业务清晰，拆分规则明确；
- 系统之间容易扩展和整合；
比如商品库有新的业务需求，需要做系统升级，但是并不影响订单库和用户库； - 数据维护简单
只需要维护一个库的数据就可以了，不会和其他的库有任何的关联；
垂直切分-缺点
- 部分业务表无法join，只能通过接口调用，提升了系统的复杂度
- 跨库事务难以处理
比如下订单，要生成订单、扣减库存，库存一般在商品库当中，既要生成订单，又要扣减库存，其中有一步失败就需要整体的回滚；在单体项目中事务的回滚非常的容易，但是如果是跨库，跨库的事务也是一个难点，后续会介绍分布式中跨库的事务； - 垂直切分后，某些业务数据过于庞大，仍然存在单体性能瓶颈
比如某一个业务的数据量非常的大，单体数据库业务没有办法能够存储下去的
水平切分
- 将一张表的数据按照某种规则分到不同的数据库中
- 需确定分片的规则
比如订单表，按照用户进行切分，订单是哪个用户的，按照用户id进行水平切分；切分的规则是对某一个数字进行取模，如果是对2取模，那就是奇偶数了；奇数在一个订单库里，偶数在另一个订单库里； - 使用分片字段查询时，可确定实体库，其他字段查询，查询所有表
比如用户查看自己的订单，在按用户进行取模水平切分时，用户可以通过用户id确定当前用户订单所在的实体库；而商户如果想查看自己的所有订单时，需要用商户id查询订单，也就需要在所有的订单分片库中查询数据，然后进行汇总；
以下是水平切分的架构图
水平切分-优点
- 解决了单库大数据、高并发的性能瓶颈
- 拆分规则封装好，对应用端几乎透明，开发人员无需关心拆分细节
- 提高了系统的稳定性和负载能力
水平切分-缺点
- 拆分规则很难抽象
上面说到的，同一个订单表，用用户id查询和用商户id查询；如果按用户id切分，用户查询是方便了，能找到具体的单库，但是商户查询就必须查询所有订单分片表；所以拆分规则难以取舍，有利有弊； - 分片事务一致性难以解决
- 二次扩展时，数据迁移、维度难度大
一开始水平分片库有两个，一个存用户id为奇数，另一个存用户id为偶数；如果现在两个数据库依然无法满足订单数据量，此时在扩展两个分片库，就变成了四个订单分片库，规则就需要改成用户id用4来取模，拆分成四个数据库；
在原本是两个分片库规则中的数据就需要迁移到新规则匹配的数据库中，而这个数据迁移就会很麻烦
切分规则的选择
先垂直后水平