OpenSearch资源使用说明

从OpenSearch历史发展来看，OpenSearch诞生的初衷是为了更高效的全文检索功能，为了更快的检索，OpenSearch会尽可能地把倒排索引相关的元数据常驻在JVM Heap中，这种追求高效检索的模式意味着OpenSearch会占用更多的内存。一个包含Master节点与Data节点的OpenSearch集群，Data节点写入数据的过程同时也伴随着倒排索引、FST等元数据的创建，写入的数据量越大，对应的元数据也会越大。元数据由Master持有并由Master分发与管理，因此一个存储海量数据的OpenSearch集群需要同时为Data与Master节点配置足够的内存。

如下会从容量规划与控制分片数量两个方面阐述OpenSearch集群需要关注的点。

容量规划

新接入的OpenSearch集群，需要根据数据量预先评估好节点配置和集群规模，可以从如下几个方面进行评估：

• 存储容量：需要考虑数据膨胀、是否引入副本、OpenSearch内部任务额外占用的空间。如果再需要预留50%的空闲磁盘空间，则集群总体的存储容量大约为源数据量的3~4倍；
• 计算资源：通常2核8GB的节点能够支持5000qps的写入，随着节点数量和节点规格的提升，写入能力基本呈线性增长；
• 索引容量：一个Shard的数据量控制在30~50GB为宜，则索引的容量大约为分片数量*（30~50GB）。1GB堆内存支持20~30个分片（一般1TB的数据至少需要1GB堆内存来支撑）。

控制集群整体分片数量

集群分片数量的大小往往决定着元数据的大小，集群元数据由Master管理，也决定着Master的节点性能。所以集群整体的分片数量不建议过多，主要原因如下：

• 过多的分片数量会带来集群元数据的增大，这部分数据常驻在堆内存old区，且不会被GC掉；
• 节点扩容的场景中，需要进行分片搬迁的操作，以此来保持数据在节点间的均衡。此时搬迁的任务会变得比较慢且会导致Master节点不能及时响应索引新建或者更新mapping的任务，最终导致写入失败；
• 分片数量最好不要超过3w，主要的原因是元数据太大会导致Master节点JVM内存使用率过高，GC频繁，影响性能；

实践过程来看，3w个分片在32GB堆内存的Master上，堆内存使用率可以稳定在50~60%，Master能够稳定且高效的工作.