elasticsearch原理_花几分钟看一下Elasticsearch原理解析与性能调优

最新推荐文章于 2022-12-30 18:53:18 发布
最新推荐文章于 2022-12-30 18:53:18 发布
阅读量142 收藏 1
点赞数
文章标签： elasticsearch原理

基本概念

定义

  • 一个分布式的实时文档存储，每个字段 可以被索引与搜索
  • 一个分布式实时分析搜索引擎
  • 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据

用途

  • 全文检索
  • 结构化搜索
  • 分析

VS传统数据库

  • 传统数据库提供精确匹配
  • ES提供精确匹配全文检索处理同义词给文档相关性评分生成分析与聚合数据实时

专有名词

  • 索引(名词)类似于数据库
  • 索引(动词)类似于insert。例如索引一个文档到一个索引
  • 倒排索引默认每个属性都会有一个倒排索引，可以设置属性不被索引，它只能被覆盖，不能被修改
  • 类型类似表，同一索引的不同类型，可以拥有不同的字段，但应该拥有大部分相似的字段。它可以包含大小写，不能包含句号，不能以下划线开头，长度限制为256.
  • Id文档的id，可以在生成文档时指定或自动生成，自动生成的ID，在大部分情况下多个节点的时候唯一。如果在创建文档时，ID冲突，服务器会返回409
  • 文档类似于记录，文档只能被替换，而不能被修改，文档的字段类型需要一致，否则无法进行精确匹配
  • 精确值字段对于数字，日期，布尔和一个not_analyzed字段，进行查询，会适用精确匹配
  • 全文搜索字段否则，进行相关性搜索
PUT /megacorp/employee/1{    "first_name" : "John",    "last_name" :  "Smith",    "age" :        25,    "about" :      "I love to go rock climbing",    "interests": [ "sports", "music" ]}

例如

  • megacorp是索引
  • employee是类型
  • 1是文档id
  • json内容是文档

交互

RESTful API

curl -X '://:/?' -d ''

VERB适当的 HTTP 方法 或 谓词 : GET、 POST、 PUT、 HEAD 或者 DELETE。PROTOCOLhttp 或者 https(如果你在 Elasticsearch 前面有一个 https 代理)HOSTElasticsearch 集群中任意节点的主机名，或者用 localhost 代表本地机器上的节点。PORT运行 Elasticsearch HTTP 服务的端口号，默认是 9200 。PATHAPI 的终端路径(例如 _count 将返回集群中文档数量)。Path 可能包含多个组件，例如：_cluster/stats 和 _nodes/stats/jvm 。QUERY_STRING任意可选的查询字符串参数 (例如 ?pretty 将格式化地输出 JSON 返回值，使其更容易阅读)BODY一个 JSON 格式的请求体 (如果请求需要的话)

例子

request:

curl -XGET 'http://localhost:9200/_count?pretty' -d '{    "query": {        "match_all": {}    }}'

response:

{    "count" : 0,    "_shards" : {        "total" : 5,        "successful" : 5,        "failed" : 0    }}

检索文档功能

  • 获取一个文档GET /megacorp/employee/1
  • 简单查询GET /megacorp/employee/_search #查询前十条记录 GET /megacorp/employee/_search?q=last_name:Smith #查询smith的前十条记录
  • 表达式查询GET /megacorp/employee/_search { "query" : { "match" : { "last_name" : "Smith" } } } GET /megacorp/employee/_search { "query" : { "bool": { "must": { "match" : { "last_name" : "smith" } }, "filter": { "range" : { "age" : { "gt" : 30 } } } } } }
  • 全文检索GET /megacorp/employee/_search { "query" : { "match" : { "about" : "rock climbing" } } }
  • 短语查询GET /megacorp/employee/_search { "query" : { "match_phrase" : { "about" : "rock climbing" } } }
  • 分析(类似于聚合group by)request:GET /megacorp/employee/_search { "aggs" : { "all_interests" : { "terms" : { "field" : "interests" }, "aggs" : { "avg_age" : { "avg" : { "field" : "age" } } } } } } response: ... "all_interests": { "buckets": [ { "key": "music", "doc_count": 2, "avg_age": { "value": 28.5 } }, { "key": "forestry", "doc_count": 1, "avg_age": { "value": 35 } }, { "key": "sports", "doc_count": 1, "avg_age": { "value": 25 } } ] }
  • 修改文档PUT /website/blog/123 { "title": "My first blog entry", "text": "I am starting to get the hang of this...", "date": "2014/01/02" } 旧文档不会马上删掉新文档会被索引文档的version会加一
  • 删除文档DELETE /megacorp/employee/123 文档的version依然会加一

