es近实时搜索原理

标签: es 实时 搜索 | 发表时间:2019-05-08 09:56 | 作者:dwj147258
出处:https://www.iteye.com

1.

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

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

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

在Elasticsearch和磁盘之间是文件系统缓存。 像之前描述的一样, 在内存索引缓冲区(  图 19 “在内存缓冲区中包含了新文档的 Lucene 索引” )中的文档会被写入到一个新的段中(  图 20 “缓冲区的内容已经被写入一个可被搜索的段中,但还没有进行提交” )。 但是这里新段会被先写入到文件系统缓存--这一步代价会比较低,稍后再被刷新到磁盘--这一步代价比较高。不过只要文件已经在缓存中, 就可以像其它文件一样被打开和读取了。

图 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毫秒 --无疑会使你的集群陷入瘫痪。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [es 实时 搜索] 推荐:

es近实时搜索原理

- - 企业架构 - ITeye博客
 随着按段(per-segment)搜索的发展, 一个新的文档从索引到可被搜索的延迟显著降低了. 新文档在几分钟之内即可被检索,但这样还是不够快.  提交(Commiting)一个新的段到磁盘需要一个 . fsync 来确保段被物理性地写入磁盘,这样在断电的时候就不会丢失数据. 但是  fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题.

用Flink SQL CDC + ES实现数据实时化真香!

- -
本人目前参与的项目属于公司里面数据密集、计算密集的一个重要项目,需要提供高效且准确的 OLAP 服务,提供灵活且实时的报表. 业务数据存储在 MySQL 中,通过主从复制同步到报表库. 作为集团级公司,数据增长多而且快,出现了多个千万级、亿级的大表. 为了实现各个维度的各种复杂的报表业务,有些千万级大表仍然需要进行 Join,计算规模非常惊人,经常不能及时响应请求.

ES和Druid搞不定的实时场景,我们用ClickHouse摆平了

- -
在介绍实时场景之前,我先简单讲一下早期的离线数据是如何支持的:. 在第一场分享中,技术负责人陈星介绍了 ClickHouse 在字节跳动内部最早支持的两个业务场景,用户行为分析平台和敏捷 BI 平台. 这两个平台的数据主要由分析师或者数仓同学产出,以 T+1 的离线指标为主. 考虑到 ClickHouse 并不支持事务,为了保障数据的一致性,我们在 ClickHouse 系统外实现了一套外部事务:.

MySQL如何实时同步数据到ES?试试这款阿里开源的神器!

- - 掘金后端本月最热
SpringBoot实战电商项目mall(40k+star)地址:. mall项目中的商品搜索功能,一直都没有做实时数据同步. 最近发现阿里巴巴开源的 canal可以把MySQL中的数据实时同步到Elasticsearch中,能很好地解决数据同步问题. 今天我们来讲讲 canal的使用,希望对大家有所帮助.

ES优化总结

- - 非技术 - ITeye博客
最近一直在研究ES集群,也看了很多篇前辈们总结的博客,同事借鉴了官方给出的一些建议,做了一下几点总结,希望对后来者有用:. 为了防止ES进程的内存被置换到磁盘上(会导致在检索的时候发生内存交换导致检索速度迟缓)引起性能急速下降. 候可以把config/elasticsearch.yml中的bootstrap.mlockall设置为true就可以了.

es的连接查询

- - 行业应用 - ITeye博客
在一般的关系型数据库中,都支持连接操作. 在ES这种分布式方案中进行连接操作,代价是十分昂贵的. 不过ES也提供了相类似的操作,支持水平任意扩展,实现连接的效果. 其他内容, 参考Elasticsearch官方指南整理. 在ES中支持两种连接方式:嵌套查询 和 has_child、has_parent父子查询.

ES性能优化总结

- - 互联网 - ITeye博客
    Elasticsearch是目前大数据领域最热门的技术栈之一,经过近8年的发展,已从0.0.X版升级至6.X版本,虽然增加了很多的特性和功能,但是在主体架构上,还是没有太多的变化. 下面就把我对于ES使用实践的一些经验总结一下,供大家参考;也请大家拍砖. 如果有条件,尽可能使用SSD硬盘, 不错的CPU.

Twitter实时搜索系统EarlyBird

- - CSDN博客互联网推荐文章
twitter对存档的tweet使用lucene做全量索引,新发的推文则是实时索引,实时检索(10秒之内索引). 实时索引和检索系统叫EarlyBird. 感觉写得比较清楚简洁,只要这些信息足够真实可信,完全可以做实现参考. 1)基于lucene + java,michael busch是lucene committer.

[原]Lucene系列-近实时搜索

- - 文武天下
近实时搜索(near-real-time)可以搜索IndexWriter还未commit的内容,介于immediate和eventual之间,在数据比较大、更新较频繁的情况下使用. lucene的nrt可以控制更新生效的间隔时间. 从indexwriter中获得indexreader. 建立indexsearcher.

ES既是搜索引擎又是数据库?真的有那么全能吗? - 更多 - dbaplus社群:围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙。

- -
经常遇到很多朋友询问,如何学好Elasticsearch. 这个问题本质上很不好回答,但我一直又很想好好回答,所以本文就以我个人的经验视角,跟大家探讨一下如何正确的拥抱Elasticsearch. Elasticsearch是什么,不同的人有不同的理解定位,之前写过Elasticsearch对比其它数据产品的文章.