如何解决将大型PDF文件导入Elastic Search索引时出现的超时问题

你当前的方案是将完整PDF转base64后一次性提交给ES的attachment管道处理，大体积PDF转码后体积会膨胀1/3，管道解码+Tika内容提取全流程耗时很长，HTTP请求链路、ES客户端请求超时、ES服务端处理超时任意环节阈值不足都会触发超时异常。

注：你此前对fscrawler、Logstash等工具的认知存在偏差，这类工具并非仅支持日志处理，均原生支持PDF等二进制办公文档的内容提取与ES索引，是解决该问题的最优选择。

方案1：使用FSCrawler（最推荐，适配批量/大体积文档场景） #

• FSCrawler是专门为ES设计的文件系统文档索引工具，原生支持PDF、Word、Excel等数十种格式的内容提取，内部已经适配大文件处理逻辑，不会出现超时问题
• 仅需简单配置本地PDF存储路径、ES集群地址、目标索引名，启动后会自动扫描目录文件，完成内容提取、索引写入全流程，还支持增量同步、断点续传
• 无需修改现有业务代码，运维成本极低

方案2：优化现有代码适配大文件 #

如果不想引入新工具，可从以下维度调整现有逻辑：

• 同步调高全链路超时阈值：除了请求参数里的timeout: '5m'，还需要修改ES集群配置的ingest.pipeline.timeout（管道处理超时）、indices.breaker.total.limit（内存熔断阈值），同时初始化ES客户端时设置requestTimeout为300000（5分钟）以上，避免链路任意环节主动断开连接
• 把同步处理改为异步任务：不要在HTTP请求的同步逻辑里处理大PDF转码、ES写入，收到上传请求后先把PDF存储到本地/对象存储，提交给后台异步任务执行后续流程，接口直接返回任务ID供前端轮询结果，规避HTTP请求超时
• 关闭ES客户端的自动重试逻辑，避免大文件重复提交加重集群负担

方案3：使用Logstash做中转处理 #

• 搭配Logstash的tika解码插件、elasticsearch输出插件，即可实现自动扫描指定目录下的PDF文件，完成内容提取后写入ES
• 可通过调整pipeline.workers、pipeline.batch.size等参数适配大文件处理性能，不会触发超时问题

内容的提问来源于stack exchange，提问作者regShank