主键 切分利用多个数据库，其中所有数据库都独立起作用，不干涉其他切分。因此，如果您依赖于数据库序列（如自动主键生成），很有可能在一个数据库集中将出现同一个主键。可以跨分布式数据库协调序列，但是这样会增加系统的复杂程度。避免相同主键最安全的方法就是让应用程序（应用程序将管理切分系统）生成主键。

跨切分查询 大部分切分实现（包括 Hibernate Shards）不支持跨切分查询，这就意味着，如果您想利用不同切分的两个数据集，就必须处理额外的长度。（有趣的是，Amazon 的 SimpleDB 也禁止跨域查询）例如，如果将美国客户信息存储在切分 1 中，还需要将所有相关数据存储在此。如果您尝试将那些数据存储在切分 2 中，情况就会变得复杂，系统性能也可能受影响。这种情况还与之前提到的一点有关 — 如果您因为某种原因需要进行跨切分连接，最好采用一种可以消除重复的方式管理键！

很明显，在建立数据库前必须全面考虑切分策略。一旦选择了一个特定的方向之后，您差不多就被它绑定了 — 进行切分后很难随便移动数据了。

避免不成熟切分

切分最好在后期实现。如不成熟优化一样，基于预期数据增长的切分可能是灾难的温床。成功的切分实现基于对于应用程序数据随时间增长的理解，以及之后对于未来的推断。一旦对数据进行切分后，移动数据会非常困难。

Java开发2.0: 使用Hibernate Shards进行切分(2)

一个策略示例

因为切分将您绑定在一个线型数据模型中（也就是说，您无法轻松连接不同切分中的数据），您必须对如何在每个切分中对数据进行逻辑组织有一个清晰的概念。这可以通过聚焦域中的主要节点实现。如在一个电子商务系统中，主要节点可以是一个订单或者一个客户。因此，如果您选择 “客户” 作为切分策略的节点，那么与客户有关的所有数据将移动至各自的切分中，但是您仍然必须选择将这些数据移动至哪个切分。

对于客户来说，您可以根据所在地（欧洲、亚洲、非洲等）切分，或者您也可以根据其他元素进行切分。这由您决定。但是，您的切分策略应该包含将数据均匀分布至所有切分的方法。切分的总体概念是将大型数据集分割为小型数据集；因此，如果一个特定的电子商务域包含一个大型的欧洲客户集以及一个相对小的美国客户集，那么基于客户所在地的切分可能没有什么意义。

回到比赛 — 使用切分！

现在让我们回到我经常提到的赛跑应用程序示例中，我可以根据比赛或参赛者进行切分。在本示例中，我将根据比赛进行切分，因为我看到域是根据参加不同比赛的参赛者进行组织的。因此，比赛是域的根。我也将根据比赛距离进行切分，因为比赛应用程序包含不同长度和不同参赛者的多项比赛。

请注意：在进行上述决定时，我已经接受了一个妥协：如果一个参赛者参加了不止一项比赛，他们分属不同的切分，那该怎么办呢？Hibernate Shards （像大多数切分实现一样）不支持跨切分连接。我必须忍受这些轻微不便，允许参赛者被包含在多个切分中 — 也就是说，我将在参赛者参加的多个比赛切分中重建该参赛者。

为了简便起见，我将创建两个切分：一个用于 10 英里以下的比赛；另一个用于 10 英里以上的比赛。

实现 Hibernate Shards

Hibernate Shards 几乎可以与现有 Hibernate 项目无缝结合使用。唯一问题是 Hibernate Shards 需要一些特定信息和行为。比如，需要一个切分访问策略、一个切分选择策略和一个切分处理策略。这些是您必须实现的接口，虽然部分情况下，您可以使用默认策略。我们将在后面的部分逐个了解各个接口。

ShardAccessStrategy

执行查询时

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!