本文将分别从通用场景（如文本检索、日志分析）和向量场景（向量存储与向量搜索）两个维度，介绍云搜索服务实例规格的资源预估方法。云搜索服务的核心资源为计算和存储，本文将重点说明这两类资源的预估方法，包括节点类型、节点规格、节点磁盘空间及节点数量等配置维度。 ## 背景和原则实例的资源规格预估遵循以下原则： * 如果您是从其他厂商或自建环境迁移的用户，由于原有实例规格已在实际数据规模和业务场景中得到验证，建议优先复用原有的 Elasticsearch 或OpenSearch 实例规格和容量配置，以降低迁移成本并提升部署效率。 * 索引的读写性能受多种因素影响，包括索引的 Mapping 和 Settings 元数据、数据特征、查询语句复杂度以及读写 QPS 等。因此，Elasticsearch 资源规格的预估不存在统一的标准答案。建议结合实际数据规模和业务场景进行测试，以确定符合实际需求的实例规格和容量。 * 在无法对真实业务场景进行充分测试的情况下，首次购买并开通实例后，强烈建议为实例、索引和节点等关键指标配置告警规则，持续监控运行状态。当出现资源不足相关告警时，可以及时发现并快速将实例升级至合适的规格，以避免资源瓶颈对业务产生影响。具体告警指标可参考[推荐配置的告警规则](/docs/6465/1219834)。 * 向量检索场景相比通用检索场景对内存资源的消耗更高。若内存预估不足，容易引发 OOM 问题。强烈建议以 CPU:内存 = 1:8 的数据节点规格（例如 4 核 32 GiB）作为初始配置，同时推荐使用 FlexPL 类型的存储。 * 计算资源的预估难度通常高于存储空间的预估。但根据火山引擎云搜索服务的实际告警情况来看，磁盘空间更容易触发容量不足告警，因此在资源规划时应优先对存储空间进行评估。 * 节点磁盘容量与节点内存规格之间存在一定的线性关系。在存在大容量磁盘存储需求的情况下，建议选择高内存规格的节点，以保障实例的稳定性和整体性能，应尽量避免使用大量低规格节点搭配大容量磁盘的配置方式。 * 当实例整体状态正常，但因节点资源不足触发告警而需要扩容时，建议优先进行纵向规格扩容，例如将节点升级至 8 核 32 GiB 或 16 核 64 GiB 的规格（该操作会触发实例滚动重启，请在业务低峰期执行），随后再根据需要考虑通过横向扩容增加节点数量（该操作不会触发实例滚动重启）。云搜索服务还提供资源计算器功能，您可以基于提供的实验数据了解资源规模的估算方法，并根据测试结果在实际部署过程中进行相应调整。详细信息，请参见[资源计算器](https://www.volcengine.com/docs/6465/2183188)。 ## 通用场景 ### 场景介绍通用场景指的是云搜索服务常用的文本检索、日志分析等场景，通过近实时检索分析超大数据集的能力，配合 Logstash/Kibana/Dashboards 等开源组件，以及云搜索自身的内核增强特性，快速构建日志分析、信息检索分析等实际业务。 ### 计算资源预估云搜索服务的计算资源主要用于数据写入和查询过程。由于影响计算资源消耗的因素较多，资源预估往往存在一定不确定性。本文提供两种计算资源的预估思路，供 ```mixin-react return ( ); ``` ### 分片数量预估和推荐云搜索服务实例中，每个索引都会被划分为多个分片。分片数量直接影响索引的读写性能以及故障恢复速度，而分片数量在索引创建后修改成本较高，因此需要在规划阶段提前设计。火山引擎对分片数量的预估和配置建议如下： * 分片过大会导致故障恢复时间变长；而由于每个分片都会占用一定的 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 定向路由](/docs/6465/1249513)和[写入自适应优化](/docs/6465/1472225)。 ### 存储资源预估影响云搜索服务的节点的磁盘存储空间大小的因素主要包括： * 原始数据的大小：需要存入到云搜索服务的数据量。 * 索引的副本数量：每个索引默认至少需要 1 个副本（副本的增加可以提升可靠性，但会增加存储成本）。 * 索引开销或膨胀：通常比原始数据的 10%。 * 实例的内部开销：段合并、Translog、日志等内部操作，需要预留 20%。 * 操作系统的预留：默认预留 5% 的空间，用于处理系统的恢复、关键的流程处理、防止磁盘的碎片化等。 * 存储的安全阈值：云搜索服务通常建议至少预留 15% 的安全阈值。根据以上因素得到建议实例存储空间： ```Plain Text 实际空间 = 原始数据 × (1 + 副本数) × (1 + 索引开销或膨胀) / (1 - 实例内部开销) / (1 - 操作系统预留) / (1 - 存储安全阈值） ≈ 原始数据 × (1 + 副本数) × 1.7 ``` 云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量为： ```Plain Text 每个节点的存储容量 ≈ 原始数据 × (1 + 副本数) × 1.7 / 节点数量 ``` ## 向量场景 ### 适用场景分析向量场景指的是云搜索服务提供的 OpenSearch 2.9 版本，支持向量和文本混合搜索，支持 DiskANN 算法、Hybrid DiskANN 算法或 HNSW 算法等多种算法，提供百亿级稳定快速的高效检索，配合豆包、DeepSeek 等大模型，快速构建 RAG、语义分析、以图搜图、多模态搜索等 AI 搜索的应用。向量存储和向量检索对内存和磁盘的容量和性能非常敏感，如果没有合理规划资源很容易导致整个集群 crash，本文介绍向量存储的资源规划方法。 ### 内存资源预估由于向量存在内存中，不同的算法对内存均要求不一样，其中 DiskANN 算法的内存消耗更低，在超大规模场景下如 10 亿级向量以上更加经济化，以下是云搜索服务支持的各类算法的所需的内存计算。 **Vamana 内存估算** Vamana 是 DiskANN 引擎的向量索引算法，构图速度略慢于 HNSW，不过在相同召回率的前提下查询性能和成本均优于 HNSW。 ```Plain Text vector_size：单个向量大小，fp32=4，fp16=2，int8=1，单位为 Byte。 dimension：向量的维度 m：向量间指针的数量，默认 32 num_vectors：索引的数量 1.1：预留 10% 作为图索引的临时空间 storage_request = 1.1 * (vector_size * dimension + 8 * m) * num_vectors ``` **HNSW 内存估算** HNSW 是广泛使用的向量索引算法，拥有速度快精度高的优点。 ```Plain Text vector_size：单个向量大小，fp32=4，fp16=2，int8=1，单位为 Byte。 dimension：向量的维度 m：向量间指针的数量，默认 32 num_vectors：索引的数量 1.1：预留 10% 作为图索引的临时空间 storage_request = 1.1 * (vector_size * dimension + 8 * m) * num_vectors ``` **IVF 内存估算** IVF 是一种成本较低的向量索引算法，一般情况下召回率较低。 ```Plain Text ''' vector_size：单个向量大小，fp32=4，fp16=2，int8=1，单位为 Byte。 dimension：向量的维度 num_vectors：索引的数量 nlist：bucket（中心点）数量 1.1：预留 10% 作为图索引的临时空间 ''' storage_request = 1.1 * ((vector_size * dimension * num_vectors) + (4 * nlist * dimension)) ``` ### 内存占用估算由于云搜索服务的节点的内存还需要用于 JVM 或其他用途，以下是云搜索服务支持的各个算法分类后所需的节点的内存计算。 **内存占比配置** ```HTTP # 向量内存占比默认50%，剩余的内存分配给 JVM 以及其他用途，可以根据实际需求进行配置 PUT _cluster/_settings { "persistent": { "knn.memory.circuit_breaker.limit": "70%" } } ``` ### 向量内存占用估算 ```Plain Text 计算向量内存需求 replica_number：副本数量 storage_request：向量存储占用计算得到的结果，计算方法参考内存资源预估 vector_memory_request = (1 + replica_number) * storage_request ``` #### 全内存模式 ```Plain Text 计算内存需求 vector_memory_request：向量的内存空间需求 heap_memory：堆内存，32 GiB(含)以下占比 50%，32 GiB(不含）以上固定 31 GiB 1.5：预留一些内存来存放cache、程序以及其他内存开销保证稳定性，可以按需调整 memory_request = (vector_memory_request + heap_memory) * 1.5 ``` #### DiskANN 磁盘或 Hybrid DiskANN 模式 ```Plain Text 计算内存需求 vector_memory_request：向量的内存空间需求 heap_memory：堆内存，32 GiB(含)以下占比 50%，32 GiB（不含）以上固定 31 GiB 1.5：预留一些内存来存放 cache、程序以及其他内存开销保证稳定性，可以按需调整磁盘内存混合：memory_request = (vector_memory_request / 2 + heap_memory) * 1.5 纯磁盘+默认配置：memory_request = （vector_memory_request / 3 + heap_memory) * 1.5 （保守估计）纯磁盘+参数优化：memory_request = （vector_memory_request / 6 + heap_memory) * 1.5 ``` 云搜索服务为天然的分布式架构，内存空间为所有节点之和，每个节点的内存容量为： ```Plain Text 每个节点的内存容量 ≈ 内存空间/ 节点数量 ``` ### 存储资源预估参考通用场景的 1.7 倍的计算方法并考虑到向量场景对于磁盘容量的更高要求，例如 DiskANN 在磁盘上存储图结构的部分节点和边，因此存储上需要预留 2 倍的空间。 ```Plain Text vector_size：单个向量大小，fp32=4，fp16=2，int8=1，单位为 Byte。 dimension：向量的维度 m：向量间指针的数量，默认 32 num_vectors：索引的数量存储空间 = 2.0 * (vector_size * dimension + 8 * m) * num_vectors * (1 + 副本数) ``` 云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量如下所示。 ```Plain Text 每个节点的存储容量 ≈ 存储空间/ 节点数量 ```