HibernateShards-数据库水平分区解决方案

[b] HibernateShard[/b]
多数据库水平分区解决方案。

[b]1. 简介[/b]
Hibernate 的一个扩展，用于处理多数据库水平分区架构。
由google工程师 2007年 捐献给 Hibernate社区。
[url]http://www.hibernate.org/414.html[/url]
目前版本： 3.0.0 beta2， 未发GA版。
条件：Hibernate Core 3.2, JDK 5.0

[b]2. 水平分区原理[/b]
一个库表如 Order 存在于多个数据库实例上。按特定的分区逻辑，将该库表的数据存储在这些实例中，一条记录的主键 PK，在所有实例中不得重复。

水平分区在大型网站，大型企业应用中经常采用。
目的出于海量数据分散存储，分散操作，分散查询以便提高数据处理量和整体数据处理性能。

使用：
google工程师的设计还是非常好的，完全兼容 Hibernate本身的主要接口。

      org.hibernate.Session
      org.hibernate.SessionFactory 
       org.hibernate.Criteria 
       org.hibernate.Query 

因此程序员开发变化不大，甚至不需要关心后台使用了分区数据库。程序迁移问题不大。而且配置上比较简明。

[b]3. 三种策略：[/b]
1) ShardAccessStrategy, 查询操作时，到那个分区执行。
默认提供两个实现：
顺序策略：SequentialShardAccessStrategy， 每个query按顺序在所有分区上执行。
平行策略：ParallelShardAccessStrategy， 每个query以多线程方式并发平行的在所有分区上执行。 此策略下，需要使用线程池机制满足特定的性能需要，java.util.concurrent.ThreadPoolExecutor。

2) ShardSelectionStrategy, 新增对象时，存储到哪个分区。
框架默认提供了一个轮询选择策略 RoundRobinShardSelectionStrategy, 但一般不这样使用。
通常采用“attribute-based sharding”机制，基于属性分区。一般是用户根据表自己实现一个基于属性分区的策略类ShardSelectionStrategy ，例如，以下WeatherReport基于continent属性选择分区：

      public class WeatherReportShardSelectionStrategy implements ShardSelectionStrategy {
    public ShardId selectShardIdForNewObject(Object obj) {
        if(obj instanceof WeatherReport) {
            return ((WeatherReport)obj).getContinent().getShardId();
        }
        throw new IllegalArgumentException();
    }
}

3) ShardResolutionStrategy, 该策略用于查找单个对象时，判断它在哪个或哪几个分区上。
默认使用 AllShardsShardResolutionStrategy ，可以自定义例如：

public class WeatherReportShardResolutionStrategy extends AllShardsShardResolutionStrategy {
    public WeatherReportShardResolutionStrategy(List<ShardId> shardIds) {
        super(shardIds);
    }

    public List<ShardId> selectShardIdsFromShardResolutionStrategyData(
            ShardResolutionStrategyData srsd) {
        if(srsd.getEntityName().equals(WeatherReport.class.getName())) {
            return Continent.getContinentByReportId(srsd.getId()).getShardId();
        }
        return super.selectShardIdsFromShardResolutionStrategyData(srsd);
    }
}

[b]4. 水平分区下的查询[/b]

对于简单查询 HibernateShard 可以满足。

水平分区下多库查询是一个挑战。主要存在于以下三种操作：
1) distinct
因为需要遍历所有shard分区，并进行合并判断重复记录。
2) order by
类似 1)
3) aggregation
count，sim，avg等聚合操作先分散到分区执行，再进行汇总。
是不是有点类似于 MapReduce ？ 呵呵。

目前 HibernateShard 不支持 1), 2), 对 3) 部分支持

HibernateShard 目前通过 Criteria 接口的实现对 聚合提供了较好的支持， 因为 Criteria 以API接口指定了 Projection 操作，逻辑相对简单。

而HQL，原生 SQL 还不支持此类操作。


[b]5. 再分区和虚拟分区[/b]
当数据库规模增大，需要调整分区逻辑和数据存储时， 需要再分区。
两种方式： 1）数据库数据迁移其他分区； 2） 改变记录和分区映射关系。这两种方式都比较麻烦。尤其“改变记录和分区映射关系”，需要调整 ShardResolutionStrategy。

HibernateShard 提供了一种虚拟分区层。当需要调整分区策略时，只需要调整虚拟分区和物理分区映射关系即可。以下是使用虚拟分区时的配置创建过程：

 
  Map<Integer, Integer> virtualShardMap = new HashMap<Integer, Integer>();
virtualShardMap.put(0, 0);
virtualShardMap.put(1, 0);
virtualShardMap.put(2, 1);
virtualShardMap.put(3, 1);
ShardedConfiguration shardedConfig =
    new ShardedConfiguration(
        prototypeConfiguration,
        configurations,
        strategyFactory,
        virtualShardMap);
return shardedConfig.buildShardedSessionFactory();

[b]6. 局限：[/b]
1）HibernateShard 不支持垂直分区， 垂直+水平混合分区。

2） 水平分区下 查询功能受到一定限制，有些功能不支持。实践中，需要在应用层面对水平分区算法进行更多的考虑。
3） 不支持跨分区的 关系 操作。例如：删除A分区上的 s 表，B分区上的关联子表 t的记录无法进行参照完整性约束检查。 （其实这个相对 跨分区查询的挑战应该说小的多，也许google工程师下个版本会支持，呵呵）

4) 解析策略接口似乎和对象ID全局唯一性有些自相矛盾，
AllShardsShardResolutionStrategy 的接口返回的是给定对象ID所在的 shard ID集合，按理应该是明确的一个 shard ID.

参考资料：HibernateShard 参考指南。