存在以下问题：
-
但是，系统将最终达到上限，而在给定服务器上无法轻松地增加存储容量。
-
使用单个服务器托管数据存储无法提供支持此负载所需的计算能力，从而因应用程序存储和检索数据超时而导致用户和频发故障的响应时间延长。可以添加内存或升级处理器，但在无法增加更多的任何计算资源时，表示系统已达到上限。
-
网络流量可能会超过用于连接到服务器的网络容量，从而导致请求失败。
-
如果用户分布在不同的国家/地区或区域，它可能无法在单个数据存储中存储应用程序的全部数据。
能够支持大量用户和大量数据的水平分区能够接近无限缩放，因此垂直缩放并不一定是最佳解决方案。
解决此需求的方案是什么？
这样可存储和访问大量数据时提高可伸缩性。
在不同的服务器上作为存储节点运行。
此模式具有以下优点：
-
通过添加在其他存储节点上运行的更多分片，可以向外扩展系统。
-
系统可以为每个存储节点使用现成的硬件，而不是专用且昂贵的计算机。
-
通过在分片间平衡工作负荷可减少争用并提高性能。
-
在设计时应考虑分片可位于靠近将访问数据的用户的位置。
它不应基于可能会更改的数据。
可以将此分片逻辑实现为应用程序中数据访问代码的一部分，或者它以一种更透明方式支持分片，则可由数据存储系统中间实现它。
权衡是在确定每个数据项被检索时的位置所需的附加数据访问开销。
若要处理这些情况，请使用支持最常执行的查询的分片键实现分片策略。
或者如索引模式（例如索引表）来提供针对基于分片键未覆盖属性的数据的快速查找。
分片策略
策略包括：
多个货主可以共享同一分片，但是单个货主的数据不会分布于多个分片中。
无需修改应用程序代码，虚拟分片和物理分区之间的映射既可以更改为使用一组不同的分片键。
下一个图说明了分片中数据的存储顺序集（范围）。
受范围查询支配并需要组合在一起的项可以使用具有同一分区键值的分片键，但行键值是唯一的。
下一个图采用多货方委托三方物流企业管理仓库情景所使用的仓储系统来说明了基于货主 ID 哈希的分片货主数据。
上图展示了为货主 55 和 56 分发负载的过程。
者三个分片策略的优势和注意事项如下：
-
查找分片位置会产生额外开销。
-
如果大多数活动适用于毗邻的分片键，则重新平衡分片很困难并且可能无法解析负载不均的问题。
-
此外，重新平衡分片会很困难。
例如，在多货主应用程序中：
-
因此，可能会提高其他货主的数据访问速度。
-
可以脱机获取特定地理区域中的货主的数据，以便在该区域的非高峰时段进行备份和维护，而其他区域中的货主的数据保持在线并可在其工作时间访问。
-
为高值货主分配他们自己的私有、高性能、负载较轻的分片，而低值货主可能分享排列更密集的、繁忙的分片。
-
需要高度数据隔离和隐私的货主的数据可以存储在完全独立的服务器上。
缩放和数据移动操作
每个分片策略表示用于管理缩小、扩大、数据移动和维护状态的不同能力和复杂性水平。
查找策略要求高度可缓存及可友好复制的状态。
范围策略还可能需要维护一些状态，以便将范围映射到物理分区。
但是，哈希策略不需要状态维护。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
-
有关分区的详细信息
-
还应开发可以在必要时用于快速重新平衡分片的策略和脚本。
-
相反，查找不变的或自然形成键的属性。
-
在某些系统中，自动递增字段无法跨分片进行协调，从而可能会导致不同分片中的项具有相同分片键。
例如，如果使用自动递增字段生成唯一 ID，则位于不同分片中的两个不同项可能会分配有相同 ID。
-
。
-
请考虑使非规范化数据以便将经常查询的相关实体（如客户和他们已下订单的详细信息）一起保留在相同分区中，从而减少应用程序执行的单独读取数。
这可以帮助提高跨分片引用相关数据的查询的性能。
-
但是，此方法不可避免地会在一定程度上增加解决方案数据访问逻辑的复杂性。
-
移动小分片比移动大分片更快。
-
确保每个分片存储节点的可用资源充足，在数据大小和吞吐量方面可以应对可伸缩性要求。
-
应用程序随后可以方便地提取所有数据进行查询，而不必对单独的数据存储进行额外往返。
如果执行此操作，应将应用程序设计为能够处理它。
-
有关实施最终一致性的详细信息，请参阅数据一致性入门。
-
这些任务可能使用脚本或其他自动化解决方案来实现，但是这可能无法完全消除额外的管理要求。
-
此方法可以显著提高性能，但是需要额外考虑必须访问不同位置的多个分片的任务。