分布式特性

ES自动执行的分布式动作

  • 分配文档到不同的容器 或 分片 中，文档可以储存在一个或多个节点中
  • 按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡
  • 复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失
  • 将集群中任一节点的请求路由到存有相关数据的节点
  • 集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复

水平扩展VS垂直扩展

ES对水平扩展是友好的，通过购置更多的机器，可以更好的使用ES的分布式功能

集群

集群拥有一个或多个节点，当有节点加入或者退出集群时，集群会重新平均分配所有数据的分布

主节点功能

  • 增加/删除索引
  • 增加/删除节点不涉及文档的变更和搜索，因此单一的主节点不会成为集群的性能瓶颈

索引分片的元数据在每个ES节点都有存储，每个节点在接到请求后，都知道到哪台ES node找到数据，通过转发请求到ES node所在的机器

一个分片的最大文档数：(2^31-128)

一个索引的主分片数在建立时被确定，且无法修改：因为文档的存储是用shard = hash(routing) % number_of_primary_shards来确定文档的位置的。routing默认是id，也可以自定义

分片的副本数可以随时修改

建立索引

PUT /blogs{   "settings" : {      "number_of_shards" : 3,      "number_of_replicas" : 1   }}
9ed3287c22dadf65bc8e641ca3e4750e.png

故障转移

增加一台机器到集群

7b455fec6d42ed2f4f0082ebe8b37dd2.png

删除节点

2512a9d64867163d17acbed47b3178de.png

分布式写入冲突

e6444120d90966a184a95329becbe1ca.png


对于多个client的写入ES，有可能造成写入冲突，导致数据的丢失

在一些场景下，数据丢失是可以接受的

但是在某些场景下，是不允许的。

悲观控制并发

传统数据库的控制方式。通过对记录加锁，来实现并发的串行执行

乐观并发控制

ES采用乐观控制

所谓乐观控制，就是服务器假设大部分情况下，是不会发生冲突的，如果发生冲突，则拒绝修改，客户端可以需要通过重新获取并重试进行处理。

过程如下图

49b0a5f09ef081326268230eb181b968.png

分布式文档存储

确定文档位于那个shard

shard = hash(routing) % number_of_primary_shards

API支持带routing参数，来自定义路由，来确保相关文档路由到同一个分片

以ID新建，写入和删除文档

bc173b3ecbad2ede7e5b3d37194489a1.png

一致性保证

  • none: 主分片活跃，允许写入
  • all: 在所有分片活跃，允许写入
  • quorum: 半数以上节点活跃，允许写入

如果暂时没有足够的分片活跃，ES会等待，默认等待1分钟，可以通过参数timeout改变这个值，如果超时，则失败返回

新索引默认有 1 个副本分片，这意味着为满足 规定数量 应该 需要两个活动的分片副本。 但是，这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有当 number_of_replicas 大于1的时候，规定数量才会执行。

以ID检索文档

与上图类似

以ID更新文档

与上图类似，但在更新完文档后，会重建索引

在局部更新文档的时候，主分片会以整份文档来同步给副本，来保证数据的完整性

通过条件获取多个文档

a4848a9e87e22aceda4c103ca5451c4d.png

搜索

返回特殊字段

