【问题标题】:Elasticsearch - Search with in near realtime (1 sec)Elasticsearch - 近乎实时的搜索(1 秒)
【发布时间】:2021-01-27 08:57:41
【问题描述】:

我遇到了以下短语https://www.elastic.co/guide/en/elasticsearch/reference/6.8/documents-indices.html

存储文档后,它会被近乎实时地编入索引并完全可搜索——在 1 秒内。

假设 1 秒是主观的并且取决于各种因素,我们可以安全地假设它至少是 1 秒吗?而且,我看到不同的时间间隔将作为索引的一部分启动,如刷新间隔等,这 1 秒是否大约是所有这些间隔的总和(中间)

当我们说 elasticsearch 是(接近)实时搜索引擎时,它的实时性是多少

【问题讨论】:

  • 不是“至少”,在大多数情况下它比 1 秒短得多
  • 1 秒的间隔可能取决于各种因素,如网络延迟、分片等 ..?对吗?

标签: elasticsearch


【解决方案1】:

默认刷新间隔(由索引设置index.refresh_interval 控制)为一秒。你引用的那句话就是这个意思。默认情况下,您编入索引的文档将在最多一秒内可供搜索,但也可能少于此时间。

如果刷新发生在瞬间 T 并且您在同一时刻索引文档,则基础段将在几乎恰好一秒内刷新,并且您的文档将在刷新后可搜索。

如果在瞬间 T 发生刷新,并且您在该瞬间后 500 毫秒为您的文档编制索引,那么它在被编制索引后仅 500 毫秒就可用于搜索。

这也意味着,如果您在 T 时刻发生的最后一次刷新后的 T+990 毫秒时刻对其进行索引,则您的文档在被编入索引后仅几毫秒(例如 10 毫秒)就可用。

这不是精确的科学,因此一秒钟的时间应该加一粒盐,有时它可能会持续更长时间,比如 10xx 毫秒,其中 xx 取决于各种因素。不过,您不应该依赖于纳米级精确的持续时间。

所以近乎实时只是表示刷新间隔的持续时间(您可以修改)。

【讨论】:

  • "这不是精确的科学,所以一秒钟应该用一粒盐,有时它可能会持续更长时间,比如 10xx 毫秒,其中 xx 取决于各种因素。你不应该依赖不过,在那个持续时间上是纳米级的。” . 1 秒的间隔可能取决于各种因素,如网络延迟、分片等 ..?对吗?
  • 是的,这是正确的,节点本身之间的网络延迟,段合并过程可能正忙于完成另一个操作,可能由于其他大量搜索/写入等导致资源争用。但在正常操作中,那 1 秒相当稳定。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-12-06
  • 2013-07-10
  • 2018-06-06
  • 1970-01-01
  • 1970-01-01
  • 2015-07-24
  • 1970-01-01
相关资源
最近更新 更多