当前位置: 首页 > 面试题库 >

Elasticsearch 2.1:“结果”窗口太大(index.max_result_window)

闻人树
2023-03-14
问题内容

我们从Elasticsearch 2.1检索信息,并允许用户翻阅结果。当用户请求较高的页码时,我们会收到以下错误消息

结果窗口太大,从+大小必须小于或等于:[10000],但为[10020]。请参阅滚动API,以获取请求大型数据集的更有效方法。可以通过更改[index.max_result_window]索引级别参数来设置此限制

弹性文档表示,这是因为内存消耗很高,并且要使用滚动api:

大于的值会在每次搜索和执行搜索的每个分片上消耗大量的堆内存。保留此值是最安全的,因为它是任何深度滚动使用的滚动API
https://www.elastic.co/guide/zh-
cn/elasticsearch/reference/2.x/breaking_21_search_changes.html#_from_size_limits

问题是我不想检索大型数据集。我只想从数据集中检索一个切片,该切片在结果集中很高。滚动文档也说:

滚动不适用于实时用户请求https://www.elastic.co/guide/en/elasticsearch/reference/2.2/search-
request-
scroll.html

这给我一些问题:

1)如果我使用滚动api向上滚动到结果10020(而不考虑低于10000的所有内容),而不是对结果10000-10020进行“正常”搜索,则内存消耗是否会真正降低(如果有,为什么)?

2)滚动API似乎不是我的选择,但我必须增加“ index.max_result_window”。有人对这个有经验么?

3)还有其他选择可以解决我的问题吗?


问题答案:

弹性文档中的以下页面讨论深度分页:

https://www.elastic.co/guide/en/elasticsearch/guide/current/pagination.html


https://www.elastic.co/guide/en/elasticsearch/guide/current/_fetch_phase.html

根据文档的大小,分片的数量以及所使用的硬件,完全可以分页10,000至50,000个结果(1,000至5,000页)。但是,通过足够大的值,使用大量的CPU,内存和带宽,排序过程的确会变得非常繁重。因此,我们强烈建议您不要进行深度分页。



 类似资料:
  • 问题内容: 我收到溢出错误(OverflowError:(34,“结果太大”)) 我想将pi计算为100个小数,这是我的代码: 问题答案: Python浮点数既不精确,也不具有无限大小。当k = 349时,太大了-几乎是2 ^ 1400。幸运的是,该库允许任意精度并可以处理大小:

  • 问题内容: 我在elasticSearch中收到以下错误: [结果窗口太大,从+大小必须小于或等于:[10000],但为[100000]。 请参阅滚动API,以获取请求大型数据集的更有效方法。可以通过更改[index.max_result_window]索引级别参数来设置此限制。我没有进入必须设置的文件 问题答案: 您可以在此处找到一些有关深度分页的官方文档的参考。 如果您需要更新Elastics

  • 问题内容: 当我将此配置添加到ubuntu vm中时; 在此配置后,当我重新启动Elasticsearch时,给我这个异常; 问题答案: 这是中的预期行为。不允许在节点级别配置上设置索引级别设置。 从文档中, index.max_result_window(默认值为10,000)是一种保护措施,搜索请求占用的堆内存和时间与+大小成正比。 如果您查看elasticsearch日志,它将显示以下内容,

  • 问题内容: 我有一个Java小程序,J试图使用setSize将其设置为480、800,但是由于某种原因,窗口出现487,850。这是设置它的代码。 在代码中的其他任何地方都没有提到设置大小,为什么会这样呢? 问题答案: 您没有在applet本身中设置applet的大小,并且尝试这样做将不会有任何效果,正如您所发现的那样。如果要指定小程序的大小,请在调用小程序的HTML代码中执行此操作。 顺便说一句

  • 使用翻滚窗口的apache flink应用程序遇到问题。窗口大小是10秒,我希望每隔10秒有一个resultSet数据流。然而,当最新窗口的结果集总是延迟时,除非我将更多数据推送到源流。 例如,如果我在“01:33:40.0”和“01:34:00.0”之间将多条记录推送到源流,然后停止查看日志,则不会发生任何事情。 我在“01:37:XX”上再次推送一些数据,然后将在“01:33:40.0”和“0

  • 我使用Flink SQL计算基于事件时间的窗口分析。在我的数据源每天晚上空闲之前,一切都正常工作,之后直到第二天数据再次开始流动时才产生最后一分钟的结果。 我已尝试将<code>设置为table.exec.source。空闲超时,但没有帮助。我能做什么?