GET /_search
{   "hits" : {      "total" :       14,      "hits" : [        {          "_index":   "us",          "_type":    "tweet",          "_id":      "7",          "_score":   1,          "_source": {             "date":    "2014-09-17",             "name":    "John Smith",             "tweet":   "The Query DSL is really powerful and flexible",             "user_id": 2          }       },        ... 9 RESULTS REMOVED ...      ],      "max_score" :   1   },   "took" :           4,   "_shards" : {      "failed" :      0,      "successful" :  10,      "total" :       10   },   "timed_out" :      false}
  • took执行的毫秒数
  • _shards查询分片的状态，例如有几个分片是失败的，几个是成功的
  • timeout可以通过在查询设定超时，如果查询超过时间，则只返回已经成功获得的数据，剩余的数据将丢弃
  • _index数据来源的Lucene索引，文档的每一个字段，都拥有一个不同的Lucene索引在查询中可以指定Lucene的索引，默认是不指定的，所以会查询该文档的所有索引，并汇总结果。如果指定，则会限定仅在指定的Lucene索引中查询数据

分页

GET /_search?size=5&from=5

此方式只适用于浅分页，如果查询过深，会导致严重的性能问题。

因为例如查询size为5，from=10000。那么ES会从各分片中都查询10005条记录，如果有100个shard，那么就会有100*10005条记录，ES再对这100*10005排序，并仅返回5条记录

深分页

使用游标scroll

它在ES中建立了一个有有效期的快照，提供给scroll进行数据的深度查询

倒排索引

对一下文档进行倒排：

  1. The quick brown fox jumped over the lazy dog
  2. Quick brown foxes leap over lazy dogs in summer

得到：

Term      Doc_1  Doc_2-------------------------Quick   |       |  XThe     |   X   |brown   |   X   |  Xdog     |   X   |dogs    |       |  Xfox     |   X   |foxes   |       |  Xin      |       |  Xjumped  |   X   |lazy    |   X   |  Xleap    |       |  Xover    |   X   |  Xquick   |   X   |summer  |       |  Xthe     |   X   |------------------------

倒排面临的挑战

  • Quick跟quick，用户有可能认为它们是相同的，也有可能认为是不同的
  • dog和dogs非常接近，在相关性搜索时，它们应该都被搜索到
  • jump和leap是同义词，在相关性搜索时，它们应该都被搜索到

理解相关性

相关性的分数是一个模糊的概念。没有精确值，没有唯一正确的答案。是一种根据各种规则对文档进行的一种量化的估计。

它评分的准则如下：

  • 检索词频率检索词在该字段出现的频率越高，分数越高
  • 反向文档频率检索词在索引出现的频率越高，分数越低
  • 字段长度准则字段的长度越长，分数越低

相关性破坏

在使用全文检索某个关键字的时候，会出现，相关度低的文档的得分高于相关度高的文档的得分。

例如检索词milk。索引内有两个主分片，milk在P1出现了5次，在P2出现了6次。由于P1和P2的词分布不一样。

P1的词量比P2的词量高，那么milk算在P1出现占比小，导致在P1得相关性得分高，而在P2，占比da，导致在P2的相关性得分低。

原因

是因为局部数据分布不均匀导致的

解决方法

  • 插入更多的文档
  • 使用?search_type=dfs_query_then_fetch进行全局评分。但会有严重的性能问题。不推荐使用。

查询过滤bitset

每次使用检索词查询，都会为检索词建立一个bitset，bitset包含了匹配的文档的序号。在热搜索的检索词，ES会对这些bitset有针对的进行缓存，而不用在再次查询的时候，重新查找倒排索引。

对于多个查询可以有下图

f4c600712fad7adca66d5cac70639bbc.png

当倒排索引重建的时候，bitset在缓存会自动失效

缓存的策略

  • 最近256次被使用的bitset，会被缓存
  • 段内记录小于1w的，不会被缓存

索引管理

创建索引

可以显式创建，也可以隐式创建。

