假设我正面临一个Elasticsearch数据库，该数据库包含一组给定的索引以及遍布它们的大量文档。当我调用http://localhost:9200/_optimize时，运行需要很长时间，结果证明这是必要的事情，显而易见的暗示是数据库大小减少了大约20％。
现在我想针对每个索引而不是整个数据库定期进行优化。对我们来说这很有意思，因为我们通常的操作并不会同时涵盖所有指数。随着时间的推移，所有指数都会受到影响。我如何找出哪些指数需要优化？
我觉得有用的是使用http://localhost:9200/_stats/docs查找已删除文档的索引。
我可以做其他检查吗？
也许要强调一点，这个问题不是关于何时，为什么或如何优化或如何避免它。
答案 0 :(得分：1)
ES中的索引基本上是磁盘上的文件。每次执行索引操作时，都会将文档附加到此类文件或新的段文件（取决于刷新周期）。优化过程将较小的Lucene段合并为更大的段。
当对索引执行删除操作或更新操作（更新=删除旧版本的文档并重新索引文档的新版本）时，文档实际上不会被删除，而是标记为删除。每当合并操作开始时，就是实际删除“标记为已删除”文档的时间。
这就是为什么查看已删除文档的数量然后合并可以改善磁盘分配空间的原因。通常，不需要优化操作，它由ES自动执行。如果您真的想这样做，请注意它会消耗IO和CPU周期。这可能有用的一种情况是那些不太可能在未来发生变化的指数（例如，过去的日志）。建议不要在其他情况下手动执行此操作。
“哪些指数需要优化？” - 那些你知道不太可能改变的东西（不再写它们）。理想情况下，一个索引最好只有一个段（搜索只有一个段的索引比搜索由多个段组成的索引更好）。
另外，我建议this reading关于优化。