水平切分
水平切分又叫做 Sharding，它是将同一个表中的记录横向拆分到多个结构相同的表中。
当一个表的数据不断增多时，Sharding 是必然的选择，它可以将数据分不到集群的不同节点上，从而缓存单个数据库的压力。
比如说一个用户信息表，太长了，我们按照某个标准给同样的一张表分为多个不同的多张表，存储在不同的从数据库中，当然数据量特别大才有必要。
优点
- 表关联关系基本能够在数据库端全部完成。
- 不会存在那种超大型数量和高负载的表遇到瓶颈的问题。
- 应用程序端整体架构改动相对较少。
- 事务处理起来会相对简单。
- 只要切分规则能够定义好，基本上较难遇到扩展性限制。
缺点
- 切分规则相对更为复杂，很难抽象出一个能够满足整个数据库的切分规则。
- 后期数据的维护难度有所增加，认为手工定位数据更为困难。
- 应用系统各模块的耦合度较高，可能会对后面数据的迁移拆分造成一定的困难。
垂直切分
垂直切分是将一张表按列切分成多个表，通常是按照列的关系密集程度进行切分，也可以利用垂直切分把经常使用的列和不经常使用的列切分到不同的表中。
在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，列入将原来的电商数据库垂直切分成商品数据库，用户数据库等。
优点
- 数据库的拆分简单明了，拆分的规则明确。
- 应用程序模块清晰明确，整合容易。
- 数据维护方便易行，容易定位。
缺点
- 部分表关联无法在数据库级别完成，需要在程序中完成。
- 对于访问及其频繁以及数据量超大的表仍然存在性能瓶颈，不一定能满足要求。
- 事务处理相对会更为复杂。
- 切分达到一定程度之后，扩展性会遇到限制。
- 过度的切分可能会带来系统过度复杂导致难以维护。
Sharding 策略
事务问题
使用分布式事务来解决，比如 XA 接口。
链接
可以将原来的 JOIN 分解成多个当表查询，然后再用户程序中进行 JOIN。
ID 唯一性
- 使用全局唯一ID:GUID
- 为每个分片指定一个 ID 范围。
- 分布式 ID 生成器（如 Twitter 的 Snowflake 算法）。
码云仓库同步笔记，可自取欢迎各位star指正:https://gitee.com/noblegasesgoo/notes
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
