Elasticsearch近实时搜索

转载 2018年04月16日 15:17:01

近实时搜索

随着按段(per-segment)搜索的发展, 一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索,但这样还是不够快。

磁盘在这里成为了瓶颈。 提交(Commiting)一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘,这样在断电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。

我们需要的是一个更轻量的方式来使一个文档可被搜索,这意味着 fsync 要从整个过程中被移除。

在Elasticsearch和磁盘之间是文件系统缓存。 像之前描述的一样, 在内存索引缓冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存--这一步代价会比较低,稍后再被刷新到磁盘--这一步代价比较高。不过只要文件已经在缓存中, 就可以像其它文件一样被打开和读取了。

图 19. 在内存缓冲区中包含了新文档的 Lucene 索引

A Lucene index with new documents in the in-memory buffer

Lucene 允许新段被写入和打开--使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多,并且在不影响性能的前提下可以被频繁地执行。

图 20. 缓冲区的内容已经被写入一个可被搜索的段中,但还没有进行提交

The buffer contents have been written to a segment, which is searchable, but is not yet commited

refresh API编辑

在 Elasticsearch 中,写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是  实时搜索: 文档的变化并不是立即对搜索可见,但会在一秒之内变为可见。

这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它,但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新:

POST /_refresh 
POST /blogs/_refresh 

刷新(Refresh)所有的索引。

只刷新(Refresh) blogs 索引。

提示

尽管刷新是比提交轻量很多的操作,它还是会有性能开销。 当写测试的时候, 手动刷新很有用,但是不要在生产环境下每次索引一个文档都去手动刷新。 相反,你的应用需要意识到 Elasticsearch 的近实时的性质,并接受它的不足。

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件, 你可能想优化索引速度而不是近实时搜索, 可以通过设置 refresh_interval , 降低每个索引的刷新频率:

PUT /my_logs
{
  "settings": {
    "refresh_interval": "30s" 
  }
}

每30秒刷新 my_logs 索引。

refresh_interval 可以在既存索引上进行动态更新。 在生产环境中,当你正在建立一个大的新索引时,可以先关闭自动刷新,待开始使用该索引时,再把它们调回来:

PUT /my_logs/_settings
{ "refresh_interval": -1 } 

PUT /my_logs/_settings
{ "refresh_interval": "1s" } 

关闭自动刷新。

每秒自动刷新。

小心

refresh_interval 需要一个 持续时间 值, 例如 1s (1 秒) 或 2m (2 分钟)。 一个绝对值 1 表示的是 1毫秒 --无疑会使你的集群陷入瘫痪。

为什么说Elasticsearch搜索是近实时的?

通过前面两篇文章的介绍,我们大概已经知道了 Elasticsearch处理数据的流程,其中在Elasticsearch和磁盘之间还有一层称为FileSystem Cache的系统缓存,正是由于这层ca...
  • u010454030
  • u010454030
  • 2018-03-16 19:47:30
  • 243

elasticsearch近实时搜索refresh

近实时搜索编辑 随着按段(per-segment)搜索的发展, 一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索,但这样还是不够快。 磁盘在这里成为了...
  • gongpulin
  • gongpulin
  • 2017-12-10 17:25:03
  • 397

剖析Elasticsearch集群系列第三篇 近实时搜索、深层分页问题和搜索相关性权衡之道

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。本文是这个系列的第三篇,我们将讨论Elasticsearch是如何提供近实时搜索并...
  • zlh3955649
  • zlh3955649
  • 2016-11-15 11:35:32
  • 837

lucene学习笔记(七)lucene近实时搜索

近实时搜索Lucene3.5起提供了NRTManager管理近实时搜索。原理:将搜索存放到内存中,每个一定时间提交到硬盘中。NRTManager和SearchManager是线程安全的使用NRTMan...
  • fgyibupi
  • fgyibupi
  • 2017-01-25 14:15:09
  • 976

Lucene 6.2.1入门教程(三) 近实时搜索的变化

Lucene从2.9版本就提供了一个近实时搜索功能,就是在一个打开的IndexWriter中获取IndexReader,读取该IndexWriter要写入的内容。 Lucene 4.x版本对这个功能...
  • ccdust
  • ccdust
  • 2017-01-27 22:34:18
  • 699

Lucene系列-近实时搜索(1)

近实时搜索(near-real-time)可以搜索IndexWriter还未commit的内容,介于immediate和eventual之间,在数据比较大、更新较频繁的情况下使用。lucene的nrt...
  • whuqin
  • whuqin
  • 2015-01-20 20:01:33
  • 2798

solr 近实时搜索

摘要: Solr的近实时搜索NRT(Near Real Time Searching)意味着文档可以在索引以后马上可以被查询到。Solr不会因为这次提交而阻塞更新操作,不会等待后台合并的完成而直接检索...
  • jiangchao858
  • jiangchao858
  • 2017-04-22 23:22:02
  • 2808

lucene4及以上如何做到近实时搜索

请支持原创博客 http://blog.csdn.net/cl59452/article/details/38408741 lucene2.9 之后推出了nrtmanager  近实时搜索,...
  • cdnight
  • cdnight
  • 2014-10-19 22:19:03
  • 4901

lucene系列-近实时搜索

Index索引刷新过程:只有Index Writer上的commit操作才会导致ram directory上的数据完全同步到文件。 Index Writer提供了实时获得reader的API,这个调...
  • madman188
  • madman188
  • 2016-04-25 14:08:34
  • 1858

Lucene近实时搜索应用总结

原文地址:Lucene近实时搜索应用总结 最近因工作需要,用到了Lucene,在需求中,需要对生成的索引文件不断的更新、新增、删除等操作,同时还要实时的看到索引改动后的数据,在使用过程中碰到了Luc...
  • huyongl1989
  • huyongl1989
  • 2015-09-26 14:10:49
  • 1890
收藏助手
不良信息举报
您举报文章:Elasticsearch近实时搜索
举报原因:
原因补充:

(最多只允许输入30个字)