Elasticsearch深度应用(上) - 女友在高考 - 博客园

标签: | 发表时间:2022-07-09 14:17 | 作者:
出处:https://www.cnblogs.com

索引文档写入和近实时搜索原理

基本概念

Segments in Lucene

众所周知,Elasticsearch存储的基本单元是shard,ES中一个index可能分为多个shard,事实上每个shard都是一个Lucece的Index,并且每个Lucece Index由多个Segment组成,每个Segment事实上是一些倒排索引的集合,每次创建一个新的Document,都会归属一个新的Segment,而不会去修改原来的Segment。且每次的文档删除操作,仅仅会标记Segment的一个删除状态,而不会真正立马物理删除。所以说ES的Index可以理解为一个抽象的概念。如下图所示:

Commits in Lucene

Commit操作意味着将Segment合并,并写入磁盘。保证内存数据不丢失。但刷盘是很重的IO操作,所以为了性能不会刷盘那么及时。

Translog

新文档被索引意味着文档首先写入内存buffer和translog文件。每个shard都对应一个translog文件。

Refresh in Elasticsearch

在Elasticsearch种,_refresh操作默认每秒执行一次,意味着将内存buffer的数据写入到一个新的Segment中,这个时候索引变成了可被检索的。写入新Segment后会清空内存。

Flush in Elasticsearch

Flush操作意味着内存buffer的数据全都写入新的Segment中,并将内存中所有的Segments全部刷盘,并且清空translog日志的过程。

近实时搜索

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

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

原理:

当一个写请求发送到es后,es将数据写入memory buffer中,并添加事务日志(translog)。如果每次一条数据写入内存后立即写到硬盘文件上,由于写入的数据肯定是离散的,因此写入硬盘的操作也就是随机写入了。硬盘随机写入的效率相当低,会严重降低es的性能。

因此es在设计时在memory buffer和硬盘间加入了Linux的高速缓存(Filesy stemcache)来提高es的写效率。当写请求发送到es后,es将数据暂时写入memory buffer中,此时写入的数据还不能被查询到。默认设置下,es每1秒钟将memory buffer中的数据refresh到Linux的Filesy stemcache,并清空memory buffer,此时写入的数据就可以被查询到了。

Refresh API

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

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

  1. 刷新所有索引
      POST /_refresh
  1. 只刷新某一个索引
      POST /索引名/_refresh
  1. 只刷新某一个文档
      PUT /索引名/_doc/{id}?refresh
{"test":"test"}

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

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

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

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

持久化变更

如果没有用fsync把数据从文件系统缓存刷(flush)到硬盘,我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证Elasticsearch的可靠性,需要确保数据变化被持久化到磁盘。

在动态更新索引时,我们说一次完整的提交会将段刷到磁盘,并写入一个包含所有段列表的提交点。Elasticsearch在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

即使通过每秒刷新(refresh)实现了近实时搜索,我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办?我们也不希望丢失掉这些数据。Elasticsearch增加了一个translog,或者叫事务日志,在每一次对Elasticsearch进行操作时均进行了日志记录。

整个流程如下:

  1. 一个文档被索引之后,就会被添加到内存缓冲区,并且追加到了translog。如下图:

  1. 分片每秒refres一次,refresh完成后,缓存被清空

  2. 这个进程继续工作,更多的文档被添加到内存缓冲区和追加到事务日志

  3. 每隔一段时间--例如translog变得越来越大--索引被刷新(flush);一个新的translog被创建,并且一个全量提交被执行。

  • 所有在内存缓冲区的文档被写入一个新的段
  • 缓冲区被清空
  • 一个提交点被写入磁盘
  • 文件系统缓存通过fsync被刷新(flush)
  • 老的translog被删除

translog提供所有还没有被刷到磁盘的操作的一个持久化纪录。当Elasticsearch启动的时候,它会从磁盘中使用最后一个提交点去恢复已知的段,并且会重放translog中所有在最后一次提交后发生的变更操作。

Flush API

这个执行一个提交并且截断translog的行为在Es中被称为一次flush。分片每30分钟被自动刷新(flush),或者在translog太大的时候也会刷新。

flush API 可以被用来执行手工的刷新

      POST /索引名称/_flush

#刷新(flush)所有的索引并且等待所有刷新在返回前完成
POST /_flush?wait_for_ongoin