在大集群下，索引的创建，涉及元数据的同步，有可能导致集群负载的大量增加。此时需要禁用索引的隐式创建

action.auto_create_index: false

删除索引

删除索引，会涉及大量数据的删除，如果用户意外地试图通过一条命令，把所有索引删掉，这可能导致可怕的后果

通过禁用此操作，可以设置如下

action.destructive_requires_name: true

分析器

每个索引都可以设置自己的分析器，分析器的用途主要是在全文索引上面，通过对不同的语言，使用不同的分词，不同的词转换来构造倒排索引和计算相关性。

分片

倒排索引的不变性

好处

  • 一旦被读入系统缓存，就会一直留在那里，直到LRU算法把不常用的倒排索引剔除。这对ES的读取性能提供了非常大的提升

不好

  • 新的文档加入，不能增量更新，只能重建索引并替换

如何保证新数据能实时能查询到

用更多的索引。

对于新的文档，不马上重建索引，而是通过新增额外的索引。在查询数据时，通过轮询所有的索引，并合并结果返回。

5f3eae24d5546787407c2560226c0195.png

ES并不是严格意义上的实时，准确来说是准实时，由于data从插入到建立倒排索引这段时间，新数据是不能访问的

聚合

像数据库的group by。只是语法不一样。功能相通

应用层性能调优

调大 refresh interval

默认刷新时间是1s，每次刷新都会有一次磁盘写入，并创建一个新的段。通过设置更大的刷新时间，可以让磁盘写入的次数更低，写入的段更大。减少段合并的次数。

禁止OS把ES置换出去

OS的内核会在内存紧张的时候，把进程置换到外村。而对于性能跟内存强相关的ES来说，置换到外存是致命的。通过设置进程在内核的参数，禁止置换，可以避免OS的这种动作

预留大量的文件系统缓存给ES

由于ES大部分数据的不变性，使得ES的大部分磁盘操作，都可以通过文件系统的缓存来加快速度。一旦ES的倒排索引和数据缓存到系统，如果没有其他进程的干扰，而且是比较频繁访问的数据，则会一直驻留在系统缓存，使得ES的大部分操作都是走内存的。一般来说，分配一半的内存给文件系统，是合适的。

使用自动生成ID

如果指定ID，ES会在集群内检查是否ID已经存在，这对大集群来说，是昂贵的。如果ID是自动生成的，ES会跳过检查，直接插入文档

更好的硬件

  • 更大的内存
  • SSD
  • 本地磁盘

不要使用join关联查询

ES不适合做关联查询，会导致严重的性能问题。

如果业务一定要join，可以把关联的数据都写到一个索引内，或者通过应用程序来做关联的动作。

强制merge只读索引

merge成一个单一的段，会得到更好的性能

增加副本

有更多的机器，通过提高副本数，可以提高读效率

不要返回大数据

ES不适合这场景

避免稀疏

不要把不相关的信息存入同一个索引

数据预热

对于热点数据，可以通过一个客户端请求ES，让数据先占据filesystem cache。

冷热数据分离

冷热数据部署在不同的机器，可以让热数据在缓存内不会被冷数据冲走

内核层性能调优

限流

如果ES出现高负载的请求，ES的协调节点会累积大量的请求在内存在等待处理，随着请求数的增加，协调节点的内存占用会越来越大，最后导致OOM。

通过限流，可以有效缓解。

大查询

如果客户端发来了一个复杂的查询，使得需要返回的数据异常的大，这也会导致OOM问题。

通过修改内核，让如果请求的内存占用超过系统可以承受的范围，则截断来解决

FST过大引发OOM

FST是对倒排索引在内存的索引，它通过前缀状态机的方法，快速的定位检索词在倒排索引的磁盘位置，达到减少磁盘访问次数而加快检索速度的目的。

但由于FST是常驻内存的，如果倒排索引达到一定规模时，FST必然会引起OOM问题。而且FST是存放在JVM堆内内存的。堆内内存的上限时32G。

