背景和原则
本文介绍云搜索服务实例规格资源预估方法，分为通用场景（如文本检索、日志分析等）场景和向量场景（向量存储和搜索），云搜索服务的主要资源为计算资源和存储资源，因此本文重点介绍计算资源和存储资源的预估，包括节点类型、节点规格、节点磁盘空间和节点数量等，实例的资源规格预估遵循以下原则：
- 如果您是从其他厂商或自建搬迁的客户，由于之前的规格是已经经过实际数据和场景的验证，建议直接复用原有 ES/OpenSearch 实例规格和容量，这样最为方便和实用。
- 索引的读写性能与索引 Mapping/Settings 元数据、数据特征、查询语句以及读写 QPS 等有关，因此 ES 资源预估无标准答案，建议您最好根据实际数据和业务场景，测试出适合您实际需求的实例规格和容量。
- 如果无法测试实际场景，您在第一次购买开通之后，强烈建议您对实例、索引、节点等指标进行告警配置，实时关注实例、索引、节点的运行状态，若出现资源不足的告警时，可以快速发现，及时升级到合适的实例规格，以防资源不足影响业务，具体告警指标参考 推荐配置的告警规则。
- 向量场景相比通用场景，需要更多的内存消耗，若预估内存空间不足，容易造成 OOM，强烈推荐以 CPU:内存=1:8 的数据节点规格（例如 4C32G）作为起始配置，存储类型则推荐使用 FlexPL 类型。
- 计算资源的预估的难度远大于存储空间的预估，但是根据火山云搜索服务的实际告警情况来看，磁盘空间更加容易出现容量不足的告警，因此存储空间更需要优先评估。
- 节点磁盘容量大小和节点内存大小具有一定的线性关系，如果有大容量的的磁盘存储需求，建议选择高内存规格的节点，这样可以保障实例的稳定性和性能，需要极力避免存在大量的低规格节点配套大容量磁盘存储的情况。
- 当实例状态正常，但是出现节点资源不足报警而需要扩容时，建议优先进行纵向的规格扩容，例如将节点扩容到 8核32GB 或 16核64GB 的规格（注：该操作会造成实例滚动重启，请在低峰期操作），然后再考虑横向扩容增加节点个数（该操作不会造成实例滚动重启）。
通用场景
适用场景分析
通用场景指的是云搜索服务常用的文本检索、日志分析等场景，通过近实时检索分析超大数据集的能力，配合Logstash/Kibana/Dashboards 等开源组件，以及云搜索自身的内核增强特性，快速构建日志分析、信息检索分析等实际业务。
计算资源预估
云搜索服务的计算资源主要用于在写入和查询，各类因素均会造成资源预估不准，本文提供两种预估思路。
根据业务数据的估算
- 日志类场景多属于写多读少型，计算资源主要用于写入，根据火山的测试数据，2C8G 的节点最大可支持 5000-10000 条日志/秒的写入，根据节点规格增长，基本上可以认为是线性的增长，例如 8C32G 节点可最大支持20000-40000 条日志/秒的写入，建议开始按最小值预估，后根据实际情况进行扩缩容。
- 日志场景若要实现超长时间（例如大于1个月）的存储，建议配置温节点、冷节点进行数据存储，配置数据的生命周期，可以显著降低存储成本，提升实例处理性能，具体参考利用 Data Streams 和 ISM 实现时序数据管理。
- 文本搜索场景如网站搜索、在线搜索场景，与日志场景相反，大多属于读多写少类型，计算资源主要用于查询，根据火山的经验，云搜索服务在不同的数据结构、不同的查询语法、不同的数据大小、不同的写入和查询 QPS 所需的资源均不一样，因此没有标准建议值，建议您实际数据和业务场景测试出适合您实际情况的实例规格和容量。
火山的配置经验值推荐
按照火山的经验值的推荐配置如下：
- 生产环境禁止使用单节点实例，单节点实例只适合测试场景。测试使用的单节点实例，如果需要转为正式生产使用，建议升配到 3 节点或以上。操作步骤，请参见升配实例。
- 实例最大节点的数量 = 单节点CPU核数 * 5，例如数据节点规格 16C128G，最大建议数据节点为 80个。
- 日志分析场景：单节点最大存储空间 = 单节点内存大小（GiB）* 50，例如数据节点规格 8C32G，那么磁盘空间建议为 1600GiB。
- 搜索场景：单节点最大存储空间 = 单节点内存大小（GiB）* 10，例如数据节点规格 16C32G，那么磁盘空间建议为 320GiB。
- 如果实例的数据节点大于一定数量，建议开启专有主节点，推荐配置如下：
- 超过10个数据节点的专有主节点规格建议：4C16G
- 超过30个数据节点的专有主节点规格建议：8C32G
- 超过50个数据节点的专有主节点规格建议：16C64G
- 如果您的查询写入较大，建议开启协调节点，将读写请求解耦，分担数据节点的压力，配置建议如下：
- 协调节点数量2个起步，协调节点建议选择 CPU:内存为 1:4 或 1:8 的规格
- 协调节点的数量与数据节点的数量比例，建议保持在 1:5 左右，协调节点的规格建议等于数据节点或高于数据节点，也可根据压测结果调整数量
- 例如 10个 8C32G 的数据节点，建议配置 2个 8C32G 的协调节点
- 如果需要启用温数据节点，建议温数据节点规格与数据节点规格保持一致或降低一半规格，也可以减少副本数降低存储空间，以节省存储成本。
- 例如有配置【8C32G+1000G】*20的数据节点，温数据节点建议配置为 【4C16G+1000G】*20
- 如果需要启用冷数据节点，建议冷数据节点的磁盘空间设置在 TOS 总存储容量的 10% - 20% 之间，若 TOS 存储空间持续增加，为了保证搜索的性能可用，可对节点数和存储规格进行对应的扩容。
- 冷节点数量 2 个起步，冷节点也比较耗费内存资源，只能选择 1:8 的规格
- 冷节点为一般日志场景时，冷节点的内存与磁盘空间的占比建议为 1:50
- 例如：冷数据存入 TOS 的量为 100TB，则建议冷节点的磁盘总空间为 20TB
- 冷节点的内存需求为 20TB/50=400GiB
- 冷节点配置建议为【8C64GB+磁盘 3200G】*7
分片数量预估和推荐
云搜索服务 ES /OpenSearch 的每个索引均被分为多个 Shard（分片），分片的数量会影响到读写性能和故障恢复的速度，分片数量修改难度也较大，所以需要提前设计，火山建议的分片数量预估和推荐如下：
- 因为分片过大，可能使云搜索服务的故障恢复速度变慢；由于每个分片使用一些数量的 CPU 和内存，分片过小可能导致非常多的分片，从而造成读写性能下降、内存空间不足等问题。
- 在规划阶段或测试阶段，可以根据您的业务需求、Index的大小、未来的增长预期，及时调整分片数量，以免后续频繁调整。
- 火山建议的单个分片大小保持在 10GiB - 50GiB 之间，建议 30GiB 或以下，可以根据数据大小计算分片个数；同时，建议单个节点上同一个索引的 Shard 个数不要超过 5个。
- 如果您实例的分片的数量超过数据节点数量，建议分片数量差不多是数据节点的整数倍，方便分片能够均匀分布在所有数据节点上。
- 例如您的实例有6个数据节点，当前的 Index 大小为 200GB，预期半年后增长 100%，如果每个单分片为30GB 计算，则大约需要 200GB ×（1 + 100%）/ 30 ≈ 14个分片，按这个分片数量，节点间压力相对不均匀，我们把分片数量调整到 18个。
- 单个节点上全部索引的 Shard 数量预估建议：
- 小规格实例的单个数据节点的分片数量 = 当前节点的内存大小 * 30，例如 4C16G，单个节点上所有索引的Shard 数量为 480个。
- 大小规格实例的单个数据节点的分片数量 = 当前节点的内存大小 * 50，例如 24C48G，单个节点上所有索引的 Shard 数量为 2400个。
- 分片和副本设置建议：
- 当数据量很大时，需要减少写入量的大小，降低 ES 压力，建议配置多个分片**。**
- 当数据量较小时，如果同时写入量也较小时，建议使用1主多副本或者1主1副本。
- 其他优化措施可以参考Bulk 定向路由、写入自适应优化。
存储资源预估
影响云搜索服务的节点的磁盘存储空间大小的因素主要包括：
- 原始数据的大小：需要存入到云搜索服务的数据量。
- 索引的副本数量：每个索引默认至少需要1个副本（副本的增加可以提升可靠性，但会增加存储成本）。
- 索引开销或膨胀：通常比原始数据的 10%。
- 实例的内部开销：段合并、Translog、日志等内部操作，需要预留 20%。
- 操作系统的预留：默认预留5%的空间，用于处理系统的恢复、关键的流程处理、防止磁盘的碎片化等。
- 存储的安全阈值：云搜索服务通常建议至少预留 15% 的安全阈值。
根据以上因素得到建议实例存储空间：
实际空间 = 原始数据×(1+副本数)×(1+索引开销或膨胀)/(1-实例内部开销)/(1-操作系统预留)/(1-存储安全阈值）
≈ 原始数据×(1+副本数)× 1.7
云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量为：
每个节点的存储容量 ≈ 原始数据×(1+副本数)× 1.7/ 节点数量
向量场景
适用场景分析
向量场景指的是云搜索服务提供的 OpenSearch 2.9 版本，支持向量和文本混合搜索，支持 DiskANN 算法、Hybrid DiskANN 算法或 HNSW 算法等多种算法，提供百亿级稳定快速的高效检索，配合豆包、DeepSeek 等大模型，快速构建 RAG、语义分析、以图搜图、多模态搜索等 AI 搜索的应用。
向量存储和向量检索对内存和磁盘的容量和性能非常敏感， 如果没有合理规划资源很容易导致整个集群 crash， 本文介绍向量存储的资源规划方法。
内存资源预估
由于向量存在内存中，不同的算法对内存均要求不一样，其中 DiskANN 算法的内存消耗更低，在超大规模场景下如 10 亿级向量以上更加经济化，以下是云搜索服务支持的各类算法的所需的内存计算。
Vamana 内存估算
Vamana 是 DiskANN 引擎的向量索引算法， 构图速度略慢于 HNSW，不过在相同召回率的前提下查询性能和成本均优于HNSW。
'''
* vector_size 单个向量大小， fp32=4, fp16=2, int8=1
* dimension是向量的维度
* m 是向量间指针的数量,默认32
* num_vectors 索引的数量
* 1.1 是预留10%作为图索引的临时空间
'''
storage_request = 1.1 * (vector_size * dimension + 8 * m) * num_vectors
HNSW 内存估算
HNSW 是广泛使用的向量索引算法，拥有速度快精度高的优点。
'''
vector_size: 单个向量大小， fp32=4, fp16=2, int8=1
dimension:是向量的维度
m: 是向量间指针的数量，默认32
num_vectors: 索引的数量
1.1 是预留10%作为图索引的临时空间
'''
storage_request = 1.1 * (vector_size * dimension + 8 * m) * num_vectors
IVF 内存估算
IVF 是一种成本较低的向量索引算法， 一般情况下召回率较低。
'''
vector_size: 单个向量大小， fp32=4, fp16=2, int8=1
dimension: 是向量的维度
num_vectors: 索引的数量
nlist: bucket（中心点）数量
1.1 是预留10%作为图索引的临时空间
'''
storage_request = 1.1 * ((vector_size * dimension * num_vectors) + (4 * nlist * dimension))
内存占用估算
由于云搜索服务的节点的内存还需要用于 JVM 或其他用途，以下是云搜索服务支持的各个算法分类后所需的节点的内存计算。
内存占比配置
# 向量内存占比默认50%，剩余的内存分配给jvm以及其他用途，可以根据实际需求进行配置
PUT _cluster/_settings
{
"persistent": {
"knn.memory.circuit_breaker.limit": "70%"
}
}
全内存模式
'''
计算内存需求
replica_number: 副本数量
storage_request： 向量存储占用计算得到的结果，计算方法参考内存资源预估
memory_limit: 内存占比配置的值换算为小数，例如50%换算为 0.5
1.5: 预留一些内存保证稳定性，可以按需调整
'''
memory_request = (1 + replica_number) * storage_request / memory_limit * 1.5
DiskANN 磁盘或者 Hybrid DiskANN 模式
# full_memory_request: 全内存计算出来的值
磁盘内存混合： memory_request = full_memory_request / 2
纯磁盘+默认配置: memory_request = full_memory_request / 3 （保守估计）
纯磁盘+参数优化： memory_request = full_memory_request / 6
云搜索服务为天然的分布式架构，内存空间为所有节点之和，每个节点的内存容量为：
每个节点的内存容量 ≈ 内存空间/ 节点数量
存储资源预估
参考通用场景的 1.7 倍的计算方法并考虑到向量场景对于磁盘容量的更高要求，例如 DiskANN 在磁盘上存储图结构的部分节点和边，因此存储上需要预留 2 倍的空间。
'''
vector_size: 单个向量大小， fp32=4, fp16=2, int8=1
dimension:是向量的维度
m: 是向量间指针的数量，默认32
num_vectors: 索引的数量
'''
存储空间 = 2.0 * (vector_size * dimension + 8 * m) * num_vectors * (1 + 副本数)
云搜索服务为天然的分布式架构，存储空间为所有节点之和，每个节点的存储容量为：
每个节点的存储容量 ≈ 存储空间/ 节点数量