我们知道用fsync把数据从文件系统缓存flush到硬盘是安全的,那么如果我们觉得偶尔丢失几秒数据也没关系,可以启用async。

      PUT /索引名/_settings {
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}

索引文档存储段合并机制

由于自动刷新流程每秒会创建一个新的段,这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和CPU运行周期。更重要的是,每个搜索请求都必须轮流检查每个段;所以段越多,搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段,然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档(或被更新文档的旧版本)不会被拷贝到新的大段中。

合并大的段需要消耗大量的I/O和CPU资源,如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制,所以搜索仍然有足够的资源很好地执行。默认情况下,归并线程的限速配置indices.store.throttle.max_bytes_per_sec是20MB。对于写入量较大,磁盘转速较高,甚至使用SSD盘的服务器来说,这个限速是明显过低的。对于ELKStack应用,建议可以适当调大到100MB或者更高。

      PUT /_cluster/settings
{
  "persistent" : {
  "indices.store.throttle.max_bytes_per_sec" : "100mb"
  }
}

归并策略

归并线程是按照一定的运行策略来挑选 segment 进行归并的。主要有以下几条:

index.merge.policy.floor_segment默认2MB,小于这个大小的segment,优先被归并。

index.merge.policy.max_merge_at_once默认一次最多归并10个segment

index.merge.policy.max_merge_at_once_explicit默认optimize时一次最多归并30个segment。

index.merge.policy.max_merged_segment默认5GB,大于这个大小的segment,不用参与归并。optimize除外

optimize API

optimizeAPI大可看做是强制合并API。它会将一个分片强制合并到max_num_segments参数指定大小的段数目。这样做的意图是减少段的数量(通常减少到一个),来提升搜索性能。

在特定情况下,使用optimizeAPI颇有益处。例如在日志这种用例下,每天、每周、每月的日志被存储在一个索引中。老的索引实质上是只读的;它们也并不太可能会发生变化。在这种情况下,使用optimize优化老的索引,将每一个分片合并为一个单独的段就很有用了;这样既可以节省资源,也可以使搜索更加快速。

api:

      POST /logstash-2014-10/_optimize?max_num_segments=1

java api:

      forceMergeRequest.maxNumSegments(1)

Es乐观锁

Es的后台是多线程异步的,多个请求之间没有顺序,可能后发起修改请求的先被执行。Es的并发是基于自己的_version版本号进行并发控制的。

1. 基于seq_no

乐观锁示例:

先新增一条数据

      PUT /item/_doc/4
{
  "date":"2022-07-01 01:00:00",
  "images":"aaa",
  "price":22,
  "title":"先"
}

查询:

      GET /item/_doc/4

可以查出我们的seq_no和primary_term

      {
  "_index" : "item",
  "_type" : "_doc",
  "_id" : "4",
  "_version" : 5,
  "_seq_no" : 12,
  "_primary_term" : 5,
  "found" : true,
  "_source" : {
    "date" : "2022-07-01 01:00:00",
    "images" : "aaa",
    "price" : 33,
    "title" : "先"
  }
}

然后两个客户端都根据这个seq_no和primary_term去修改数据,会有一个提示异常的。

      PUT /item/_doc/4?if_seq_no=12&if_primary_term=5
{
  "date":"2022-07-01 01:00:00",
  "images":"aaa",
  "price":33,
  "title":"先"
}

2. 基于external version

es提供了一个功能,不用它内部的_version来进行并发控制,你可以根据你自己维护的版本号进行并发控制。

      ?version=1&version_type=external

区别在于,version方式,只有当你提供的version与es中的version一模一样的时候,才可以进行修改,只要不一样,就报错。当version_type=external的时候,只有当你提供的version比es中的_version大的时候,才能完成修改

示例:

我先查出目前的version为7

      {
  "_index" : "item",
  "_type" : "_doc",
  "_id" : "4",
  "_version" : 7,
  "_seq_no" : 14,
  "_primary_term" : 5,
  "found" : true,
  "_source" : {
    "date" : "2022-07-01 01:00:00",
    "images" : "aaa",
    "price" : 33,
    "title" : "先"
  }
}

只有设置为8才能成功修改了

      PUT /item/_doc/4?version=8&version_type=external
{
  "title":"先"
}

分布式数据一致性如何保证

es5.0版本后

      PUT /test_index/_doc/1?wait_for_active_shards=2&timeout=10s
{
  "name":"xiao mi"
}

这代表着所有的shard中必须要有2个处于active状态才能执行成功,否则10s后超时报错。

