将数据存储划分为一组水平分区或分片。这可以提高存储和访问大量数据时的可扩展性。

背景

数据存储可能会受到以下限制：

• 储存空间。服务器通常只提供有限数量的磁盘存储，但可以用更大的磁盘替换现有磁盘，或者随着数据量的增长向机器添加更多磁盘。然而，系统最终会达到一个极限，即不可能轻易地增加服务器上的存储容量。
• 计算资源。数据存储的单个服务器可能无法提供必要的计算能力来支持此负载，从而导致用户响应时间延长，并且由于尝试存储和检索数据的应用程序超时而经常出现故障。可能可以添加内存或升级处理器，但当无法进一步增加计算资源时，系统将达到极限。
• 网络带宽。最终，在单个服务器上运行的数据存储的性能取决于服务器接收请求和发送回复的速率。网络流量可能会超过用于连接服务器的网络容量，从而导致请求失败。
• 地理。出于法律、合规性或性能原因，或者为了减少数据访问的延迟，可能需要将特定用户生成的数据存储在与这些用户相同的区域中。如果用户分散在不同的国家或地区，则可能无法将应用程序的全部数据存储在单个数据存储中。

• 
  

通过增加更多磁盘容量、处理能力、内存和网络连接来垂直扩展只是一个临时解决方案。

解决方案

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

这种模式有以下好处：

• 可以通过添加在其他存储节点上运行的更多分片来扩展系统。

• 可以通过平衡分片之间的工作负载来减少争用并提高性能。
• 分片可以位于物理上靠近将访问数据的用户。

将数据存储划分为分片时，决定哪些数据应放置在每个分片中。分片通常包含落在由数据的一个或多个属性确定的指定范围内的项目。

分片对数据进行物理组织。当应用程序存储和检索数据时，分片逻辑将应用程序定向到适当的分片。

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

分片策略

在选择分片键和决定如何跨分片分布数据时，通常使用三种策略。策略是：

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

分片键和物理存储之间的映射可以基于物理分片，其中每个分片键映射到一个物理分区。或者，用于重新平衡分片的更灵活的技术是虚拟分区，其中分片键映射到相同数量的虚拟分片，而虚拟分片又映射到更少的物理分区。

范围策略。该策略将相关项目组合在同一个分片中，并按分片键对它们进行排序——分片键是顺序的。它对于经常使用范围查询（返回给定范围内的分片键的一组数据项的查询）检索项目集的应用程序很有用。

例如，如果应用程序需要定期查找给定月份的所有订单，如果一个月的所有订单都以日期和时间顺序存储在同一分片中，则可以更快地检索此数据。如果每个订单都存储在不同的分片中，则必须通过执行大量点查询（返回单个数据项的查询）来单独获取它们。

下图说明了在分片中存储数据的顺序集（范围）。

哈希策略。此策略的目的是减少热点（接收不成比例负载的分片）的机会。它以在每个分片的大小和每个分片将遇到的平均负载之间实现平衡的方式在分片之间分配数据。分片逻辑基于数据的一个或多个属性的散列计算存储项目的分片。选择的散列函数应该在分片上均匀分布数据，可能通过在计算中引入一些随机元素。

下图说明了基于租户 ID 散列的租户数据分片。

要了解哈希策略相对于其他分片策略的优势，请考虑按顺序注册新租户的多租户应用程序如何将租户分配到数据存储中的分片。使用 Range 策略时，租户 1 到 n 的数据将全部存储在 shard A 中，租户 n+1 到 m 的数据将全部存储在 shard B 中，以此类推。如果最近注册的租户也是最活跃的，那么大部分数据活动将发生在少数分片中，这可能会导致热点。

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

• 查找。这提供了对分片配置和使用方式的更多控制。使用虚拟分片可以减少重新平衡数据时的影响，因为可以添加新的物理分区来平衡工作负载。可以修改虚拟分片和实现分片的物理分区之间的映射，而不会影响使用分片键存储和检索数据的应用程序代码。
• 范围。这很容易实现并且适用于范围查询，因为它们通常可以在单个操作中从单个分片中获取多个数据项。此策略提供了更轻松的数据管理。

例如，如果同一区域的用户在同一个分片中，则可以根据本地负载和需求模式在每个时区安排更新。然而，这种策略并不能提供分片之间的最佳平衡。如果大部分活动是针对相邻的分片键，重新平衡分片很困难，并且可能无法解决负载不均的问题。

• 哈希。这种策略提供了更均匀的数据和负载分布的更好机会。请求路由可以直接使用散列函数来完成。

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

• 可以根据工作负载对数据进行分片。可以将高度不稳定的租户的数据隔离在单独的分片中。
• 可以根据租户的位置对数据进行分片。可以将特定地理区域的租户的数据在该区域的非高峰时段离线备份和维护，而其他区域的租户的数据在其工作时间保持在线并可访问。
• 可以为高价值租户分配他们自己的私有、高性能、轻负载分片，而低价值租户可能会被期望共享更密集、更繁忙的分片。
• 需要高度数据隔离和隐私的租户的数据可以存储在完全独立的服务器上。

考虑

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

• 分片是对其他形式的分区的补充，例如垂直分区和功能分区。
• 保持分片平衡，以便它们都处理相似量的 I/O。随着数据的插入和删除，需要定期重新平衡分片以保证分布均匀并减少热点的机会。再平衡可能是一项昂贵的操作。为了减少重新平衡的必要性，通过确保每个分片包含足够的可用空间来处理预期的更改量来规划增长。如果有必要，还应该开发可用于快速重新平衡分片的策略和脚本。
• 使用确定的条件作为分片键。如果分片键更改，相应的数据项可能必须在分片之间移动，从而增加更新操作执行的工作量。

• 可能无法设计一个与针对数据的每个可能查询的要求相匹配的分片键。对数据进行分片以支持最常执行的查询，并在必要时创建二级索引表以支持使用基于不属于分片键的属性的条件检索数据的查询。

• 如果应用程序必须执行从多个分片检索数据的查询，则可以通过使用并行任务来获取这些数据。

• 配置和管理大量分片可能是一项挑战。监控、备份、检查一致性以及日志记录或审计等任务必须在多个分片和服务器上完成，这些分片和服务器可能位于多个位置。

何时使用此模式

当数据存储可能需要扩展到单个存储节点可用的资源之外，或者通过减少数据存储中的争用来提高性能时，请使用此模式。