本文将分别从通用场景（如文本检索、日志分析）和向量场景（向量存储与向量搜索）两个维度，介绍云搜索服务实例规格的资源预估方法。云搜索服务的核心资源为计算和存储，本文将重点说明这两类资源的预估方法，包括节点类型、节点规格、节点磁盘空间及节点数量等配置维度。

背景和原则

实例的资源规格预估遵循以下原则：

如果您是从其他厂商或自建环境迁移的用户，由于原有实例规格已在实际数据规模和业务场景中得到验证，建议优先复用原有的 Elasticsearch 或OpenSearch 实例规格和容量配置，以降低迁移成本并提升部署效率。

索引的读写性能受多种因素影响，包括索引的 Mapping 和 Settings 元数据、数据特征、查询语句复杂度以及读写 QPS 等。因此，Elasticsearch 资源规格的预估不存在统一的标准答案。建议结合实际数据规模和业务场景进行测试，以确定符合实际需求的实例规格和容量。

在无法对真实业务场景进行充分测试的情况下，首次购买并开通实例后，强烈建议为实例、索引和节点等关键指标配置告警规则，持续监控运行状态。当出现资源不足相关告警时，可以及时发现并快速将实例升级至合适的规格，以避免资源瓶颈对业务产生影响。具体告警指标可参考推荐配置的告警规则。

向量检索场景相比通用检索场景对内存资源的消耗更高。若内存预估不足，容易引发 OOM 问题。强烈建议以 CPU:内存 = 1:8 的数据节点规格（例如 4 核 32 GiB）作为初始配置，同时推荐使用 FlexPL 类型的存储。

计算资源的预估难度通常高于存储空间的预估。但根据火山引擎云搜索服务的实际告警情况来看，磁盘空间更容易触发容量不足告警，因此在资源规划时应优先对存储空间进行评估。

节点磁盘容量与节点内存规格之间存在一定的线性关系。在存在大容量磁盘存储需求的情况下，建议选择高内存规格的节点，以保障实例的稳定性和整体性能，应尽量避免使用大量低规格节点搭配大容量磁盘的配置方式。

当实例整体状态正常，但因节点资源不足触发告警而需要扩容时，建议优先进行纵向规格扩容，例如将节点升级至 8 核 32 GiB 或 16 核 64 GiB 的规格（该操作会触发实例滚动重启，请在业务低峰期执行），随后再根据需要考虑通过横向扩容增加节点数量（该操作不会触发实例滚动重启）。

云搜索服务还提供资源计算器功能，您可以基于提供的实验数据了解资源规模的估算方法，并根据测试结果在实际部署过程中进行相应调整。详细信息，请参见资源计算器。

通用场景

场景介绍

通用场景指的是云搜索服务常用的文本检索、日志分析等场景，通过近实时检索分析超大数据集的能力，配合 Logstash/Kibana/Dashboards 等开源组件，以及云搜索自身的内核增强特性，快速构建日志分析、信息检索分析等实际业务。

计算资源预估

云搜索服务的计算资源主要用于数据写入和查询过程。由于影响计算资源消耗的因素较多，资源预估往往存在一定不确定性。本文提供两种计算资源的预估思路，供

根据业务数据的估算

火山引擎的配置经验值推荐

日志类场景通常属于写多读少的业务类型，计算资源主要消耗在写入阶段。根据火山引擎的测试数据，2 核 8 GiB 的节点在日志写入场景下，单节点最大可支持约 5000～10000 条日志/秒的写入。随着节点规格的提升，写入能力基本呈线性增长。例如，8 核 32 GiBBB 的节点最大可支持约 20000~40000 条日志/秒的写入。建议在初始规划时按照区间下限进行预估，并在实例运行过程中根据实际负载情况进行弹性扩缩容。

在日志场景中，如需实现超长时间（例如超过 1 个月）的数据存储，建议配置温节点和冷节点，并结合数据生命周期管理策略进行数据分层存储。通过合理配置数据生命周期，可以在显著降低存储成本的同时提升实例整体处理性能。具体配置方法可参考利用 Data Streams 和 ISM 实现时序数据管理。

文本搜索场景（如网站搜索、在线搜索等）与日志场景不同，通常属于读多写少的业务类型，计算资源主要用于查询处理。根据火山引擎的实践经验，不同的数据结构、查询语法、数据规模以及写入和查询 QPS，对资源的消耗差异较大，因此不存在统一的推荐规格。建议您基于实际数据规模和业务场景进行测试，以确定适合自身需求的实例规格和容量。

生产环境禁止使用单节点实例。单节点实例仅适用于测试场景。测试使用的单节点实例如需转为正式生产环境，建议升级至 3 节点或以上规格。具体操作步骤请参见《升配实例》。

实例最大节点数量的推荐计算方式为：实例最大节点数 = 单节点 CPU 核数 × 5。例如，当数据节点规格为 16 核 128 GiB 时，建议最大数据节点数量为 80 个。

日志分析场景下，单节点最大存储空间的推荐计算方式为：单节点最大存储空间 = 单节点内存大小（GiB）× 50。例如，当数据节点规格为 8 核 32 GiB 时，建议磁盘空间为 1600 GiB。

搜索场景下，单节点最大存储空间的推荐计算方式为：单节点最大存储空间 = 单节点内存大小（GiB）× 10。例如，当数据节点规格为 16 核 32 GiB 时，建议磁盘空间为 320 GiB。

当实例中的数据节点数量达到一定规模时，建议启用专有主节点，推荐配置如下：

数据节点数量超过 10 个时，专有主节点建议规格为 4 核 16 GiB

数据节点数量超过 30 个时，专有主节点建议规格为 8 核 32 GiB

数据节点数量超过 50 个时，专有主节点建议规格为 16 核 64 GiB

当查询或写入压力较大时，建议启用协调节点，以解耦读写请求并分担数据节点压力，推荐配置如下：

协调节点数量建议从 2 个起步，规格建议选择 CPU:内存为 1:4 或 1:8

协调节点与数据节点的数量比例建议保持在约 1:5，协调节点规格建议不低于数据节点规格，也可根据压测结果进行调整

例如，当实例中包含 10 个 8 核 32 GiB 的数据节点时，建议配置 2 个 8 核 32 GiB 的协调节点

如需启用温数据节点，建议温数据节点规格与数据节点规格保持一致，或降低至数据节点规格的一半。同时，也可以通过减少副本数的方式降低存储空间占用，以节省存储成本。例如，当数据节点配置为 (8 核 32 GiB + 1000 GiB) × 20 时，温数据节点建议配置为 (4 核 16 GiB + 1000 GiB) × 20。

如需启用冷数据节点，建议冷数据节点的磁盘空间设置为 TOS 总存储容量的 10%～20%。当 TOS 存储空间持续增长时，为保障搜索性能和可用性，可相应扩容冷节点的数量或存储规格。

冷节点数量建议从 2 个起步

冷节点对内存资源消耗较高，仅支持选择 CPU:内存为 1:8 的规格

在通用日志场景下，冷节点的内存与磁盘空间占比建议为 1:50

例如，当冷数据存入 TOS 的数据量为 100 TB 时，建议冷节点的磁盘总容量为 20 TB，对应的内存需求约为 400 GiB。此时，冷节点可参考配置为 (8 核 64 GiB + 3200 GiB 磁盘) × 7。

分片数量预估和推荐

云搜索服务实例中，每个索引都会被划分为多个分片。分片数量直接影响索引的读写性能以及故障恢复速度，而分片数量在索引创建后修改成本较高，因此需要在规划阶段提前设计。火山引擎对分片数量的预估和配置建议如下：

分片过大会导致故障恢复时间变长；而由于每个分片都会占用一定的 CPU 和内存资源，分片过小则可能产生过多分片，从而引发读写性能下降、内存资源不足等问题。

在规划阶段或测试阶段，建议根据业务需求、索引数据规模以及未来的数据增长预期，对分片数量进行合理规划和调整，以避免在生产阶段频繁变更分片配置。

火山引擎建议单个分片的大小控制在 10～50 GiB 之间，推荐 30 GiB 或以下。可根据索引的数据总量计算所需的分片数量。同时，建议在单个数据节点上，同一个索引的分片数量不超过 5 个。

当实例中的分片总数大于数据节点数量时，建议将分片数量设置为数据节点数量的整数倍，以便分片能够均匀分布在各个数据节点上，提升整体资源利用率。

例如，实例中包含 6 个数据节点，当前索引大小为 200 GiB，且预计在半年内数据量增长 100%。若按照单个分片 30 GiB 进行规划，则所需分片数量约为：200 GiB × (1 + 100%) ÷ 30 ≈ 14 个分片。在该分片数量下，分片在节点间分布不均衡。为提升负载均衡效果，建议将分片数量调整为 18 个。

单个节点分片数量预估建议：

对于小规格实例，单个数据节点上全部索引的分片数量建议值为：单节点分片数 = 节点内存大小（GiB）× 30。例如，节点规格为 4 核 16 GiB，则单个节点上全部索引的分片数量建议不超过 480 个。

对于大规格实例，单个数据节点上全部索引的分片数量建议值为：单节点分片数 = 节点内存大小（GiB）× 50。例如，节点规格为 24 核 48 GiB，则单个节点上全部索引的分片数量建议不超过 2400 个。

分片和副本设置建议：

当数据量较大、写入压力较高时，为降低单分片写入压力并提升并发能力，建议配置多个分片。

当数据量较小且写入压力不高时，建议采用一主多副本或一主一副本的配置方式，以提升数据可靠性和查询性能。

其他写入和分片优化措施，可参考 Bulk 定向路由和写入自适应优化。

存储资源预估

影响云搜索服务的节点的磁盘存储空间大小的因素主要包括：

原始数据的大小：需要存入到云搜索服务的数据量。

索引的副本数量：每个索引默认至少需要 1 个副本（副本的增加可以提升可靠性，但会增加存储成本）。

索引开销或膨胀：通常比原始数据的 10%。

实例的内部开销：段合并、Translog、日志等内部操作，需要预留 20%。

操作系统的预留：默认预留 5% 的空间，用于处理系统的恢复、关键的流程处理、防止磁盘的碎片化等。

存储的安全阈值：云搜索服务通常建议至少预留 15% 的安全阈值。

根据以上因素得到建议实例存储空间：

云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量为：

向量场景

适用场景分析

向量场景指的是云搜索服务提供的 OpenSearch 2.9 版本，支持向量和文本混合搜索，支持 DiskANN 算法、Hybrid DiskANN 算法或 HNSW 算法等多种算法，提供百亿级稳定快速的高效检索，配合豆包、DeepSeek 等大模型，快速构建 RAG、语义分析、以图搜图、多模态搜索等应用。

向量存储和向量检索对内存和磁盘的容量和性能非常敏感，如果没有合理规划资源很容易导致整个集群 crash，本文介绍向量存储的资源规划方法。

内存资源预估

由于向量存在内存中，不同的算法对内存均要求不一样，其中 DiskANN 算法的内存消耗更低，在超大规模场景下如 10 亿级向量以上更加经济化，以下是云搜索服务支持的各类算法的所需的内存计算。

Vamana 内存估算

Vamana 是 DiskANN 引擎的向量索引算法，构图速度略慢于 HNSW，不过在相同召回率的前提下查询性能和成本均优于 HNSW。

HNSW 内存估算

HNSW 是广泛使用的向量索引算法，拥有速度快精度高的优点。

IVF 内存估算

IVF 是一种成本较低的向量索引算法，一般情况下召回率较低。

内存占用估算

由于云搜索服务的节点的内存还需要用于 JVM 或其他用途，以下是云搜索服务支持的各个算法分类后所需的节点的内存计算。

内存占比配置

向量内存占用估算

全内存模式

DiskANN 磁盘或 Hybrid DiskANN 模式

云搜索服务为天然的分布式架构，内存空间为所有节点之和，每个节点的内存容量为：

存储资源预估

参考通用场景的 1.7 倍的计算方法并考虑到向量场景对于磁盘容量的更高要求，例如 DiskANN 在磁盘上存储图结构的部分节点和边，因此存储上需要预留 2 倍的空间。

云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量如下所示。