相关 [elasticsearch 深度 应用] 推荐:

Elasticsearch深度应用(下) - 女友在高考 - 博客园

- -
query then fetch(默认搜索方式). 找到所有匹配的文档,并使用本地的Term/Document Frequery信息进行打分. 返回关于结果的元数据到请求节点. 注意,实际文档还没有发送,只是分数. 来自所有shard的分数合并起来,并在请求节点上进行排序,文档被按照查询要去进行选择.

Elasticsearch深度应用(上) - 女友在高考 - 博客园

- -
众所周知,Elasticsearch存储的基本单元是shard,ES中一个index可能分为多个shard,事实上每个shard都是一个Lucece的Index,并且每个Lucece Index由多个Segment组成,每个Segment事实上是一些倒排索引的集合,每次创建一个新的Document,都会归属一个新的Segment,而不会去修改原来的Segment.

从原理到应用,Elasticsearch详解

- - SegmentFault 最新的文章
Elasticsearch(简称ES)是一个分布式、可扩展、实时的搜索与数据分析引擎. ES不仅仅只是全文搜索,还支持结构化搜索、数据分析、复杂的语言处理、地理位置和对象间关联关系等. ES的底层依赖Lucene,Lucene可以说是当下最先进、高性能、全功能的搜索引擎库. 但是Lucene仅仅只是一个库.

ElasticSearch 亿级数据检索深度优化

- - IT瘾-dev
数据平台已迭代三个版本,从头开始遇到很多常见的难题,终于有片段时间整理一些已完善的文档,在此分享以供所需朋友的实现参考,少走些弯路,在此篇幅中偏重于ES的优化,关于HBase,Hadoop的设计优化估计有很多文章可以参考,不再赘述. 在一业务系统中,部分表每天的数据量过亿,已按天分表,但业务上受限于按天查询,并且DB中只能保留3个月的数据(硬件高配),分库代价较高.

全方位深度解读 Elasticsearch 分页查询

- - IT瘾-dev
1、关于 Elasticsearch 分页查询,这几个问题经常被问到. 问题1:想请问下,一次性获取索引上的某个字段的所有值(100 万左右),除了把 max_result_window 调大 ,还有没有啥方法. 问题2:关于 es 的分页,每次拿 20 条展示在前台,然后点击下一页,在查询后面的20条数据,应该要怎么写.

[译]为什么ElasticSearch应用开发者需要了解cluster state

- - SegmentFault 最新的文章
在前面的文章( ES vs Solr)中我们提到, ES构建了Loggly的很多核心功能. 在把这项通用搜索技术用于我们的日志管理系统, 并为超过5000多客户提供准实时服务的过程中, 我们在技术上成长颇多. 按照我们对开源社区的尊重, 在此希望能把我们所学到的知识回馈到社区. 本文将探讨对ES扩展过程中的性能有深远影响的关键概念: cluster state..

[译] 使用 Docker 和 Elasticsearch 搭建全文本搜索引擎应用

- - IT瘾-dev
作者简介:Patrick Triest是一位全栈工程师,数据爱好者,持续学习者,洁癖编程者. 作者github地址为 https://github.com/triestpa,本文地址参见 https://blog.patricktriest.com. 本文源码可以在GitHub repository 中找到 - https://github.com/triestpa/guttenberg-search.

Elasticsearch 在各大互联网公司大量真实的应用案例

- -
国内现在有大量的公司都在使用 Elasticsearch,包括携程、滴滴、今日头条、饿了么、360安全、小米、vivo等诸多知名公司. 除了搜索之外,结合Kibana、Logstash、Beats,Elastic Stack还被广泛运用在大数据近实时分析领域,包括日志分析、指标监控、信息安全等多个领域.

[译]elasticsearch mapping

- - an74520的专栏
es的mapping设置很关键,mapping设置不到位可能导致索引重建. 请看下面各个类型介绍^_^. 每一个JSON字段可以被映射到一个特定的核心类型. JSON本身已经为我们提供了一些输入,支持 string,  integer/ long,  float/ double,  boolean, and  null..

Elasticsearch as Database - taowen - SegmentFault

- -
【北京上地】滴滴出行基础平台部招聘 Elasticsearch 与 Mysql binlog databus 开发工程师. 内推简历投递给: [email protected] 推销Elasticsearch. 时间序列数据库的秘密(1)—— 介绍. 时间序列数据库的秘密(2)——索引.