关于垂直切分Vertical Sharding的粒度

推荐：博主历时三年倾注大量心血创作的《大数据平台架构与原型实现：数据中台建设实战》一书已由知名IT图书品牌电子工业出版社博文视点出版发行，真诚推荐给每一位读者！点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，扫码进入京东手机购书页面！

 

垂直切分的粒度指的是在做垂直切分时允许几级的关联表放在一个shard里．这个问题对应用程序和sharding实现有着很大的影响．

 

关联打断地越多，则受影响的join操作越多，应用程序为此做出的妥协就越大，但单表的路由会越简单，与业务的关联性会越小，就越容易使用统一机制处理．在此方向上的极端方案是：打断所有连接，每张表都配有路由规则，可以使用统一机制或框架自动处理．比如amoeba这样的框架，它的路由能且仅能通过SQL的特征（比如某个表的id）进行路由．

 

反之，若关联打断地越少，则join操作的受到的限制就小，应用程序需要做出的妥协就越小，但是表的路由就会变复杂，与业务的关联性就越大，就越难使用统一机制处理，需要针对每个数据请求单独实现路由．在此方向上的极端方案是：所有表都在一个shard里，也就是没有垂直切分，这样就没有关联被打断．当然这是非常极端的，除非整个数据库很简单，表的数量很少．

 

实际的粒度掌控需要结合“业务紧密程度”和“表格数据量”两个因素综合考虑，一般来说：

• 若划归到一起的表格关系紧密，且数据量并不大，增速也非常缓慢，则适宜放在一个shard里，不需要再进行水平切分;

• 若划归到一起的表格数据量巨大且增速迅猛，则势必要在垂直切分的基础上再进行水平切分，水平切分就意味着原单一shard会被细分成多个更小的shard，每一个shard存在一个主表（即会以该表ID进行散列的表）和多个相之相关的关联表。

总之，垂直切分的粒度在两个相反的方向上呈现优势与劣势并存并相互博弈的局面．架构师需要做的是结合项目的实际情况在两者之间取得收益最大化的平衡．

 

 

相关阅读：

数据库分库分表(sharding)系列(五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案

 

 

 

数据库分库分表(sharding)系列(四) 多数据源的事务处理

数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量

 

数据库分库分表(sharding)系列(二) 全局主键生成策略

 

数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示

 

关于垂直切分Vertical Sharding的粒度

数据库Sharding的基本思想和切分策略