将数据存储划分为一组水平分区或碎片。在存储和访问大量数据时，这可以提高可伸缩性。

上下文和问题

由单个服务器托管的数据存储可能受到以下限制：

• 储存空间。大型云应用程序的数据存储预计将包含大量数据，这些数据可能会随着时间的推移而显着增加。服务器通常仅提供有限数量的磁盘存储，但是您可以将现有磁盘替换为较大的磁盘，或者随着数据量的增长将更多磁盘添加到计算机中。但是，系统终将达到无法轻松增加给定服务器上存储容量的极限。
• 计算资源。需要云应用程序来支持大量并发用户，每个并发用户都运行查询以从数据存储中检索信息。承载数据存储的单个服务器可能无法提供必要的计算能力来支持此负载，从而导致用户的响应时间延长，并且在应用程序尝试存储和检索数据的过程中超时，导致频繁出现故障。可能可以添加内存或升级处理器，但是当无法进一步增加计算资源时，系统将达到极限。
• 网络带宽。终，在单个服务器上运行的数据存储的性能取决于服务器可以接收请求和发送答复的速率。网络通信量可能会超过用于连接服务器的网络容量，从而导致请求失败。
• 地理。出于法律，法规遵从或性能方面的原因，可能有必要将特定用户所生成的数据存储在与这些用户相同的区域中，或者减少数据访问的延迟。如果用户分散在不同的国家或地区，则可能无法将应用程序的全部数据存储在单个数据存储中。

通过增加磁盘容量，处理能力，内存和网络连接来垂直扩展可能会延迟其中一些限制的影响，但这可能只是一个临时解决方案。能够支持大量用户和大量数据的商业云应用程序必须能够无限期地扩展，因此垂直扩展不一定是佳的解决方案。

解

将数据存储划分为水平分区或碎片。每个分片都具有相同的架构，但是拥有自己的独特数据子集。分片本身就是一个数据存储（它可以包含许多不同类型实体的数据），并在充当存储节点的服务器上运行。

此模式具有以下优点：

• 您可以通过添加在其他存储节点上运行的其他分片来扩展系统。
• 系统可以为每个存储节点使用现成的硬件，而不是专用且昂贵的计算机。
• 您可以通过平衡分片之间的工作负载来减少争用并提高性能。
• 在云中，分片可以物理上靠近将访问数据的用户。

将数据存储划分为分片时，请确定应在每个分片中放置哪些数据。分片通常包含落入由数据的一个或多个属性确定的指定范围内的项目。这些属性形成分片键（有时称为分区键）。分片密钥应为静态。它不应基于可能更改的数据。

分片以物理方式组织数据。当应用程序存储和检索数据时，分片逻辑会将应用程序定向到适当的分片。该分片逻辑可以作为应用程序中数据访问代码的一部分实现，或者，如果透明地支持分片，则可以由数据存储系统实现。

在分片逻辑中抽象数据的物理位置提供了对哪些分片包含哪些数据的高度控制。如果以后需要重新分配分片中的数据（例如，如果分片变得不平衡），它还使数据能够在分片之间迁移而无需重新设计应用程序的业务逻辑。折衷方案是确定每个数据项在检索时的位置时所需的额外数据访问开销。

为了确保佳性能和可伸缩性，以适合应用程序执行的查询类型的方式拆分数据非常重要。在许多情况下，分片方案不太可能完全符合每个查询的要求。例如，在多租户系统中，应用程序可能需要使用租户ID来检索租户数据，但它可能还需要基于其他属性（例如，租户的名称或位置）来查找此数据。要处理这些情况，请使用支持常执行的查询的分片键实施分片策略。

如果查询使用属性值的组合定期检索数据，则可以通过将属性链接在一起来定义复合分片键。或者，使用索引表之类的模式基于分片键未涵盖的属性提供对数据的快速查找。

分片策略

选择分片密钥并决定如何在分片之间分配数据时，通常使用三种策略。请注意，分片与托管它们的服务器之间不必一一对应，一台服务器可以托管多个分片。这些策略是：

查找策略。在这种策略中，分片逻辑实现一个映射，该映射使用分片密钥将对数据的请求路由到包含该数据的分片。在多租户应用程序中，可以使用租户ID作为分片密钥将一个租户的所有数据一起存储在一个分片中。多个租户可能共享同一分片，但是单个租户的数据不会分散在多个分片上。该图说明了基于租户ID的租户数据分片。

分片密钥和物理存储之间的映射可以基于物理分片，其中每个分片密钥都映射到物理分区。替代地，用于重新分配分片的更灵活的技术是虚拟分区，其中分片键映射到相同数量的虚拟分片，而虚拟分片又映射到更少的物理分区。在这种方法中，应用程序使用引用虚拟分片的分片密钥来定位数据，并且系统透明地将虚拟分片映射到物理分区。虚拟分片和物理分区之间的映射可以更改，而无需修改应用程序代码以使用不同的分片密钥集。

范围策略。此策略将相关项目分组在同一分片中，并按分片键对它们进行排序-分片键是顺序的。这对于经常使用范围查询（为特定范围内的分片键返回一组数据项的查询）的应用程序很有用。例如，如果应用程序定期需要查找给定月份中下的所有订单，则如果一个月中的所有订单都以日期和时间顺序存储在同一分片中，则可以更快地检索此数据。如果每个订单存储在不同的分片中，则必须通过执行大量的点查询（返回单个数据项的查询）来分别获取它们。下图说明了将数据的顺序集（范围）存储在分片中。

在此示例中，分片键是一个复合键，其中包含订单月份为重要的元素，后跟订单日期和时间。创建新订单并将其添加到分片时，订单数据自然会进行排序。某些数据存储支持由两部分组成的分片键，其中包含用于标识该分片的分区键元素和用于标识该分片中项目的行键。数据通常以行键顺序保存在分片中。需要进行范围查询且需要分组的项目可以使用分片键，该分片的分区键值相同，而行键的值。

哈希策略。此策略的目的是减少热点（分担负载量不成比例的碎片）的机会。它将数据分布在各个分片上，从而在每个分片的大小和每个分片将遇到的平均负载之间取得平衡。分片逻辑基于数据的一个或多个属性的散列来计算用于存储项目的分片。选择的散列函数应该通过在计算中引入一些随机元素，将数据均匀地分布在各个分片上。下图说明了基于租户ID散列的租户数据分片。

要了解哈希策略相对于其他分片策略的优势，请考虑按顺序注册新租户的多租户应用程序如何将租户分配给数据存储区中的分片。使用范围策略时，租户1到n的数据将全部存储在分片A中，租户n + 1到m的数据将全部存储在分片B中，依此类推。如果近注册的租户也是活跃的，则大多数数据活动将发生在少数碎片中，这可能会引起热点。相比之下，哈希策略根据租户ID的哈希将租户分配给分片。这意味着顺序的租户有可能被分配给不同的分片，这将在他们之间分配负载。上图显示了租户55和56的情况。

三种分片策略具有以下优点和注意事项：

• 查找。这样可以更好地控制分片的配置和使用方式。使用虚拟分片可减少重新平衡数据时的影响，因为可以添加新的物理分区来均衡工作量。可以修改虚拟分片与实现分片的物理分区之间的映射，而不会影响使用分片密钥存储和检索数据的应用程序代码。查找分片位置可能会带来额外的开销。
• 范围。这很容易实现并且可以很好地与范围查询一起使用，因为它们通常可以在单个操作中从单个碎片中获取多个数据项。此策略可简化数据管理。例如，如果同一区域中的用户位于同一分片中，则可以根据本地负载和需求模式在每个时区中计划更新。但是，此策略无法在分片之间提供佳平衡。重新分配碎片很困难，并且如果大多数活动是用于相邻的碎片密钥，则可能无法解决负载不均的问题。
• 哈希。此策略提供了更均匀的数据和负载分配的机会。可以使用哈希函数直接完成请求路由。无需维护地图。请注意，计算散列可能会带来额外的开销。而且，重新分配碎片很困难。

大多数常见的分片系统都实现了上述方法之一，但是您还应该考虑应用程序的业务需求及其数据使用模式。例如，在多租户应用程序中：

• 您可以根据工作负载分片数据。您可以将易变租户的数据隔离在单独的分片中。结果，可以提高其他租户的数据访问速度。
• 您可以根据租户的位置来分片数据。您可以使特定地理区域的租户的数据脱机，以在该区域的非高峰时间进行备份和维护，而其他区域的租户的数据则保持在线并在其工作时间内可以访问。
• 可以为高价值的租户分配他们自己的私有，高性能，轻负载的碎片，而低价值的租户则可以共享更密集，繁忙的碎片。
• 需要高度数据隔离和隐私的租户数据可以存储在完全独立的服务器上。

扩展和数据移动操作

每种分片策略都暗含不同的功能和复杂度，用于管理横向扩展，横向扩展，数据移动和维护状态。

查找策略允许在联机或脱机的用户级别上执行缩放和数据移动操作。该技术是暂停某些或所有用户活动（可能在非高峰时段），将数据移至新的虚拟分区或物理碎片，更改映射，使保存此数据的所有缓存或刷新，然后允许用户活动恢复。通常，可以对这种类型的操作进行集中管理。查找策略要求状态具有高度可缓存性和副本友好性。

范围策略对缩放和数据移动操作施加了一些限制，通常必须在部分或全部数据存储脱机时执行这些限制，因为必须在各个分片上拆分和合并数据。如果大多数活动是用于相邻分片密钥或相同范围内的数据标识符，则将数据移动到重新平衡分片可能无法解决负载不均衡的问题。范围策略可能还需要维护一些状态才能将范围映射到物理分区。