而10 TB的数据就需要10G到15G的内存来存放FST。

  • 通过把FST的存储放到堆外内存
  • 通过LRU算法来管理FST，对不常用的FST置换出内存
  • 修改ES访问FST的逻辑，使得ES可以从堆内直接访问堆外的FST
  • 在堆内增加FST的cache，加快命中速度

作者：谭英智

来源：https://www.cnblogs.com/kukafeiso/p/13947142.html

weixin_39922147
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Elasticsearch实战与原理解析 源代码.zip
06-06
Elasticsearch实战与原理解析 源代码
ElasticSearch + 架构解析 + 最佳实践
07-22
内核原理 、架构解析、最佳实践、调优实战
ES内存那点事
热门推荐
很多时候，你缺少的不是知识而是热情
01-13 1万+
“该给ES分配多少内存？”  “JVM参数如何优化?“ “为何我的Heap占用这么高？” “为何经常有某个field的数据量超出内存限制的异常？“ “为何感觉上没多少数据，也会经常Out Of Memory？” 以上问题，显然没有一个统一的数学公式能够给出答案。 和数据库类似，ES对于内存的消耗，和很多因素相关，诸如数据总量、mapping设置、查询方式、查询频度等等。默认的设置虽开
Elasticsearch 可搜索快照技术原理及最 佳实践
cloudbigdata的博客
12-29 919
Elasticsearch 可搜索快照的技术原理
Elasticsearch关联关系
u011356878的博客
09-27 431
原文地址http://www.54288.top/article/view.do?articleId=129 原文地址http://www.54288.top/article/view.do?articleId=129 原文地址http://www.54288.top/article/view.do?articleId=129 原文地址http://www.54288.top/art...
Elasticsearch7.17 六 :ES高级功能和数据建模
admin522043032的博客
06-23 813
关系型数据库范式化（Normalize）设计的主要目标是减少不必要的更新，往往会带来一些副作用：反范式化(Denormalize)的设计不使用关联关系，而是在文档中保存冗余的数据拷贝。关系型数据库，一般会考虑Normalize 数据；在Elasticsearch，往往考虑Denormalize 数据。 Elasticsearch并不擅长处理关联关系，一般会采用以下四种方法处理关联：案例1： 博客作者信息 当我们查询博客信息的同时需要知道作者信息，那么把作者信息当成一个对象放到博客信息当中 案例2：包含对象数
Elasticsearch之join关联查询
星空的风fly
11-19 1万+
Elasticsearch提供了类似于SQL JOIN的关联查询，通过has_child/has_parent可以实现一对多关系的父子表数据查询。但是其损耗也是比较大的，在使用的时候要根据分片数量的多少和预估数量量级的大小，提前做好性能测试
elasticsearch_ES_Elasticsearch界面_elasticsearch_源码
10-04
一个搜索框架的管理界面项目，可以监控管理相关的微服务
es与solr的区别_solr_ES_es与solr的区别_elasticsearch_
10-03
详细介绍了Elasticsearch 和 solr 的区别；是一道经典的java面试题
ElasticSearch工作原理.pptx
03-16
本文章以PPT的形式，详细展示了elastic search的工作原理、存储、及注意事项，如shard分片原理及设计、相关插件、与solr比较
查询亿级数据毫秒级返回！牛逼哄哄的ElasticSearch是如何做到的？
石杉的架构笔记
06-09 3682
点击上方石杉的架构笔记，右上角选择“设为星标”每日早8点半，技术文章准时送上公众号后台回复“学习”，获取作者独家秘制精品资料往期文章BAT 面试官是如何360°无死角考察...
Elasticsearch处理表关联关系的N种方式
nandao158的博客
12-30 3887
Elasticsearch处理表关联关系的N种方式
elasticsearch原理_Elasticsearch原理解析与性能优化
weixin_39849894的博客
11-30 121
基本概念定义一个分布式的实时文档存储，每个字段 可以被索引与搜索一个分布式实时分析搜索引擎能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据用途全文检索结构化搜索分析VS传统数据库传统数据库提供精确匹配ES提供精确匹配全文检索处理同义词给文档相关性评分生成分析与聚合数据实时专有名词索引（名词）类似于数据库索引（动词）类似于insert。例如索引一个文档到一个索引倒排索引默认每个...
Elasticsearch集群内的原理
aiduo4911的博客
05-07 89
一个运行中的 Elasticsearch 实例称为一个 节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。 当一个节点被选举成为 主 节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需...
elasticsearch 快照介绍
goodluck_mh的博客
05-02 2013
快照用于保存运行着的elasticsearch 集群中运行的数据，可以将一个或多个 index 保存到 repository(仓库中)，同一个 repo 的不同快照之间的数据是增量添加的，也就是说snap_1 ,之后再创建 snap_2 ,那么snap_2 只保存 snap_1 和 snap_2 之间的增量数据。因此可以比较高效的保存数据了。 保存起来的 snapshot 通过 restore ...
Elasticsearch快照备份
南宫乘风-Linux运维-虚拟化容器-Python编程 ownit.top
11-13 1936
快照是增量的，可以包含在多个ES版本中创建的索引。如果在一个快照中的任何索引时在不兼容的ES版本中创建的，你将不能恢复该快照。在升级前备份数据的时候，如果快照中的索引是在与你升级版本不兼容的ES版本中创建的，那么这些快照将不能被恢复。如果你的情况是需要恢复一个与你当前运行的集群版本不兼容的索引快照，你可以先恢复到最新的兼容版本中，然后在当前版本中使用 reindex-from-remote 重建索引。远程Reindexing只能在源索引source为enabled的情况下进行。
Elasticsearch性能优化总结
yht520100的专栏
11-29 1392
Elasticsearch是目前大数据领域最热门的技术栈之一，经过近8年的发展，已从0.0.X版升级至6.X版本，虽然增加了很多的特性和功能，但是在主体架构上，还是没有太多的变化。下面就把我对于ES使用实践的一些经验总结一下，供大家参考；也请大家拍砖。 一、 硬件环境选择： 如果有条件，尽可能使用SSD硬盘， 不错的CPU。ES的厉害之处在于ES本身的分布式架构以及lucene的特性。IO的提升，会极大改进ES的速度和性能。 二、系统拓朴设计： ES集群在架构拓朴时，一般都会采用Hot-Warm的架
【ES】ES中的join方案一（Nested类型，基于6.3版本的java实现）
lsr40的博客
10-09 3939
菜鸡一只，国庆真是玩了好几天，等到快上班的时候才开始又学习，找状态 本文来讲讲ES中的Join方案！ 在数据库中，join是非常常见的操作！ 其实就是将两张表的数据合并到一起，然后查询出结果数据，当然最后可能还需要一些过滤，这是数据库中的概念 在ES中也有join的方案，ES提供了两种api： 1、使用Nested结构存储（查询）数据 2、通过设置字段的type为join，然后使...
duckula之三(duckula对es的join类型的支持)
偏锋书生的专栏
12-29 559
前言   互联网体系架构具有可控性差、 数据量大、 架构复杂等特点，错综复杂的各业务模块需要解耦，各异构数据需要同步，双活/多活的容灾方案需要高实时性 等，在各种场合都需要一套可靠的数据实时推送方案。mysql已成为互联网项目存储的主力，围绕着它的各外围模块急需实时地获取它的数据，binlog监听是解决此实时同步问题的不二之选。 使用场景   duckula可以做到mysql到ES的增量和全量的同...
max_result_window会影响es性能_ElasticSearch读写底层原理及性能调优
最新发布
05-12
除了max_result_window，还有其他的Elasticsearch性能调优技巧，例如： 1. 使用合适的硬件配置，尤其是内存和磁盘 2. 使用合适的索引设置，例如合适的分片大小和副本数量 3. 使用合适的查询语法和查询参数 4. ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值