关于微博：使用混合分区策略。微博包括ID，内容，转发数，评论数，发表时间等属性，笔者根据分析应用的倾向，根据转发数，评论数，赞数等属性拟合出一个影响力的属性，并以影响力作为微博垂直分区的依据，根据微博的创建时间作为水平分区的依据。
垂直分区：根据影响力划分为5个等级，具体如下表。分析应用可根据应用场景来选择全表分析查询或子表分析查询。
主分区表 | 非主分区表 | 下界 |
status | status _v1 | / |
status _v2 | 100 |
status _v3 | 200 |
status _v4 | 300 |
status _v5 | 400 |
水平分区：根据根据微博的发表时间，由于该网站一天发表的微博超过1亿条，超过了单台服务器，平均查询的数量，同时也为了避免写热点的问题，笔者采用了更小的时间单位小时，具体如下
复制组 | 区间 | 复制组 |
复制组1 | [1,2) [9,10) [17,18) | 复制组5 |
复制组2 | [2,3) [10,11) [18,19) | 复制组6 |
复制组3 | [3,4) [11,12) [19,20) | 复制组7 |
复制组4 | [4,5) [12,13) [20,21) | 复制组8 |
关于转发：使用混合分区策略。转发具有与微博相同的属性，笔者根据转发的再次转发数及转发者的粉丝等信息，拟合出转发影响力的属性，并以影响力属性分为垂直分区的依据，以被转发的原创微博的ID及转发时间为水平分区的依据。
垂直分区：根据影响力划分为5个等级，具体如下表。分析应用可根据应用场景来选择全表分析查询或子表分析查询。
主分区表 | 非主分区表 | 下界 |
repost | repost _v1 | / |
repost _v2 | 100 |
repost _v3 | 200 |
repost _v4 | 300 |
repost _v5 | 400 |
水平分区：由于关于转发的分析应用往往针对一个原创微博或一个时间段的微博而展开，所以为了避免产生读热点：对于影响力在1~3级的转发，并用根据原创微博ID离散水平分区的方式进行；对于影响力在4~5级的转发，由于转发的数量巨大，可达千万级别，若采用离散的水平分区方式，系统必定会将数据集中在一台服务器上，对转发进行分析时，只利用到一台服务器，导致产生读热点，所以采用按转发的时间进行水平分区，方式与微博的类似，不同的点在于，转发并不是使用小时，而是使用的是分钟，避免热门微博在短时间内产生大量的转发的情况。
关于评论：使用混合分区策略。评论的微博的影响力，作为评论的影响力，并按影响力进行垂直分区，见微博的垂直分区，与转发类似，对于影响力较小的微博评论，根据微博的ID进行散列水平分区，对于影响力较大的微博评论采用时间水平分区，根据的是评论时间的分钟数。
以上若干数据分区的使用例子，其中使用了水平分区，混合分区。与常见的数据库产品相比，HBase通过Region的分布式存储来实现水平分区，Oracle通过分区表来实现垂直分区，而Sequoiadb能同时支持水平分区和垂直分区，提供了至少2个以上维度，为复杂的数据分区环境实现提供了有力的支持。
一般来说，应用业务场景，即总量庞大，但单个查询最大值不大的场景，往往只需要数据水平分区，如淘宝用户订单管理，一个用户的订单不大可能达到百万级别以上，后台只需要当用户订单按用户维度进行水平分区，当一个用户登陆之后在一台机器上就足以查询出用户所需要的所有数据了；而在分析业务场景往往需要混合分区，因为分析业务场景往往中，单个查询的最大值就是总量，而不同的查询需要从不同的维度去切入，价值高的信息会被往往反复查询，如电商的订单分析系统，交易成功的订单比取消的订单信息价值更高，会在用户分析，店铺分析等多种场景下反复查询，如果只有简单的水平分区，必然导致重复的查询，浪费资源。
