本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon OpenSearch 服务的成本优化技术
以下是在使用 Amazon OpenSearch 服务时优化成本的一些最常用的技术，包括托管集群和无服务器。由于每种工作负载都是独一无二的，因此请根据您的特定使用模式评估这些策略，并在测试环境中对其进行验证，然后再应用于生产。
亚马逊 OpenSearch 服务托管集群的成本优化
派生来源-跳过存储 _source 字段
Derived Source 是一项存储优化功能，可消除存储_source字段的开销：
-
OpenSearch 将每个摄取的文档存储两次：一次存储在
_source字段（原始文档）中，另一次作为索引字段进行搜索。 -
仅该
_source字段就可能占用大量存储空间，通常占索引存储总量的 30-50%。 -
使用 Derived Source，您可以跳过存储，
_source而是在需要时（在搜索、获取、mget、重新索引或更新操作期间）从索引字段动态重建索引字段。 -
这是可选的，在使用复合索引设置创建索引时启用。
-
在支持 OpenSearch 3.1 或更高版本的所有地区均可用。
最适合：分析和日志工作负载，您无需频繁检索原始原始文档，但仍需要通过字段进行搜索和聚合。
OR1 / OR2 / OM2 实例 — OpenSearch 经过优化的实例系列
OR1 而较新的 OR2 和 OM2 实例则通过分段复制使用 Amazon S3 作为副本存储：
-
OR2：索引吞吐量比 R7g 实例高出 26% OR1，比 R7g 实例高 70%。
-
OM2：索引吞吐量比 m7g 实例高出 15% OR1，比 m7g 实例高 66%。
-
两者都使用相同的架构：本地 EBS 用于主存储，S3 用于持久性。
-
消除了副本存储成本 — 副本存储在 S3 中（11 9 的耐久性），而不是昂贵的 EBS 卷。
-
与上一代实例相比，性价比最高可提高 30%。
-
支持浅层快照 v2 — 近乎即时的快照，没有 I/O 开销。
最适合：索引密集型运营分析和日志分析工作负载。
有关更多信息，请参阅OR2 和新增 OM2 内容公告
索引汇总 — 汇总历史时间序列数据
索引汇总汇总较旧的时间序列数据并将其压缩为更粗略的时间间隔，从而大大减少了存储量：
-
IoT/Sensor 数据：将最近一段时间的每秒数据保存在热存储中；将较旧的数据汇总到每小时或每日摘要。
-
系统指标：保留最近 30 天的详细指标；将较早的数据汇总为每小时或每日摘要。
-
日志数据：保留活动故障排除窗口的完整详细信息（例如，1 周）；保留较早时期的汇总错误模式。
-
与 ISM 策略相结合，在单个生命周期策略中自动执行汇总和分层迁移。
-
从几秒钟到几小时，而不是从几秒钟到几分钟，节省的费用更大。
有关更多信息，请参阅索引汇总博客文章
索引状态管理 — 自动化整个数据生命周期
ISM 策略可以自动在存储层和生命周期操作中移动索引：
-
自动迁移索引：根据时 UltraWarm 长、大小或文档数量自动迁移索引：从热到冷再删除。
-
在层过渡之前触发汇总以减少数据量。
-
设置展期策略（例如，当索引达到 50 GB 或已存在 30 天时）以控制索引增长。
-
自动强制合并只读索引，以从已删除的文档中回收存储空间。
-
与汇总相结合，最大限度地节省大型时间序列数据集的费用。
预留实例 — 承诺享受可预测的折扣
对于稳定、可预测的分析工作负载，预留实例比按需定价提供大幅折扣：
-
1 年或 3 年期承诺期限，包括无预付款、部分预付或全额预付付款选项。
-
最适合连续运行的热层数据节点和专用主节点。
-
在承诺之前，使用 AWS 定价计算器估算节省的费用。
-
预留实例是适用于按需实例的账单折扣，无需更改基础架构。
适当调整实例类型和数量
来自 Well-Ar OpenSearch chitected 镜头的关键指导和正确调整规模的最佳实践：
-
始终使用最新一代的实例（例如，与基于 Graviton2 的实例相比，Graviton3 实例的性能最多可提高 25%）。
-
使用 gp3 EBS 卷代替 gp2，性能更好，成本更低，无需额外付费。
-
将实例类型与工作负载相匹配：针对搜索密集型进行了内存优化，针对索引密集型进行了计算优化。
-
评估专用集群管理器节点：仅需要 3 个或更多数据节点；避免过度配置主节点大小。
-
监控 CloudWatch 指标以检测过度配置：CPU 持续低于 40%、JVM 低于 50%、存储空间低于 50% 是浪费的迹象。
-
最佳范围：CPU 60—80%，JVM 65-85%，存储 70—85%，用于持续工作负载。
有关更多信息，请参阅 “调整大小最佳实践” 博客文章
分片优化 — 避免过度分片
过度分片是一个隐藏的成本驱动因素 — 太多的小分片会浪费 CPU、内存和 JVM 堆：
-
建议的分片大小：每个分片 10—50 GiB，具体取决于工作负载。
-
每 GiB 的 Java 堆不超过 25 个分片，每个数据节点不超过 1,000 个分片。
-
使用 ISM 展期策略来控制指数增长，避免分片的无限扩散。
-
在耐久性允许的情况下减少副本数量（OR1/OR2 实例完全消除了对副本的需求）。
-
对只读索引使用强制合并以减少段数并回收存储空间。
有关更多信息，请参阅我需要多少分片？
Zero-ETL /使用 Amazon S3 直接查询
对于很少被查询但必须保持可访问的数据，直接查询（S3 为零 ETL）允许直接从中查询 S3 数据， OpenSearch 而无需提取数据：
-
没有摄取成本 — 数据保留在 S3 中。
-
存档数据没有热层存储成本。
-
Pay-per-query 计算模型。
-
支持用于可视化的 OpenSearch 仪表板。
-
几秒或几分钟的延迟是可以接受的，但不适用于实时用例。
摄取时采样和压缩
在数据到达之前就降低成本 OpenSearch：
-
采样：仅摄取高容量日志流的代表性子集（例如，调试日志的 10%）。
-
索引压缩：启用最佳压缩编解码器以减少存储占用。
-
字段筛选：在索引之前删除高基数、低值字段（例如，旧日志的原始堆栈跟踪）。
-
保留策略：定义符合合规要求的最大保留期限，切勿无限期地存储数据。
避免延长支持成本 — 及时了解最新的发动机版本
Amazon S OpenSearch ervice 对扩展支持中的引擎版本按标准化实例小时数收取固定费用：
-
继续使用不支持的旧版本除了实例成本之外还会产生额外费用。
-
升级到当前支持的版本以免产生扩展支持费用。
成本分配标签和 CloudWatch 监控
积极的成本管理可防止浪费：
-
将成本分配标签应用于 OpenSearch 域，以便对每个团队或工作负载进行详细的成本跟踪。
-
设置存储利用率、JVM 压力和 CPU CloudWatch 警报，尽早发现过度配置。
-
使用 C AWS ost Explorer 来识别利用率一直较低的域名。
-
评估自动调整 — 自动调整 JVM 堆大小和其他设置，以提高性能并减少资源浪费。
亚马逊 OpenSearch 服务无服务器的成本优化
磁盘优化的矢量搜索（矢量集合）
磁盘优化的矢量搜索是矢量工作负载中最强大的成本降低技术之一。它仅将压缩向量保留在 RAM 中并将全精度向量存储在磁盘上，从而运行矢量搜索的成本仅为内存模式的一小部分。
工作原理：
-
在标准 (
in_memory) 模式下，完整的 HNSW 图会加载到 RAM 中，这在规模上会变得非常昂贵。 -
在
on_disk模式下，仅在内存中保留压缩（量化）向量以用于候选生成；仅在最后的重新评分阶段（两阶段搜索）从磁盘中检索全精度向量。 -
这大大降低了 RAM 需求，同时保持了较高的搜索质量。
-
默认
on_disk模式使用 32 倍的二进制量化，与内存模式相比，内存需求降低了 97%。 -
支持压缩级别：2x (FP16)、4x（字节）、8x、16x、32x（二进制）。
-
P90 延迟在 100—200 毫秒范围内，适用于不需要个位数毫秒响应时间的工作负载。
成本节约基准：
| 数据集 | 回想一下 @100 | P90 延迟 | 减少成本 |
|---|---|---|---|
| Cohere TREC-RAG | 0.94 | 104 毫秒 | 83% |
| Tasb-1M | 0.96 | 7ms | 67% |
| Marco-1M | 0.99 | 7ms | 67% |
最适合：RAG 管道、语义搜索、文档检索以及任何可接受 P90 延迟 100—200 毫秒且优先考虑降低成本的矢量工作负载。
注意
要将此更改应用于现有的索引数据，您需要重新编制索引。您可以使用外部管道工具，例如将数据重新索引到新索引中。
有关更多信息，请参阅磁盘优化的矢量搜索博客文章
矢量自动优化（矢量集合）
Auto-Optimize 会自动评估向量索引配置，并建议在搜索质量、延迟和内存成本之间进行权衡的最佳权衡，而无需矢量专业知识：
-
不到一小时即可提供优化建议。
-
与矢量摄取管道集成。
-
可以与十亿级向量数据库的 GPU 加速索引结合使用。
有关更多信息，请参阅自动优化博客文章
GPU 加速向量索引（向量集合）
GPU 加速将 HNSW 向量索引转移到无服务器 GPUs，从而大大减少了构建大型向量索引的时间和 OCU 成本：
-
与仅使用 CPU 的索引相比，索引构建时间快 6.4 倍到 13.8 倍。
-
对于写入密集型矢量工作负载，索引 OCU 成本最多可降低 75%。
-
GPUs 是动态连接的 — 只有在 GPU 加速处于活动状态 OCUs 时，您才需要付费。
-
允许在一小时内构建十亿级矢量数据库。
-
按矢量加速度单独收费 OCUs。
最适合：大规模的初始向量摄取或频繁的模型再训练场景，其中重建索引的成本很高。
有关更多信息，请参阅 GPU 加速博客文章
设置最大 OCU 限制（所有集合类型）
Amazon Serv OpenSearch ice 无服务器可 OCUs 根据需求自动扩展。如果没有上限，成本可能会意外飙升。在账户级别或每个集合组设置最大 OCU 限制，以防止失控的扩展。在峰值负载期间，系统会扩展到此极限，但不会超过该限制。
允许的值：
-
账户等级：不超过 1,700 的任意值 OCUs （不限于 16 的倍数）。
-
集合组：1、2、4、8、16 和 16 的倍数，最多 1,69 OCUs 6。
监控 CloudWatch 指标 (OCUUtilization)，以便在一段时间内调整最大 OCU 设置的大小。
注意
如果利用率达到 OCU 的最大上限，即使成本得到控制，性能也可能会显著降低。达到上限并不能解决 OCU 峰值的根本原因。对于向量集合，根本原因通常是内存中的向量，应通过优化向量索引、减小索引大小或调整召回率和精度权衡来直接解决这个问题。
提示
从保守的最大 OCU 开始，只有在持续利用率接近上限时 CloudWatch 才增加。如果您一直达到上限，请调查根本原因，尤其是向量集合的内存中向量使用情况，而不仅仅是提高限制。
有关更多信息，请参阅 管理 Amazon OpenSearch Serverless 的容量限制。
优化保留期（时间序列馆藏）
数据生命周期策略会在指定的保留期后自动从时间序列集合中删除数据，从而防止无限的存储增长。只有时间序列集合支持数据生命周期策略，搜索和矢量集合不支持。
时间序列集合的 OCU 计数直接取决于必须在本地存储中保存多少最新数据。时间序列集合仅将最新部分的数据保留在本地 OCU 存储中；较旧的数据会转移到 S3，并且相应地缩放数量 OCUs ：
OCUs required = max（最小值 OCUs， OCUs 需要在保留期限内保存数据）
配置数据生命周期策略：
-
将每个索引或索引模式的保留期从 24 小时设置为 3,650 天。
-
Amazon Serv OpenSearch ice Service Serverless 会尽力自动删除数据（通常在 48 小时或保留期的 10% 内）。
-
规则可以应用于集合级别、索引模式级别或单个索引级别，更具体的规则优先。
尺码示例：
-
1 次提 TiB/day 取，保留期为 30 天 = 大约 1 TiB 的热门数据 = 20 OCUs 用于索引 + 20 用于搜索。 OCUs
-
缩短到 7 天的保留期 = 大约 233 GiB 的热门数据 = 索引大约 OCUs 4 个 + 用于搜索 OCUs 4 个。
更短的保留期意味着本地存储中的热数据更少， OCUs 所需的数据更少，计算费用也更低。使保留期与实际业务和合规要求保持一致 — 默认情况下不要无限期保留数据。
有关更多信息，请参阅 在 Amazon OpenSearch Serverless 中使用数据生命周期策略。
避免存储不必要的数据（所有集合类型）
减少直接摄取的数据量可以降低计算 (OCUs) 和存储成本：
-
提取时筛选字段：使用管道在低值字段到达集合之前将其删除。
-
避免摄取重复或冗余数据：在管道级别执行重复数据删除。
-
使用适当的索引映射：对已存储但从未搜索过的字段禁用索引 (
"index": false)。 -
对于搜索集合：避免存储大型二进制 blob 或原始文本，因为这会使存储空间膨胀而没有搜索价值。
多租户工作负载的集合组（所有集合类型）
集合组允许具有不同 KMS 密钥的多个集合在同一安全边界内共享 OCU 资源，从而大大降低了多租户架构的成本。适用于每个租户或每个集合使用多个 KMS 密钥的客户：
-
以前，每个唯一的 KMS 密钥都需要专用 OCUs ，这使得每个租户的隔离成本高得令人望而却步。
-
通过集合组，拥有单独加密密钥的租户可以共享 OCU 容量。
-
对于大量较小的租户工作负载，最多可节省 90% 的成本。
-
支持最小值 OCUs （保证基准，无冷启动）和最大值 OCUs（成本上限）。
-
具有不同网络访问类型（公共和 VPC）的集合可以共存于同一个组中。
-
CloudWatch 指标为每个组提供了对资源消耗和延迟情况的可见性。
最适合：SaaS 提供商、多租户平台或任何包含许多小型集合的工作负载，每个集合都需要自己的 KMS 密钥。
有关更多信息，请参阅 “馆藏组” 博客文章
