Hibernate Shards

Hibernate Shards是在Hibernate之上支持数据库水平分区的软件。Shard其实就是partition或segment的意思，不过Google的人好像喜欢称之为shard。目前大部分WEB应用都不断的转向使用廉价计算机集群组成的分布式数据库，Hibernate本身没有这一支持，不免有些遗憾。Hibernate Shards的目的就是为了填补Hibernate在这方面的不足。Shards原来是Google某些员工利用著名20%时间的结果，后来开源并捐给了Hibernate社区。

虽然是支持分布式数据库，但基于Hibernate，Shards的实现实际上很简单，当然功能也很受限。Shards的核心大致只是以下三个概念（在程序中就是三个接口，应用程序可提供自己的定制实现）：

1. ShardSelectionStrategy: 当通过Hibernate物化一个对象时，调用这一接口得到用于存储这一对象的shard。系统提供一个根据round robin策略依次使用各个shard的默认实现，当然严肃一点的用户一般是不用这个的。通常会根据某个属性做个hash分区什么的。
2. ShardResolutionStrategy: 在通过Hibernate获取一个对象时，调用这一接口得到要访问的shard。若是用前面的round robin策略，这里就要返回所有的shard了。如果用hash分区的话就可以算出来。
3. ShardAccessStrategy: 这个相对不重要一点，就是在使用ShardResolutionStrategy后确实一个shard集后，按什么次序访问这些shard，比如根据id从前到后访问啦，并行同时访问啦什么的。

大概说来就是使用ShardSelectionStategy确定新加入的对象的存储位置，使用ShardResolutionStrategy为Hibernate查找对象提供方向指导。当然这两个strategy的实现要对应，不然就找不到了。

既然做了分布式，总得考虑扩展问题。如果增加了新的shard，通常就要重新分布数据来实现扩展性，不过Hibernate Shards对这个问题的处理方法是不处理，让应用自己来干。没办法这个问题确实有点复杂。

Hibernate Shards的一些其它问题：

1. 对象不能跨shard引用。这个问题有点严重，会导致无法分布式。比如一个用户的好友是另一个用户，由于这一点，用户与其好友必须在同一shard上，最后的结果是所有用户都要在同一shard上。
2. 基本上不支持稍微复杂一点的HQL