ES倒排索引中，文档删除后为何依然占用空间？如何通过图文解析优化存储？

Question

在Elasticsearch（ES）中，当文档被删除时，为何其空间未能立即释放？这是因为ES采用的倒排索引机制中，删除操作仅标记文档为“已删除”，而非物理移除。这种设计是为了维持查询性能，因为重写整个索引段成本较高。 那么如何优化存储呢？可通过如下方式：一是定期执行`forcemerge`操作，将小片段合并成大索引段并清理标记为删除的文档；二是调整分片数量，减少过多分片带来的元数据开销；三是启用`index.codec`设置，选择更高效的压缩算法如`best_compression`。 下图展示了删除标记与合并过程： ``` [图示：倒排索引中删除标记及合并清理流程] ``` 注意，在执行优化操作时需权衡系统负载与性能影响。

Answer 1

1. Elasticsearch 删除操作的基础理解

在Elasticsearch中，删除文档的操作并不是直接从磁盘上移除数据，而是通过一种标记机制来实现。这种设计的核心原因在于Elasticsearch的底层倒排索引结构。如果每次删除都重写整个索引段，将导致性能急剧下降，尤其是在高并发场景下。

因此，ES采用了一种延迟清理策略：当文档被删除时，系统仅将其标记为“已删除”状态，并记录在`.del`文件中。只有在后续执行合并（merge）操作时，这些标记为删除的文档才会被真正移除。

2. 存储优化的技术分析

为了减少存储空间浪费并提升查询性能，可以通过以下几种方式对Elasticsearch进行优化：

1. 定期执行forcemerge操作：此操作会将多个小的索引段合并成一个大的索引段，并在此过程中清理掉所有标记为删除的文档。
2. 调整分片数量：过多的分片会导致元数据开销增加，从而影响性能和存储效率。合理规划分片数量是优化的重要一步。
3. 启用高效压缩算法：通过设置`index.codec=best_compression`，可以显著降低存储空间占用，同时保持较高的查询性能。

3. 示例代码与配置

以下是执行forcemerge操作的示例命令：

POST /your_index/_forcemerge?max_num_segments=1
    

此外，可以在创建索引时指定更高效的压缩算法：

PUT /your_index
{
  "settings": {
    "index.codec": "best_compression"
  }
}
    

4. 合并与清理流程图

以下是倒排索引中删除标记及合并清理的流程图：

graph TD;
            A[文档被删除] --> B{标记为删除};
            B --> C[写入.del文件];
            C --> D[等待合并操作];
            D --> E[执行forcemerge];
            E --> F[清理已删除文档];

5. 性能权衡与注意事项

尽管上述优化方法能够有效减少存储空间占用，但在实际应用中需要考虑以下几个方面：

优化措施	优点	潜在风险
forcemerge	清理删除文档，释放存储空间	可能导致CPU和I/O负载增加
调整分片数量	降低元数据开销	重新分片可能带来复杂性
启用高效压缩	减少存储占用	可能轻微影响写入性能

在实施优化前，建议充分评估当前系统的负载情况，并根据业务需求选择合适的方案。