弹性搜索如何处理并行索引刷新请求？答案

【问题标题】：How elastic search handles parallel index refresh requests?弹性搜索如何处理并行索引刷新请求？
【发布时间】：2018-09-28 21:56:36
【问题描述】：

在我们的项目中，我们会在每次创建/更新/删除操作后点击弹性搜索的索引刷新 api，以便立即进行搜索。

我想知道，如果在具有接近 250 万个文档的单个索引上对其刷新 api 发出多个并行请求，弹性搜索将如何执行？

有什么想法吗？建议？

【问题讨论】：

你能详细说明你想用它实现什么吗？例如，您可能会使用刷新索引查询访问一个节点，但您甚至不确定副本是否已摄取数据，因此您甚至可能无法实现您认为的目标。 Elastic 已经接近实时，您可以设置自动刷新率（默认 index.refresh_interval 为 1 秒）。因此，除非您知道您的应用将插入然后立即取回的用例，否则您甚至可能不需要实际刷新。
是的，有这样的用例。因此，我们的应用程序有一个 UI 流程，用户在其中创建内容，然后立即导航到列表屏幕，其中最近创建/修改的内容显示在顶部。
目前，在每次 CUD 操作后，我们都会点击刷新 api。而且，我们正在开发一项功能，现有文档数量将增加两/三倍，即高达 750 万。我想知道我们是否在每次 CUD 操作后仍然继续刷新，那么它会以任何方式影响弹性搜索性能。我所说的性能是指索引、搜索或更多 GC 暂停等方面的任何延迟。
这个答案也可能有帮助：stackoverflow.com/questions/31499575/…

【解决方案1】：

Refresh 是 ElasticSearch 要求 Lucene 分片在磁盘上提交修改并创建一个段的操作。如果您在每次操作后都要求刷新，您将创建大量微细分。

太多的段会使您的搜索时间更长，因为您的分片需要按顺序搜索所有这些段才能返回搜索结果。此外，它们会消耗硬件资源。

每个段都消耗文件句柄、内存和 CPU 周期。更重要的是，每个搜索请求都要依次检查每个段；段越多，搜索就越慢。 from the definitive guide

Lucene 会自动将这些段合并为更大的段，但这也是一项消耗 I/O 的任务。

您可以查看this了解更多详情

但据我所知，刷新 25 亿个文档索引所需的时间与 2.5k 个文档索引相同。此外，刷新似乎 (from this issue) 是一个非阻塞操作。

但对于弹性搜索集群来说，这是一种糟糕的模式。您的应用程序的每个 CUD 操作都需要刷新吗？

【讨论】：