如何优化elasticsearch percolator index 内存性能

Question

在使用 elasticsearch percolator index 时，有没有办法提高内存性能？

我为我的过滤器创建了一个单独的索引。我大约有 1 000 000 个用户创建了保存的搜索（用于电子邮件警报）。创建此渗透器索引后，我的堆使用率飙升至 100%，并且服务器对任何查询都没有响应。我的资源有些有限，无法简单地在问题上投入更多的 RAM。唯一的解决方案是删除包含我保存的搜索的索引。

根据我的阅读，渗滤器索引永久驻留在内存中。这完全有必要吗？有没有办法限制这种行为但仍然保留功能？有没有办法优化我的数据/查询/索引结构来规避这种行为，同时仍然达到预期的结果？

Answer 1

从 ElasticSearch 的角度来看，这个问题没有解决方案，也不太可能。我已经直接与 ElasticSearch 人员聊天，他们的回答是：“投入更多硬件”。

然而，我找到了一种方法来解决这个问题，以减轻我对该功能的使用。当我分析我保存的搜索数据时，我发现我的搜索包含大约 100,000 个唯一关键字搜索以及各种过滤器排列，创建了超过 1,000,000 个保存的搜索。

如果我查看过滤器，它们是这样的：

• 位置 - 300+
• 行业 - 50+
• 等等……

给出一个解空间：

100 000 * >300 * >50 * ... ~= > 1 500 000 000

但是，如果我要在过滤器索引中分别分解搜索并索引关键字搜索和过滤器， 我最终的搜索量要少得多：

100 000 + >300 + >50 + ... ~= > 100 350

这些搜索本身比原始搜索更小，更简单。

现在我创建第二个（非渗透器）索引，列出所有 1 000 000 个已保存的搜索，并包括来自 渗滤器指数。

然后我过滤一个文档，然后执行第二个查询，根据关键字过滤搜索并过滤过滤器结果。 我什至能够保留相关性分数，因为这纯粹是从关键字搜索中返回的。

这种方法将在达到相同目的的同时显着减少我的过滤器索引内存占用。

我想就这种方法征求反馈意见（我还没有尝试过，但我会及时通知你）。

同样，如果我的方法成功，您认为值得提出功能请求吗？