大数据，大模型，服务器，技术、架构，方案

Elasticsearch读写性能优化与负面清单。

这些活动的性能特征是每个主节点合格节点上存储的速度以及选举主节点和集群中其他节点之间的网络互连的可靠性和延迟的函数。因此，你必须确保你的集群中的节点拥有足够的存储和网络，以满足你的性能目标。随着集群的增长，特别是如果你有大型机器学习作业或持续的 transforms，考虑将专用的主节点从专用的数据节点、机器学习节点和 transform 节点中分离出来。一个小的或轻负载的集群如果其主节点合格节点拥有其他角色和职责，可能会运行良好，但一旦你的集群包含超过少数节点，通常使用专用主节点合格节点是有意义的。

针对Elasticsearch的向量检索性能调优需要综合考虑并发处理、存储选择、分片策略以及I/O调度器等多个方面。通过合理的配置和优化，可以显著提升ES的查询效率和响应速度，从而满足实际应用中的高性能需求。我们观察到在HDD环境下，将搜索并发提高至40后，QPS相较于默认设置提升了23倍。尤为显著的是，通过段合并策略，性能提升幅度从原本的20%扩大至惊人的380%，这充分展现了段合并技术的巨大优势。

ann-benchamrk 是一个用于评估近似最近邻（ANN）搜索库的性能测试工具，这个本是最佳选择，但是也由于需要 pip 安装几十个依赖和 docker 构建十分麻烦，且详细的教程介绍太少，最后还是选择 esrally 进行性能测试，这个也是 ES 官方博客所使用的。本文包含ESrally的git失败各种疑难杂症、数据离线的准备、测试命令、测试结果的解读等等

通过之前的系列文章，整个ES搜索文件的流程与大的问题已经统统扫除了，既然是全栈流程，是不能缺少前端查询页面的，前端需简单实现一个用户输入查询关键词句，发起搜索，页面以表格形式展示查询的结果，额外可以提供文件的预览或下载操作。1. 实现ES检索pdf等文件内容的插件2. 基于GitBucket的Hook构建ES检索PDF等文档全栈方案3. Java实现读取转码写入ES4. ES文件搜索的细节优化与实现5. ES解析word内容为空的问题和直接使用Tika解析文档的方案。

JVM G1GC（Garbage-First Garbage Collector）是Java虚拟机中的一种垃圾收集器，它以高吞吐量和可预测的停顿时间为目标，特别适合需要大内存和多核处理器的服务器应用。初始堆大小（-Xms）和最大堆大小（-Xmx）根据应用的内存需求设定这两个值，以确保应用在启动和运行过程中有足够的内存资源。通常建议将-Xms和-Xmx设置为相同的值，以减少运行时堆内存的动态调整，从而降低额外的性能开销。具体数值依赖于应用的具体需求，可以通过性能测试来确定合适的值。

从写入机制考虑，应该原始索引有存量数据才对性能有影响，我们追加写入1000万数据进行验证，且使用随机生成的uuid。这是虚拟机环境的模拟，具体计算指定ID对性能的影响是复杂的，因为它取决于上述多个因素以及你的软硬件环境。2000万到3000万：程序耗时1904.99秒；索引累计耗时2026秒。3000万到4000万：程序耗时1904.99秒；4000万到5000万：程序耗时1904.99秒；3000万到4000万：程序耗时1497.03秒；最终通过ES查询索引元数据观察到索引操作累计耗时是1215秒。

之前已简单使用ES及Kibana和在线转Base64工具实现了检索文档的demo，预期建设方案是使用触发器类型从公共的文档源拉取最新的文件，然后调用Java将文件转Base64后入ES建索引，再提供封装接口给前端做查询之用。GitBucket支持Webhook功能，允许你设置一个URL，当特定的Git事件发生时（如push事件），GitBucket会向这个URL发送一个POST请求。由于全部内容过长，为了便于阅读，按照大的章节分为三部分，第一部分讲述基于WebHook的触发机制怎么搭建，包含全部实现细节！

