Hibernate Shard基礎分析
1.水平分區下的查詢
對于簡單查詢Hibernate Shard可以滿足。
水平分區下多庫查詢是一個挑戰。主要存在于以下三種操作：
1） distinct因為需要遍歷所有shard分區，并進行合并判斷重復記錄。
2） order by類似 1）
3） aggregation count，sim，avg等聚合操作先分散到分區執行，再進行匯總。
是不是有點類似于 MapReduce ？ 呵呵。
Hibernate Shard 目前通過 Criteria 接口的實現對 聚合提供了較好的支持， 因為 Criteria 以API接口指定了 Projection 操作，邏輯相對簡單。而HQL，原生 SQL 還不支持此類操作。
2. 再分區和虛擬分區
當數據庫規模增大，需要調整分區邏輯和數據存儲時， 需要再分區。
兩種方式：
1）數據庫數據遷移其他分區；
2）改變記錄和分區映射關系。這兩種方式都比較麻煩。尤其“改變記錄和分區映射關系”，需要調整 ShardResolutionStrategy.
Hibernate Shard 提供了一種虛擬分區層。當需要調整分區策略時，只需要調整虛擬分區和物理分區映射關系即可。以下是使用虛擬分區時的配置創建過程：
Java代碼
- 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();
3.局限：
1）Hibernate Shard 不支持垂直分區， 垂直+水平混合分區。
2）水平分區下 查詢功能受到一定限制，有些功能不支持。實踐中，需要在應用層面對水平分區算法進行更多的考慮。
3）不支持跨分區的 關系 操作。例如：刪除A分區上的 s 表，B分區上的關聯子表 t的記錄無法進行參照完整性約束檢查。 （其實這個相對 跨分區查詢的挑戰應該說小的多，也許google工程師下個版本會支持，呵呵）
4）解析策略接口似乎和對象ID全局唯一性有些自相矛盾，AllShardsShardResolutionStrategy 的接口返回的是給定對象ID所在的 shard ID集合，按理應該是明確的一個 shard ID.
【編輯推薦】
