本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 计算存储要求
<a name="bp-storage"></a>

大多数 OpenSearch 工作负载分为两大类之一：
+ **长效索引**：您编写的代码将数据处理为一个或多个 OpenSearch 索引，然后随着源数据的变化定期更新这些索引。一些常见示例为网站、文档和电子商务搜索。
+ **滚动索引**：数据持续流入一组具有索引周期和保留期限的临时索引，例如一组将保留 2 周的每日索引。一些常见示例是日志分析、时间序列处理和点击流分析。

对于长期有效的索引工作负载，您可以检查磁盘上的源数据并轻松确定它使用的存储空间。如果数据来自多个来源，只需一起添加这些来源。

对于滚动索引，您可以将代表性时间周期内生成的数据量乘以保留周期。例如，如果您每小时生成 200MiB 日志数据，即每天 4.7GiB，如果您的保留周期为 2 周，则任何给定时间的数据均为 66GiB。

但是，您的源数据的大小只是您的存储要求的一个方面。您还必须考虑以下方面：
+ **副本数量**：每个副本都是主分片的一个完整副本，索引的存储大小显示主分片和副本分片占用的大小。默认情况下，每个 OpenSearch 索引都有一个副本。我们建议至少具有一个，以防数据丢失。副本还可以提高搜索性能，因此如果您有需要进行大量读取操作的工作负载，则可能需要更多副本。使用 `PUT /my-index/_settings` 更新索引的 `number_of_replicas` 设置。
+ **OpenSearch 索引开销**：索引的磁盘大小各不相同。源数据加上索引的总大小通常为源数据的 110%，索引最多为源数据的 10%。为您的数据编制索引后，您可以使用 `_cat/indices?v` API 和 `pri.store.size` 值计算确切的开销。`_cat/allocation?v` 还提供了一个有用的摘要。
+ **操作系统预留空间**：默认情况下，Linux 将保留 5% 的文件系统供 `root` 用户处理关键流程、进行系统恢复和防止磁盘碎片问题。
+ **OpenSearch 服务开销**： OpenSearch 服务会为每个实例预留 20% 的存储空间（最多 20 GiB），用于分段合并、日志和其他内部操作。

  由于这个 20GiB 的最大值，预留空间的总量可能会相差悬殊，这具体取决于您的域中的实例数量。例如，某个域可能有三个 `m6g.xlarge.search` 实例，每个实例的存储空间为 500GiB，总存储空间为 1.46TiB。在这种情况下，只有 60GiB 的总预留空间。另一个域可能有 10 个 `m3.medium.search` 实例，每个实例的存储空间为 100GiB，总存储空间为 0.98TiB。在这里，总预留空间为 200GiB，即使第一个域大 50%。

  在以下公式中，我们对开销采用“最坏情况”估算值。该估算值包括额外的可用空间，可帮助最大限度地减少节点故障和可用区中断的影响。

总之，如果您在任何给定的时间有 66GiB 的数据并且需要一个副本，则*最低* 存储要求更接近 66 \$1 2 \$1 1.1 / 0.95 / 0.8 = 191GiB。您可以将此计算一般化，如下所示：

 **源数据 \$1（1 \$1 副本数量）\$1（1 \$1 索引开销）/（1-Linux 预留空间）/（1- OpenSearch 服务开销）= 最低存储要求**

或者，您可以使用此简化版本：

 **源数据 \$1（1 \$1 副本数量）\$1 1.45 = 最小存储要求**

存储空间不足是集群不稳定的最常见原因之一。所以，在[选择实例类型、实例数量和存储量](bp-instances.md)时，您应该交叉核对数字。

存在其他存储注意事项：
+ 如果您的最小存储要求超过 1 PB，请参阅 [Amazon 服务中的 PB 级规模 OpenSearch](petabyte-scale.md)。
+ 如果您有滚动索引并希望使用热-暖架构，请参阅 [UltraWarm 亚马逊 OpenSearch 服务的存储空间](ultrawarm.md)。