使用git hook实时监控触发，或者直接简单使用定时任务从文件源下载pdf、word、md等格式的文档，使用java将文档内容转成Base64格式，仿照上面的思路方法写入ES，就可实现全文搜索了，搜索到的文档可以返回文档的在线下载地址，可以直接打开或下载，完成闭环。使用上述网站只能转换点小文件（也可能是浏览器的问题），我转了一个10页的PPT后页面无响应，无法拷贝结果。随后我转了一个更小PDF，可复制结果，发现字符数也有41万之多。首先，我们需要保证ES已经有中文分词器ik插件，这里不再赘述。

众所周知，在Elasticsearch中，一旦索引的分片数（shard count）在创建索引时设定，就不能直接修改。需要注意的是这三种方案只有集群扩容是原索引和原业务无感知的操作，其余的方案本质都是生成新的索引而已。以上步骤中，只有2、3、5是必须执行的，第一步执行一次后无需再执行，其他操作均为观察情况。停止业务写入后，使用命令关闭指定索引的写入开关，如这里是关闭test01。需要换成要扩增的索引的名字，不是新索引的名。是新索引的名称，需要自己指定。第一，是旧索引分片的整数倍。

在实际业务开始前应充分评估当前集群的状态和未来的增长趋势，但是由于没有做好容量规划与评估，没有设计灵活的代码，或者不熟悉硬件的性能等原因，随着单个索引数据越来越多，初始设置的分片较少已经满足不了读写性能的需要，最终不得不改。：拆分后，Elasticsearch 集群会自动调整这些新分片在集群内的分布，确保数据在各个节点之间均匀分布，从而提高整体集群的性能和稳定性。如果你还没有大量的数据并且可以重新索引，此时回头还不晚，立即创建指定一个更大的主分片数的新索引。方案三：分片拆分（Split）

使用自带的demo数据，仅仅几兆的大小完全看不出什么问题来，因此索引分片的拆分几乎是在瞬间就完成了，来不及观察。同时，通过实践证明Split拆分扩大索引分片的效率是极高的，这也是生产环境中分秒必争情况下优先考虑Split方案的另一个关键因素。第二步也就是核心操作，拆分大索引，扩大其分片数，然后业务使用扩大分片数后的新索引（或别名）。扩建索引的主分片数据很快完成，但是副本分片拷贝十分缓慢。尽管我们的目标是同样的数据扩成更多的分片，理论上数据存储临时需要多一倍，等扩增完成后老索引就可删除释放空间了。

并不能随心所欲地控制创建索引的内容、索引的结构和数据量，无法创建指定的测试数据集，或者直接投入生产使用。使用java或者spark则需编译使用，修改麻烦，人生苦短，我用python。本文介绍使用python脚本批量写ES数据，需要使用pip提前下载安装es依赖库。（注意，示例中大部分中文内容是为了增加存储使用量，否侧100万条数据仅85MB，当前百万数据占用665MB，可酌情减少字段）写入了2000万条数据约13GB，足以模拟大多数测试需求了，耗时6330秒。这是主要是为了安装python依赖。

一般来说，在Elasticsearch中，使用bulk API进行批量写入时，每批次的大小对性能有着显著的影响。然而，如果批量请求过大，会导致节点上的内存压力增大，进而影响其他请求的性能，甚至可能导致节点崩溃。可以从较小的批量开始（例如5MB），然后逐渐增加批量大小，观察写入性能的变化。经过计算，上述7种单批次大小的100万数据吞吐量差异最大只有千分之7，可以说是完全没有差异了，极端值才会显著降低性能。这图看着很唬人，实际上设定不同的批次大小对写入性能的影响微乎其微，图中所示的数据索引时间单位是毫秒。

在搭建正式的生产集群之前，充分做好硬件和服务器配置以及集群规划是重中之重，磨刀不误砍柴工。