Hibernate Shards

Hibernate Shards由Google员工2007年贡献给Hibernate社区，Shard本意是segment或者partition，shard正好也是Google内部术语，同样的命名也出现在MongoDB中。

 

在大数据量的应用中，DB很容易成为应用的瓶颈，单表在随着数据量的不断增加，性能会出现急剧的下降，这个时候对数据的切分成为必然。常用的数据切分方式有：

垂直切分（VerticalPartition/Sharding）：将业务逻辑相关的一些数据存储在同一数据库中，将低耦合的各模块直接的数据区分开。

水平切分（HorizontalPartition/Sharding）：将同一表中的数据拆分到不同的数据库中。

 

不太严格的讲，对于海量的数据，如果是因为表多个数据多，一般适合使用垂直切分，即把关系紧密（比容同一模块）的表切分出来放在同一server上。如果表不多，但是单表数据量非常大，这个适合使用水平切分，将表中的数据以某种规则切分到不同的server上。

 

这里介绍的Hibernate Shards是建立在Hibernate Core之上，通过增加水平切分技术的支持，封装和最小化数据库水平分片复杂度的框架，简言之，我们使用hibernate为多个数据库的使用提供一个统一的视图。

 

Hibernate Shards的3个核心是：

ShardAccessStrategy：分片的访问策略，即在查询结果确定在一个shard集之后，对这个shard集的访问策略，默认的实现有序列式（SequentialShardAccessStrategy）和并发访问方式（ParallelShardAccessStratery）。

 

ShardSelectionStrategy：决定在哪个shard上创建对象的时候调用，可以通过实现该接口来确定分片的规则，例如hash等。

 

ShardResolutionStrategy：查找指定对象时，根据它来确定该对象所在的shard，通常与ShardSelectionStrategy相对应。

 

主键生成策略：在分片的情况之下需要做到主键在全局情况下的唯一，具体的生成策略可以在应用中自己实现，也可以使用Hibernate Shards提供的策略：ShardedUUIDGenerator，该策略中自动包含了Shard Id，查找时可以更快的确定shard。

 

扩展的问题：有人说Hibernate Shards对于增加新的shard没有任何支持，需要应用自己来处理。不过貌似Hibernate Shards对于二次分片（Resharding）提供了虚拟分片（Virtual Shards），只是对于将物理分片上的数据进行迁移时，因为应用的复杂度问题，没有作处理。

 

HibernateShards存在的问题也比较多，附件中的文档有详细的介绍。