Elasticsearch完成数据索引后能否删除原始数据？

ES本质是检索引擎，核心设计目标是提供快速的文本检索能力，而非作为原始数据的唯一可靠归档载体，针对你提出的三个问题，结合实际生产环境的判断标准逐一说明：

1. 索引完成后能不能直接删除原始文档？ #

没有绝对的可以或不可以，核心取决于你往ES里存的内容和原始文档的匹配程度：

• 如果你做索引时，只把文档中需要检索的纯文本片段（比如标题、正文摘要）存入ES，没有保留文档的排版格式、嵌入附件、完整元数据，那删掉原始文档后，后续根本没法完成原文导出、格式还原、二次解析加工的需求，这种场景绝对不能直接删除原始文件。
• 就算你把文档的全量原始内容一字不差存入了ES的_source字段，也不建议直接删除原始文档：ES的索引存在版本迭代、误操作删除、分片损坏的概率，它的多副本机制是为了保障单节点故障时检索服务不中断，不是为了做原始数据的灾备归档，一旦出现索引结构调整、段文件损坏、集群级故障，没有独立原始源的话，数据恢复的成本会极高。

2. 是否必须在其他位置存储原始数据？ #

不存在强制要求，你可以从三个维度判断是否需要单独存原始数据：

• 成本维度：同等大小的原始数据，ES因为要存储倒排索引、分段元数据、定期做段合并优化，整体存储开销是普通对象存储、文件服务器的3-10倍，长期存储大量冷数据的成本非常不划算。
• 合规维度：ES的索引更新是覆盖式的，默认不会留存文档的历史版本、操作痕迹，如果你的业务有合规审计要求（比如金融、政务场景要求留存原始文件的版本记录、哈希校验值），ES的存储能力完全满足不了要求。
• 兜底维度：ES不是100%可靠的存储系统，如果把原始文档的唯一副本放在ES里，一旦出现误操作删索引、存储介质故障、数据损坏，没有其他位置的备份就会造成永久性的数据丢失。

3. 相关判断是否完全取决于具体使用场景？ #

完全是，没有放之四海而皆准的标准，可以对照自身业务场景匹配对应方案：

• 不需要额外存原始文档的场景：比如做站内搜索时，ES只是从业务主数据库同步检索数据的检索层组件，原始数据本来就存在业务库、业务侧的文件存储里，那根本不需要为ES单独留存原始文档——就算ES集群全部丢失，只要重新从主数据源拉取数据重建索引就能恢复服务。再比如个人搭建笔记检索工具，本地文件夹已经是原始笔记的存储位置，ES只是用来加速检索，也不需要额外复制一份原始文档存到其他位置。
• 必须独立存储原始文档的场景：比如做对外的文档检索平台，用户上传的PDF、Word是平台核心资产，ES只是提供检索入口，那必须在独立的文件存储系统里留存全量原始文件，不能把ES当唯一的原始存储，否则用户后续要下载、导出原文件时根本无法提供。如果是有合规要求的行业场景，原始数据需要长期归档、留痕审计，也必须把原始文件存在专门的归档存储里，不能只靠ES存储。

新手最容易踩的坑：很多人觉得ES默认开启_source字段，能把存入的内容完整导出，就等于能替代原始文件存储。实际上_source里存的是你当初提交索引时的序列化内容，如果你索引时做了内容清洗、字段裁剪、格式转换，导出的内容根本不是真正的原始文档，完全达不到替代原始文件的效果。

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