当关系数据库试图在一个单一表中存储数 TB 的数据时，总性能经常会降低。显然，对所有数据编索引不仅对于读而且对于写都很耗时。因为 NoSQL 数据商店尤其适合存储大型数据（如 Google 的 Bigtable），显然 NoSQL 是一种非关系数据库方法。对于倾向于使用 ACID-ity 和实体结构关系数据库的开发人员及需要这种结构的项目来说，切分是一个令人振奋的可选方法。
切分 是数据库分区的一个分支，但是它不是本地数据库技术 — 切分发生在应用程序级别。在各种切分实现中，Hibernate Shards 是 Java 技术世界中最受欢迎的一个。这个灵活绝妙的项目可以让您使用映射至逻辑数据库的 POJO 对切分数据集进行几乎无缝操作（我将在下文简要介绍 “几乎” 的原因）。使用 Hibernate Shards 时，您无须将您的 POJO 特别映射至切分 — 您可以像使用 Hibernate 方法对任何常见关系数据库进行映射时一样对其进行映射。Hibernate Shards 可以为您管理低级别的切分任务。
到目前为止，在本 系列 中，我已经使用了一个基于比赛和参赛者类推关系的简单域展示了各种数据库存储技术。本月，我将继续使用这个熟悉的示例介绍一种实用的切分技术，然后在 Hibernate Shards 中对其进行实现。注意：与切分相关的主要工作与 Hibernate 没有太大关系；事实上，Hibernate Shards 的编码工作比较简单。其中关键的部分在于判断 如何进行切分以及对什么进行切分。
关于本系列
自 Java 技术首次诞生以来，Java 开发格局已发生了翻天覆地的变化。得益于成熟的开源框架和可靠的租赁部署基础设施，现在可以迅速而经济地组装、测试、运行和维护 Java 应用程序。在 本系列 中，Andrew Glover 探索使这种新的 Java 开发风格成为可能的各种技术和工具。
切分简介
数据库切分 是一个固有的关系流程，可以通过一些逻辑数据块将一个表的行分为不同的小组。例如，如果您正在根据时间戳对一个名为 foo 的超大型表进行分区，2010 年 8 月之前的所有数据都将进入分区 A，而之后的数据则全部进入分区 B。分区可以加快读写速度，因为它们的目标是单独分区中的较小型数据集。
分区功能并不总是可用的（MySQL 直到 5.1 版本后才支持），而且其需要的商业系统的成本也让人望而却步。更重要的是，大部分分区实现在同一个物理机上存储数据，所以受到硬件基础的影响。除此之外，分区也不能鉴别硬件的可靠性或者说缺乏可靠性。因此，很多智慧的人们开始寻找进行伸缩的新方法。
切分 实质上是数据库级别的分区：它不是通过数据块分割数据表的行，而是通过一些逻辑数据元素对数据库本身进行分割（通常跨不同的计算机）。也就是说，切分不是将数据表 分割成小块，而是将整个数据库 分割成小块。
切分的一个典型示例是基于根据区域对一个存储世界范围客户数据的大型数据库进行分割：切分 A 用于存储美国的客户信息，切分 B 用户存储亚洲的客户信息，切分 C 欧洲，等。这些切分分别处于不同的计算机上，且每个切分将存储所有相关数据，如客户喜好或订购历史。
切分的好处（如分区一样）在于它可以压缩大型数据：单独的数据表在每个切分中相对较小，这样就可以支持更快速的读写速度，从而提高性能。切分还可以改善可靠性，因为即便一个切分意外失效，其他切分仍然可以服务数据。而且因为切分是在应用程序层面进行的，您可以对不支持常规分区的数据库进行切分处理。资金成本较低同样也是一个潜在优势。
切分和策略
像很多其他技术一样，进行切分时也需要作出部分妥协。因为切分不是一项本地数据库技术 — 也就是说，必须在应用程序中实现 —在开始切分之前需要制定出您的切分策略。进行切分时主键和跨切分查询都扮演重要角色，主要通过定义您不可以做什么实现。
主键
切分利用多个数据库，其中所有数据库都独立起作用，不干涉其他切分。因此，如果您依赖于数据库序列（如自动主键生成），很有可能在一个数据库集中将出现同一个主键。可以跨分布式数据库协调序列，但是这样会增加系统的复杂程度。避免相同主键最安全的方法就是让应用程序（应用程序将管理切分系统）生成主键。
跨切分查询
大部分切分实现（包括 Hibernate Shards）不支持跨切分查询，这就意味着，如果您想利用不同切分的两个数据集，就必须处理额外的长度。（有趣的是，Amazon 的 SimpleDB 也禁止跨域查询）例如，如果将美国客户信息存储在切分 1 中，还需要将所有相关数据存储在此。如果您尝试将那些数据存储在切分 2 中，情况就会变得复杂，系统性能也可能受影响。这种情况还与之前提到的一点有关 — 如果您因为某种原因需要进行跨切分连接，最好采用一种可以消除重复的方式管理键！
很明显，在建立数据库前必须全面考虑切分策略。一旦选择了一个特定的方向之后，您差不多就被它绑定了 — 进行切分后很难随便移动数据了。
避免不成熟切分
切分最好在后期实现。如不成熟优化一样，基于预期数据增长的切分可能是灾难的温床。成功的切分实现基于对于应用程序数据随时间增长的理解，以及之后对于未来的推断。一旦对数据进行切分后，移动数据会非常困难。