计算存储要求 - 亚马逊 OpenSearch 服务
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

计算存储要求

大多数 OpenSearch 工作负载分为两大类之一:

  • 长效索引:您编写的代码将数据处理为一个或多个 OpenSearch 索引,然后随着源数据的变化定期更新这些索引。一些常见示例为网站、文档和电子商务搜索。

  • 滚动索引:数据持续流入一组具有索引周期和保留期限的临时索引,例如一组将保留 2 周的每日索引。一些常见示例是日志分析、时间序列处理和点击流分析。

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

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

但是,您的源数据的大小只是您的存储要求的一个方面。您还必须考虑以下方面:

  • 副本数量:每个副本都是主分片的一个完整副本,索引的存储大小显示主分片和副本分片占用的大小。默认情况下,每个 OpenSearch 索引都有一个副本。我们建议至少具有一个,以防数据丢失。副本还可以提高搜索性能,因此如果您有需要进行大量读取操作的工作负载,则可能需要更多副本。使用 PUT /my-index/_settings 更新索引的 number_of_replicas 设置。

  • OpenSearch 索引开销:索引的磁盘大小各不相同。源数据加上索引的总大小通常为源数据的 110%,索引最多为源数据的 10%。为数据编制索引后,您可以使用_cat/indices?vAPI和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 * 2 * 1.1 / 0.95 / 0.8 = 191GiB。您可以将此计算一般化,如下所示:

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

或者,您可以使用此简化版本:

源数据 *(1 + 副本数量)* 1.45 = 最小存储要求

存储空间不足是集群不稳定的最常见原因之一。所以,在选择实例类型、实例数量和存储量时,您应该交叉核对数字。

存在其他存储注意事项: