问：能否仅删除索引内部的某些数据？
做个思想实验，把 Elasticsearch 索引想象成数据库，或者数据库中的表空间。如果你要从数据库中删除数亿行数据，你会每天运行单独的 DELETE from TABLE where date<YYYY.MM.dd 来组合数亿个单独的删除操作，还是会通过对表进行分区，从而能够简单地运行 DROP table TABLENAME.YYYY.MM.dd？前者对数据库造成的压力将是巨大的，而后者几乎没有什么压力。Elasticsearch 的工作原理非常相似。虽然 Elasticsearch 从技术上讲可以采用这两种方法，但对于时间序列数据（如日志记录）的使用场景，我们建议删除整个索引，而不是采用极其消耗 I/O 的搜索并删除方法。Curator 的诞生就是为了满足这一需求。
虽然你可以将不同类型存储在不同的索引中（例如 syslog-2014.05.05、apache-2015.05.06），但这会以完全不同的方式迅速变得非常昂贵。Elasticsearch 中的每个分片都是一个 Lucene 索引。每个索引都需要一部分堆内存来维持存在并保持最新。如果你有 3 个每日索引，每个索引有 5 个主分片，那么用于分片管理的可用堆空间就会骤减（分片数量从 5 个增至 15 个，每个索引，还不算每天有多个索引的情况）。缓解这种情况的方法（如果你选择这条路线）包括：使用庞大的日常索引服务器，使用分片分配/路由将索引移动到集群中的特定成员上以减小其影响；保留较少天数的信息；在集群中拥有更多节点，等等。
尽管为数据设置不同的生命周期可能是可取的，但有时，只要按照你希望维护的最长生命周期存储所有数据，往往更简单、成本也更低。
尽管这既不被推荐1，也不是最佳实践，但你仍然可以使用 Delete by query API 自行执行这些搜索和删除操作。然而，Curator 不会被修改为执行此类操作。Curator 旨在进行索引级别的管理，而不是数据级别的管理。
1Elasticsearch 不建议这样做是有原因的，特别是对于时间序列数据。欲了解更多信息，请阅读这篇博客文章，并观察当你删除数据时你的段（segments）会发生什么。