计算机 软件工程 外文翻译 外文文献 英文文献

一、外文资料译文：

Java开发2.0：使用 Hibernate Shards 进行切分

横向扩展的关系数据库

Andrew Glover，作者兼开发人员，Beacon50

摘要：Sharding并不适合所有网站，但它是一种能够满足大数据的需求方法。对于一些商店来说，切分意味着可以保持一个受信任的 RDBMS，同时不牺牲数据可伸缩性和系统性能。在 Java 开发 2.0 系列的这一部分中，您可以了解到切分何时起作用，以及何时不起作用，然后开始着手对一个可以处理数 TB 数据的简单应用程序进行切分。 日期：2010年8月31日 级别：中级

PDF格式：A4和信（64KB的15页）取得Adobe?Reader?软件

当关系数据库试图在一个单一表中存储数 TB 的数据时，总体性能通常会降低。索引所有的数据读取，显然是很耗时的，而且其中有可能是写入，也可能是读出。因为 NoSQL 数据商店尤其适合存储大型数据，但是 NoSQL 是一种非关系数据库方法。对于倾向于使用 ACID-ity 和实体结构关系数据库的开发人员及需要这种结构的项目来说，切分是一个令人振奋的选方法。

切分 一个数据库分区的分支，不是在本机上的数据库技术，它发生在应用场面上。在各种切分实现，Hibernate Shards 可能是 Java? 技术世界中最流行的。这个漂亮的项目可以让您使用映射至逻辑数据库的 POJO 对切分数据集进行几乎无缝操作。当你使用 Hibernate Shards 时，您不需要将你的 POJO 特别映射至切分。您可以像使用 Hibernate 方法对任何常见关系数据库进行映射时一样对其进行映射。Hibernate Shards 可以为您管理低级别的切分任务。

迄今为止，在这个系列，我用一个比赛和参赛者类推关系的简单域表现出不同的数据存储技术比喻为基础。这个月，我将使用这个熟悉的例子，介绍一个实际的切分策略，然后在Hibernate实现它的碎片。请注意，切分首当其冲的工作是和Hibernate没有必然关系的，事实上，对Hibernate stards编码部分是容易的。真正难的是搞清楚内容碎片和你的工作方式。。

关于本系列

Java的发展前景已经发生了根本变化，因为Java技术初现端倪。得益于成熟的开源框架和可靠的租金部署基础设施，它现在的组装，测试，运行和维护Java应用开发的速度和成本降低。在这个系列中，Andrew Glover探讨了技术和工具，使这个新的Java开发有尽可能多的典范。

切分简介

数据库切分是一种划分成一些小团体的逻辑数据，可以将一块表的分成不同的小组。例如，如果您正在根据时间戳对一个名为 foo 的超大型表进行分区，2010 年 8 月之前的所有数据都将进入分区 A，而之后的数据则全部进入分区 B。分区可以加快读写速度，因为它们的目标是单独分区中的较小型数据集。

分区并不总是可用的（MySQL并没有支持它，直到5.1版），而且与商业系统一起做让它的成本可以让人望而却步。更何况，在同一物理机上实现最分区存储数据，所以你仍然受到硬件基础的限制。分区也不能解决可靠性的或硬件不足。因此，聪明的人开始为寻找各种新的方法。

切分基本上是在数据库级别的：而不是分裂的碎片的数据表的行，数据库本身是被分割（通常是在不同的机器）的一些逻辑数据元素，而不是分裂成较小的块表，分割分片成一个完整的数据库小切分基本上是在数据库级别的：而不是分裂的碎片的数据表的行，数据库本身是被分割（通常是在不同的机器）的一些逻辑数据元素，块。

切分典型的例子是基于大型数据库存储划分各地区的全球客户数据：切分 A 用于存储美国的客户信息，切分 B 用户存储亚洲的客户信息，切分 C 欧洲，等。这些切分分别处于不同的计算机上，且每个切分将存储所有相关数据，如客户喜好或订购历史。

对分片（如分区）的好处是它压缩大数据：在每个单独的碎片表 ，它允许更快的读取和写入，提高了性能。分片是也可以提高想象可靠性，因为即使一碎片意外失败，其他人仍然能够满足数据。而由于分片是在应用层完成，你可以做的数据库在常规下不支持分割它。资金成本也可能降低。

主键

切分利用多个数据库，所有这些都有自主意识的功能，不干涉其他切分。因此，如果你依赖于数据库序列（如主键自动生成），很可能是相同的主键将显示在一个数据库上成立。这是可能的，以协调跨分布式数据库序列，但这样做增加了系统的复杂性。最安全的方式，禁止重复的主键是让你的应用程序（这将是一个sharded管理系统反正）生成密钥。

跨碎片查询

大部分（包括Hibernate碎片）分片的实现不允许跨碎片查询，这意味着你必须去额外的长度，如果你想利用两对来自不同的碎片的数据集。（有趣的是，Amazon的SimpleDB的还禁止跨域查询。）如果将美国客户信息存储在切分 1 中，还需要将所有相关数据存储在此。如果您尝试将那些数据存储在切分 2 中，情况就会变得复杂，系统性能也可能受影响。这种情况也与先前提出的观点 - 如果你有点最终需要做跨碎片连接，你最好的管理方式，消除了重复的可能性管理键！显然，你需要充分考虑分片策略，然后再设置你的数据库。一旦你已经选择了一种特定的方向，你就或多或少地依赖于它 - 它很难在走动后，一直sharded数据。

避免过早分片

切分最好采用分片后期。像过早的优化，分片的基础上增长数据的预期可能是一个灾难。分片实施的成功是基于一段时间内适当地了解数据增长的应用程序，并推断未来。一旦你sharded您的数据可能会极其难以走动。

一个策略的例子

由于分片结合你到一个线性数据模型（即，你不能轻易加入不同碎片的数据），你应该从你的数据清楚地了解每个组织碎片是将如何逻辑的。这通常是最容易由一个域的主节点成为重点。在一个电子商务系统的情况下，主节点可以是一个命令或一个客户。因此，如果你选择“客户”作为您的分片策略的基础，然后与客户的所有数据将被转移到各自的碎片，但你还是要选择哪些碎片去移动这些数据。

对客户来说，你可以根据位置碎片（欧洲，亚洲，非洲等），或者你可以在别的东西的碎片。这取决于你。您的碎片战略应当指出，纳入均匀分布的碎片之间的所有数据的一

些方法。分片整体的思路是，打破大套成小的数据，因此，如果某个特定电子商务领域有一个大的欧洲客户在设置和美国比较少，它可能不会基于意义的碎片对客户的位置。

回到比赛——使用切分！

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

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

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

实现Hibernate shards

Hibernate stards与现有的Hibernate项目几乎天衣无缝。唯一的缺点是，Hibernate的碎片需要一些具体资料和你的行为。也就是说，它需要一个碎片访问策略，碎片，选择策略，以及碎片，解决策略。这些接口，你必须执行，尽管在某些情况下，你可以使用默认的。我们将在后面的部分逐个了解各个接口。

ShardAccessStrategy

执行查询时，Hibernate Shards 需要一个决定首个切分、第二个切分及后续切分的机制。Hibernate Shards 无需确定查询什么（这是 Hibernate Core 和基础数据库需要做的），但是它确实意识到，在获得答案之前可能需要对多个切分进行查询。因此，Hibernate Shards 提供了两种极具创意的逻辑实现方法：一种方法是根据序列机制（一次一个）对切分进行查询，直到获得答案为止；另一种方法是并行访问策略，这种方法使用一个线程模型一次对所有切分进行查询。