哈希策略使扩展和数据移动操作变得更加复杂，因为分区键是分片键或数据标识符的哈希。每个分片的新位置必须从哈希函数确定，或者必须修改该函数以提供正确的映射。但是，哈希策略不需要维护状态。

问题与注意事项

在决定如何实现此模式时，请考虑以下几点：

• 分片是其他形式分区的补充，例如垂直分区和功能分区。例如，单个分片可以包含已垂直划分的实体，而功能分区可以实现为多个分片。有关分区的更多信息，请参阅《数据分区指南》。
• 使碎片保持平衡，以便它们都处理相似量的I / O。在插入和删除数据时，有必要定期重新调整碎片以确保分布均匀并减少出现热点的机会。重新平衡可能是一项昂贵的操作。为了减少重新平衡的必要性，请通过确保每个碎片包含足够的可用空间来处理预期的更改量来计划增长。如果必要，您还应该开发可用于快速重新平衡分片的策略和脚本。
• 使用稳定的数据作为分片密钥。如果分片键更改，则相应的数据项可能必须在分片之间移动，从而增加了更新操作执行的工作量。因此，请避免将分片密钥基于潜在易失的信息。而是查找不变的或自然形成键的属性。
• 确保分片键是的。例如，避免使用自动递增字段作为分片键。在某些系统中，无法在分片之间协调自动递增的字段，这可能导致不同分片中的项目具有相同的分片密钥。
  不是分片键的其他字段中的自动递增值也会引起问题。例如，如果您使用自动递增的字段来生成的ID，则位于不同分片中的两个不同项可能会被分配相同的ID。
• 设计与每个可能查询的数据相匹配的分片键可能是不可能的。对数据进行分片以支持频繁执行的查询，并在必要时创建辅助索引表以支持使用基于不属于分片键的属性的条件检索数据的查询。有关更多信息，请参见索引表模式。
• 仅访问单个分片的查询比从多个分片中检索数据的查询更有效，因此请避免实施分片系统，以免导致应用程序执行大量查询，这些查询将不同分片中包含的数据进行合并。请记住，一个分片可以包含多种类型的实体的数据。考虑对数据进行规范化处理，以将通常一起查询的相关实体（例如客户的详细信息以及他们下的订单）保留在同一碎片中，以减少应用程序执行的单独读取的次数。
  如果一个分片中的实体引用存储在另一个分片中的实体，则将第二个实体的分片密钥包括为个实体的架构的一部分。这可以帮助提高引用跨碎片相关数据的查询的性能。
• 如果应用程序必须执行查询以从多个分片中检索数据，则可以通过使用并行任务来获取此数据。例如扇出查询，其中并行检索来自多个分片的数据，然后将其聚合为单个结果。但是，这种方法不可避免地给解决方案的数据访问逻辑增加了一些复杂性。
• 对于许多应用程序，创建大量小碎片可能比拥有少量大碎片更有效，因为它们可以提供更多的负载平衡机会。如果您预计需要将碎片从一个物理位置迁移到另一个物理位置，这也可能很有用。移动小碎片比移动大碎片更快。
• 确保每个分片存储节点可用的资源足以满足数据大小和吞吐量方面的可伸缩性要求。有关更多信息，请参见《数据分区指南》中的“设计可伸缩性分区”部分。
• 考虑将参考数据复制到所有分片。如果从分片中检索数据的操作在同一查询中还引用了静态或移动缓慢的数据，请将此数据添加到分片中。然后，应用程序可以轻松获取查询的所有数据，而不必进行到单独数据存储的额外往返操作。
  如果多个分片中保存的参考数据发生更改，则系统必须在所有分片中同步这些更改。在发生此同步时，系统可能会遇到一定程度的不一致。如果这样做，则应将应用程序设计为能够处理它。
• 维护分片之间的参照完整性和一致性可能很困难，因此您应该小化影响多个分片中数据的操作。如果应用程序必须跨分片修改数据，请评估是否实际需要完整的数据一致性。相反，云中的通用方法是实现终的一致性。每个分区中的数据将分别进行更新，并且应用程序逻辑必须负责确保所有更新均成功完成，并负责处理在运行终一致的操作时由于查询数据而引起的不一致情况。有关实现终一致性的更多信息，请参见Data Consistency Primer。
• 配置和管理大量分片可能是一个挑战。诸如监视，备份，一致性检查以及日志记录或审计之类的任务必须在可能位于多个位置的多个分片和服务器上完成。这些任务可能使用脚本或其他自动化解决方案来实现，但可能无法完全消除其他管理要求。
• 可以对分片进行地理定位，以便它们包含的数据与使用它的应用程序实例接近。这种方法可以显着提高性能，但是对于必须访问不同位置的多个分片的任务，需要额外考虑。