Elasticsearch中维护已删除文档历史及通知用户的查询方法

首先得明确：单纯靠查询没法直接维护删除历史，得先做好删除行为的记录机制，再配合查询实现需求，下面是具体方案：

1. 先搞定删除历史的记录方式 #

有两种常用思路：

• 软删除标记：别直接用DELETE API删文档，给每个文档加个status字段（比如active表示正常，deleted表示已删除），同时加deleted_at（删除时间）、deleted_by（操作人）这类元数据。删除时只更新这些字段，不删文档本身。
• 独立历史索引：创建一个专门的document_history索引，每次删除原文档前，把原文档的完整内容+删除元数据（删除时间、操作人、操作类型）写入这个历史索引，再执行原文档的删除操作。

2. 对应的查询方法 #

针对软删除模式的查询 #

如果用软删除标记，查询逻辑很直接：

• 当用户请求某个文档ID时，先查原索引：

GET /你的索引名/_search
{
  "query": {
    "term": {
      "_id": "用户请求的文档ID"
    }
  }
}

• 如果返回的文档status是deleted，就可以告知用户“该文档曾存在，现已被删除”，还能把deleted_at等信息一起返回。
• 要是想批量查已删除的文档，用这个查询：

GET /你的索引名/_search
{
  "query": {
    "term": {
      "status": "deleted"
    }
  }
}

针对独立历史索引的查询 #

如果用了单独的历史索引，直接查历史索引就能验证文档是否存在过并被删除：

GET /document_history/_search
{
  "query": {
    "term": {
      "original_document_id": "用户请求的文档ID"
    }
  },
  "sort": [{"deleted_at": "desc"}]
}

只要能查到结果，就说明该文档曾存在且已被删除，把对应的提示和历史信息返回给用户即可。

3. 额外注意点 #

• 软删除的优势是不用额外维护索引，数据都在原索引，但业务查询时要记得默认过滤掉status:deleted的文档，避免影响正常业务。
• 独立历史索引的好处是原索引不会被已删除数据占用空间，历史数据还能单独设置生命周期策略（比如自动归档、删除超期数据）。

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