关于垂直切分Vertical Sharding的粒度

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

　　关联打断地越多，则受影响的join操作越多，应用程序为此做出的妥协就越大，但单表的路由会越简单，与业务的关联性会越小，就越容易使用统一机制处理．在此方向上的极端方案是：打断所有连接，每张表都配有路由规则，可以使用统一机制或框架自动处理．比如amoeba这样的框架，它的路由能且仅能通过SQL的特征（比如某个表的id）进行路由．若关联打断地越少(先进行垂直切分，关系紧密的多张表(比如一个模块内)会放在同一个shard里，并保留关联关系)，则join操作的限制就宽松，应用程序需要做出的妥协就越小，但是多数表(那些shard里的从表)的路由就会变复杂，与业务的关联性就越大，就越难使用统一机制处理，需要针对每个数据请求单独实现路由．在此方向上的极端方案是所有表都在一个shard里，也就是没有垂直切分，这样就没有关联被打断．当然这是非常极端的，除非整个数据库很简单，表的数量很少．在此方向上较为常见的方案是：在应用程序的数据访问层上实现路由逻辑，借助应用程序的上下文可以实现基于业务的路由．比如在一个论坛系统中，Forum -> Thread -> Post三张表应该自然地分在一个shard里，应用程序在save一个post的时候，已经确定了这是为哪个forum的哪个thread追加的post.借由forum的id，能将这个post正确地散列到shard上．同样，对说读取来说，当应用程序请求一个post的时候，（如无单独追踪post的UC）应用程序之前应该已经导航到了其所在的forum和thread.这种关系和领域驱动设计中＂聚合＂概念真是如出一辙．不过这有点扯远了．

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