gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

月度归档8月 2020

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  2020   /  
  • 8月
Elasticsearch 8月 31,2020

Elsticsearch 数据查询流程

Elasticsearch在存储数据的时候默认是根据每条记录的_id字段做路由分发的,这意味着es服务端是准确知道每个document分布在那个shard上的。

相对比于CURD上操作,search一个比较复杂的执行模式,因为我们不知道那些document会被匹配到,任何一个shard上都有可能,所以一个search请求必须查询一个索引或多个索引里面的所有shard才能完整的查询到我们想要的结果。

找到所有匹配的结果是查询的第一步,来自多个shard上的数据集在分页返回到客户端的之前会被合并到一个排序后的list列表,由于需要经过一步取top N的操作,所以search需要进过两个阶段才能完成,分别是query和fetch。

如下图所示:

(一)query(查询阶段)

当一个search请求发出的时候,这个query会被广播到索引里面的每一个shard(主shard或副本shard),每个shard会在本地执行查询请求后会生成一个命中文档的优先级队列。

这个队列是一个排序好的top N数据的列表,它的size等于from+size的和,也就是说如果你的from是10,size是10,那么这个队列的size就是20,所以这也是为什么深度分页不能用from+size这种方式,因为from越大,性能就越低。

es里面分布式search的查询流程如下:

1,客户端发送一个search请求到Node 3上,然后Node 3会创建一个优先级队列它的大小=from+size

2,接着Node 3转发这个search请求到索引里面每一个主shard或者副本shard上,每个shard会在本地查询然后添加结果到本地的排序好的优先级队列里面。

3,每个shard返回docId和所有参与排序字段的值例如_score到优先级队列里面,然后再返回给coordinating节点也就是Node 3,然后Node 3负责将所有shard里面的数据给合并到一个全局的排序的列表。

上面提到一个术语叫coordinating node,这个节点是当search请求随机负载的发送到一个节点上,然后这个节点就会成为一个coordinating node,它的职责是广播search请求到所有相关的shard上,然后合并他们的响应结果到一个全局的排序列表中然后进行第二个fetch阶段,注意这个结果集仅仅包含docId和所有排序的字段值,search请求可以被主shard或者副本shard处理,这也是为什么我们说增加副本的个数就能增加搜索吞吐量的原因,coordinating节点将会通过round-robin的方式自动负载均衡。

(二)fetch(读取阶段)

query阶段标识了那些文档满足了该次的search请求,但是我们仍然需要检索回document整条数据,这个阶段称为fetch。

流程如下:

1,coordinating 节点标识了那些document需要被拉取出来,并发送一个批量的mutil get请求到相关的shard上。

2,每个shard加载相关document,如果需要他们将会被返回到coordinating 节点上。

3,一旦所有的document被拉取回来,coordinating节点将会返回结果集到客户端上。

作者 east
Elasticsearch 8月 31,2020

Elsticsearch 数据写入流程

前言

由于Elasticsearch使用Lucene来处理shard级别的索引和查询,因此数据目录中的文件由Elasticsearch和Lucene共同编写。

Lucene负责编写和维护Lucene索引文件,而Elasticsearch在Lucene之上编写与功能相关的元数据,例如字段映射,索引设置和其他集群元数据,用户和支持功能由Elasticsearch提供。

ES数据

Node Data

只需启动ES就会有生成下面的目录树:

node.lock:为了确保一次只有一个ES应用从这个数据目录读取/写入。

global-0.st:global-prefix表示这是一个全局状态的文件,而.st扩展名表示这是一个包含元数据状态的文件。这个二进制文件是包含集群的全局元数据,前缀后的数字表示集群元数据版本,这是一个严格增加的版本控制方案。版本号跟随集群而变。

不要去编辑这些文件,因为有可能会导致数据丢失。

Index Data

当我们创建index,文件目录发生变化:

此时可以看出,已经创建了与索引名称对应的新目录。目录有两类子文件夹:_state和0.。

_state包含state-{version}.st索引状态文件,包含了索引的元数据,例如:创建的时间戳。还包含唯一标识符以及索引的settings和mappings。

数字0表示的shard编号,这个文件夹包含了shard相关的数据。

Shard Data

_state目录包含shard的状态文件,其中包含版本控制以及有关分片是主分片还是副本的信息。

index目录包含Lucene拥有的文件。ES通常不直接写入此文件夹。这些文件构成了ES数据目录的大小。

translog:ES事物日志。ES事物日志确保数据可以安全的写入到索引中,而无需为每个文档执行Lucene commit。提交Lucene index会产生一个新的segment,即fsync()-ed,会导致大量的磁盘I/O,从而影响性能。

Lucene数据

Lucene文件如下表所示:

Name Extension Brief Description
Segemnts File segments_N 存储lucene数据文件的元信息,记录所有segment的元数据信息。主要记录了当前有多少个segment,每个segment有一些基本信息,更新这些信息能定位到每个segment的元信息文件。
Lock File write.lock 防止多个IndexWriters写入同一个文件
Segement Info .si 存储有关段的元数据
Compound File .cfs,.cfe 一个segment包含了如下表的各个文件,为减少打开文件的数量,在segment小的时候,segment的所有文件内容都保存在cfs文件中,cfe文件保存了lucene各文件在cfs文件的位置信息
Fields .fnm 存储fileds的相关信息
Fields Index .fdx 正排存储文件的元数据信息
Fields Data .fdt 存储了正排存储数据,写入的原文存储在这
Term Dictionary .tim 倒排索引的元数据信息
Term Index .tip 倒排索引文件,存储了所有的倒排索引数据
Frequencies .doc 保存了每个term的doc id列表和term在doc中位置
Positions .pos 全文索引的字段,会有该文件,保存了term在doc中的位置
Playloads .pay Stores additional per-position metadata information such as character offsets and user payloads全文索引的字段,使用了一些像payloads的高级特性会有该文件,保存了term在doc中的一些高级特性
Norms .nvd,.nvm 存储索引字段加权数据
Per-Document Values .dvd,.dvm Lucene的docvalues文件,即列式存储,用作聚合和排序
Term Vector Data .tvx,.tvd,.tvf 保存索引字段的矢量信息,用在对term进行高亮,计算文本相关性中使用
Live Documents .liv 记录了segment中删除的doc

数据写入流程

1.segment file: 存储倒排索引的文件,每个segment本质上就是一个倒排索引,每秒都会生成一个segment文件,当文件过多时es会自动进行segment merge(合并文件),合并时会同时将已经标注删除的文档物理删除;

2.commit point(重点理解): 记录当前所有可用的segment,每个commit point都会维护一个.del文件(es删除数据本质是不属于物理删除),当es做删改操作时首先会在.del文件中声明某个document已经被删除,文件内记录了在某个segment内某个文档已经被删除,当查询请求过来时在segment中被删除的文件是能够查出来的,但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉;

3.translog日志文件: 为了防止elasticsearch宕机造成数据丢失保证可靠存储,es会将每次写入数据同时写到translog日志中。

translog的写入也可以设置,默认是request,每次请求都会写入磁盘(fsync),这样就保证所有数据不会丢,但写入性能会受影响;如果改成async,则按照配置触发trangslog写入磁盘,注意这里说的只是trangslog本身的写盘。

4. flush:translog什么时候清空?默认是512mb,或30分钟。这个动作就是flush,同时伴随着segment提交(写入磁盘)。flush之后,这段translog的使命就完成了,因为segment已经写入磁盘,就算故障,也可以从segment文件恢复。

5.fsync:另外,有一个/_flush/sync命令,在做数据节点维护时很有用。其逻辑就是flush translog并且将sync_id同步到各个分片。可以实现快速恢复。

综述:fsync指的是translog本身被写入磁盘的动作;flush指的是逻辑上的刷新,包含一系列逻辑操作。

其实flush API的作用是强制停止translog的fsync行为,提交segment并清除translog。间隔要尽量大一点(需要优化写速度的话,就稍微调大一点flush间隔。)

作者 east
Elasticsearch 8月 31,2020

Elasticsearch写入性能调优

bulk批量写入

如果业务场景支持将一批数据聚合起来,一次性写入Elasticsarch,那么尽量采用bulk的方式,bulk批量写入的速度远高于一条一条写入大量document的速度。

并不是bulk size越大越好,而是根据写入数据量具体来定的,因为越大的bulk size会导致内存压力过大,因此最好一个请求不要发送超过10MB的数据量,以5-10MB为最佳值。计算公式为:

一次bulk写入的数据量大小=一次bulk批量写入的文档数*每条数据量的大小。

多线程写入

单线程发送bulk请求是无法最大化Elasticsearch集群写入的吞吐量的。如果要利用集群的所有资源,就需要使用多线程并发将数据bulk写入集群中。多线程并发写入同时可以减少每次底层磁盘fsync的次数和开销。

一旦发现ES返回了TOO_MANY_REQUESTS的错误,JavaClient也就是EsRejectedExecutionException。此时说明Elasticsearch已经达到了一个并发写入的最大瓶颈了。

推荐使用CPU核数的2倍线程数。

修改索引刷新时间及副本数

默认“index.refresh_interval”为“1s”,即每秒都会强制生成1个新的segments文件,增大索引刷新时间,可以生成更大的segments文件,有效降低IO并减少segments merge的压力,该配置项可以建索引时指定(或者配置到template里去)。

如果只是单纯导入数据,不需要做实时查询,可以把refresh禁用(即设置index.refresh_interval为-1),并设置“index.number_of_replicas”为“0”,当然这样设置会有数据丢失风险。等到数据完成导入后,再把参数设置为合适的值。

命令为单索引下操作如下所示,同时也支持多索引(索引名按逗号分隔)和全索引(用*通配符)操作。

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex/_settings" -H 'Content-Type: application/json' -d'
{
    "number_of_replicas": 0,
    "refresh_interval": "180s"
}'

修改事务日志translog参数

默认设置下,translog 的持久化策略是每个请求都flush(durability参数值为request),这样能保证写操作的可靠性,但是对性能会有很严重的影响,实际测试发现如果使用默认设置进行导数据磁盘IO会持续占满。如果系统可以接受一定几率的数据丢失(或有手段补录丢失数据),可以通过调整 translog 持久化策略、周期性和一定大小的时候 flush,能大大提升导入性能。该配置项可以建索引时指定(或者配置到template里去)。执行命令如下所示:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex/_settings" -H 'Content-Type: application/json' -d'
{
"index": {
    "translog": {
          "flush_threshold_size": "1GB",
          "sync_interval": "180s",
          "durability": "async"
          }
     }
}'

备注:数据丢失风险

参数描述清楚

修改merge参数以及线程数

Elasticsearch写入数据时,refresh刷新会生成1个新的segment,segments会按照一定的策略进行索引段合并merge。merge的频率对写入和查询的速度都有一定的影响,如果merge频率比较快,会占用较多的IO,影响写入的速度,但同时segment个数也会比较少,可以提高查询速度。所以merge频率的设定需要根据具体业务去权衡,同时保证写入和查询都相对快速。Elasticsearch默认使用TieredMergePolicy,可以通过参数去控制索引段合并merge的频率:

  1. 参数“index.merge.policy.floor_segment”,Elasticsearch避免产生很小的segment,小于这个阀值的所有的非常小的segment都会merge直到达到这个floor的size,默认是2MB。
  2. 参数“index.merge.policy.max_merge_at_once”,一次最多只merge多少个segments,默认是10。
  3. 参数“index.merge.policy.max_merged_segment”,超过多大size的segment不会再做merge,默认是5g。
  4. 参数“index.merge.policy.segment_per_tier”默认为10,表示每个tier允许的segment个数,注意这个值要大于等于“index.merge.policy.max_merge_at_once”值,否则这个值会先于最大可操作数到达,就会立刻做merge,这样会造成频繁merge。
  5. 参数“ index.merge.scheduler.max_thread_count ”,单个shard上可能同时合并的最大线程数。默认会启动 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)) 个线程进行merge操作,适用于SSD固态硬盘。但是如果硬盘是机械硬盘,很容易出现IO阻塞,将线程数设置为1。

一般情况下,通过调节参数“index.merge.policy.max_merge_at_once”和“index.merge.policy.segment_per_tier”去控制merge的频率。

参数修改 好处 坏处
提高“index.merge.policy.max_merge_at_once” 和“index.merge.policy.segment_per_tier”参数值(eg :50) 提升indexing速度 减少了segment merge动作的发生,意味着更多的segments,会降低searching速度
降低“index.merge.policy.max_merge_at_once” 和“index.merge.policy.segment_per_tier”参数值(eg :5) Segments更少,即能够提升searching速度 更多的segments merge操作,会花费更多系统资源(CPU/IO/RAM),会降低indexing速度

修改参数命令如下示例:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_settings?pretty" -H 'Content-Type: application/json' -d' {      "merge":{          "scheduler":{             "max_thread_count" : "1"          },          "policy":{               "segments_per_tier" : "20",               "max_merge_at_once": "20",               "floor_segment" : "2m",               "max_merged_segment" : "5g"          }       } }'


禁用Doc Values

禁用Doc Values

默认情况下,支持doc values 的所有字段都是开启的。因为 Doc Values 默认启用,可以选择对数据集里面的大多数字段进行聚合和排序操作。但是如果确定不需要在字段上进行排序和聚合,或从脚本中访问字段值,则可以禁用 doc values 来节省磁盘空间。

要禁用 Doc Values ,在字段的映射(mapping)设置 “doc_values”为“false”即可。例如,这里我们创建了一个新的索引,字段 “session_id” 禁用了 Doc Values:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "http://ip:httpport/myindex" -H 'Content-Type: application/json' -d'
{
"mappings": {
      "my_type": {
           "properties": {
                 "session_id": {
                         "type": "keyword",
                         "doc_values": false
                  }
            }
       }
    }
}'

禁用_source字段

“_source”字段包含在索引时传递的原始JSON文档正文。该“_source”字段本身不被索引(因此是不可搜索的),但它被存储,以便在执行撷取请求时可以返回,例如get或search。

虽然很方便,但是“_source”字段确实在索引中有不小的存储开销。因此,可以使用如下方式禁用:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/tweets?pretty' -H 'Content-Type: application/json' -d'
{
   "mappings": {
          "tweet": {
               "_source": {
                       "enabled": false
                 }
           }
     }
}'

说明: 在禁用_source 字段之前请注意:如果_source字段不可用,则不支持以下功能:

  • update,update_by_query,reindex APIs.
  • 高亮
  • 将索引从一个Elasticsearch索引reindex(重索引)到另一个索引的能力,以便更改映射或分析,或将索引升级到新的主要版本。
  • 通过查看索引时使用的原始文档来调试查询或聚合的能力。
  • 潜在的未来可能会自动修复索引损坏的能力。
作者 east
Elasticsearch 8月 31,2020

Elasticsearch查询性能调优

查询语句优化

查询语句优化的内容包括:查询范围,单次查询数量等。

  1. 根据实际业务需求去规划查询范围,查询越少的字段越快,过大的查询范围不仅会导致查询效率低,而且会使Elasticsearch集群资源耗费急剧增加,甚至可能造成集群崩溃。通过_source参数可以控制返回字段信息,尽量避免读取大字段;
  2. 单次查询数量限制是为了保证内存不会被查询内存大量占用,Elasticsearch默认的查询请求通常返回排序后的前10条记录,最多一次读取10000条记录。通过from和size参数控制读取记录范围,避免一次读取过多的记录。一次性查询大于10000条的数据,使用scroll查询,请参考3.7.6。

安全模式下查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty"  -H 'Content-Type: application/json' -d' 
{
  "from": 0,
  "size": 10,
  "_source": "age",
  "query": {
      "match": {
        "age": "56"
      }
  },
  "sort": [
    {
      "age": {
        "order": "asc"
      }
    }
  ]
}'

强制段合并(force merge)

每个shard是基于多个segment组成创建的,segment的个数的减少可以大幅的提高查询的速度,定时的进行手动索引段合并,可以提高查询速度。支持单索引和多索引批量操作。

单索引安全模式下示例:

curl -XPOST --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/myindex-001/_forcemerge?only_expunge_deletes=false&max_num_segments=1&flush=true&pretty'

多索引安全模式下示例:

curl -XPOST --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/myindex-001,myindex-002/_forcemerge?only_expunge_deletes=false&max_num_segments=1&flush=true&pretty'
curl -XPOST --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/_all/_forcemerge?only_expunge_deletes=false&max_num_segments=1&flush=true&pretty'

说明:

max_num_segments:merge到多少个segments,1的意思是强行merge到1个segment;

only_expunge_deletes:只清理有deleted标记的segments,推荐值false;

flush:清理完执行一下flush,默认是true。

过滤查询(filter)

Elasticsearch的查询操作分为2种:查询(query)和过滤(filter),查询(query)默认会计算每个返回文档的得分,然后根据得分排序;而过滤(filter)只会筛选出符合的文档,并不计算得分,且可以缓存文档。

对于非全文检索的使用场景,如果不关心查询结果和查询条件的相关度,只是想查找目标数据,可以使用filter来提高查询效率。

query安全模式下查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "age": "56"
    }
  }
}'

filter安全模式下查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty" -H 'Content-Type: application/json' -d' {   "query": {     "bool": {       "filter": {          "match": {           "age": "56"         }       }     }   } }'

路由(routing)

Elasticsearch写入文档时,文档会通过一个公式路由到一个索引中的一个分片上。默认公式如下:

shard_num = hash(_routing) % num_primary_shards

_routing字段的取值,默认是_id字段,可以根据业务场景设置经常查询的字段作为路由字段。例如可以考虑将用户id、地区作为路由字段,查询时可以过滤不必要的分片,加快查询速度。

安全模式下写入时指定路由:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/my_index/my_type/1?routing=user1&refresh=true" -H 'Content-Type: application/json' -d' 
{
  "title": "This is a document"
}'

安全模式下查询时不指定路由示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/my_index/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "title": "document"
    }
  }
}'

需要查询所有的分片,返回结果:

{
  "took" : 5,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 0.2876821,
    "hits" : [
      {
        "_index" : "my_index",
        "_type" : "my_type",
        "_id" : "1",
        "_score" : 0.2876821,
        "_routing" : "user1",
        "_source" : {
          "title" : "This is a document"
        }
      }
    ]
  }
}

安全模式下查询时指定路由示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/my_index/_search?routing=user1&pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "title": "document"
    }
  }
}'

查询时只需要查询一个分片,查询结果:

{
  "took" : 8,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 0.2876821,
    "hits" : [
      {
        "_index" : "my_index",
        "_type" : "my_type",
        "_id" : "1",
        "_score" : 0.2876821,
        "_routing" : "user1",
        "_source" : {
          "title" : "This is a document"
        }
      }
    ]
  }
}

游标查询(scroll)

Elasticsearch为了避免深分页,不允许使用分页(from&size)查询10000条以后的数据,需要使用游标(scroll)查询。

安全模式下scroll查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?scroll=1m&pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "age": "36"
    }
  },
  "size":1000
}'

说明:

使用scroll查询,应该在初始搜索请求中指定scroll参数,这个参数告诉Elasticsearch保持游标窗口期多长时间。例如:scroll=1m,表示1分钟。

结果返回:

{
  "_scroll_id" : "DnF1ZXJ5VGhlbkZldGNoMgAAAAAAAABPFlFHZzExcFdnUWJDU0d5bU==",
  "took" : 55,
  "timed_out" : false,
  "_shards" : {
    "total" : 50,
    "successful" : 50,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 16692062,
    "max_score" : 0.0,
    "hits" : [...1000 data ]
  }
}

优化scroll:在一般场景下,scroll用来取得排序好的大量数据,但很多时候只需要返回数据,这时候可以对scroll进行优化。使用_doc去sort返回的结果不会有排序,此时执行效率最快。

安全模式下示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?scroll=1m&pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "age": "36"
    }
  },
  "size":1000,
  "sort": "_doc"
}'

避免使用wildcard模糊匹配查询

Elasticsearch默认支持通过*?正则表达式来做模糊匹配,数据量级别达到TB+甚至更高之后,模糊匹配查询通常会耗时比较长,甚至可能导致内存溢出,卡死乃至崩溃宕机的情况。所以数据量大的情况下,不要使用模糊匹配查询。

安全模式下模糊匹配查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "wildcard" : {
	"name" : "*优" 
	}
  }
}'

聚合优化

大多时候对单个字段的聚合查询还是比较快的,但是当需要聚合多个字段时,就会产生大量的分组,最终结果就是占用Elasticsearch大量的内存,从而导致内存溢出的情况发生。尽量根据业务优化,减少聚合次数。

默认深度优化聚合改为广度优先聚合

添加设置:”collect_mode”: “breadth_first”。

depth_first:直接进行子聚合的计算。

breadth_first:先计算出当前聚合的结果,针对这个结果在对子聚合进行计算。

优化聚合执行方式

在每一层terms aggregation内部加一个 “execution_hint”: “map”。

添加设置:”execution_hint”: “map”。

  1. 查询结果直接放入到内存中构建map,在查询结果集小的场景下,速度极快;
  2. 但如果查询结果集合很大(百万-亿级别)的时候,传统聚合方式会比map方式快。

安全模式下聚合查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "size" : 0,
  "aggregations": {
    "count_age" : {
	"terms" : {
		   "field" : "age"
		} 
	}
  }
}'

安全模式下聚合优化后查询示例:

curl -XGET --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_search?pretty" -H 'Content-Type: application/json' -d'
{
  "size" : 0,
  "aggregations": {
    "count_age" : {
	"terms" : {
		   "field" : "age",
		   "execution_hint": "map",
		   "collect_mode": "breadth_first"
		} 
	}
  }
}'

配置EsClient角色(协调节点)

EsClient角色可以用于发送查询请求到其他节点,收集和合并结果,以及响应发出查询的客户端。通过配置EsClient角色可以加快查询运算速度,提升缓存命中数。

mappings优化

请确认mappings设置是否合理。

  • 对于只需要精确查询的字段,例如时间戳,应该设置为keyword。
  • 对需要进行全文检索的字段设置合理的分词器,不同的分词器查询效率相差较大。

超时参数

在对查询结果的精确度要求较低的场景下,如果低响应时间比搜索结果更重要,可以使用如下两个参数来提升查询性能:

  1. terminate_after:表示每个分片收集的文档的最大数量,一旦达到该数量,查询请求提前终止。
  2. timeout:表示每个分片上的查询超时时间,在请求超时之前,Elasticsearch将会返回已经成功从每个分片上获取的结果。 安全模式下使用示例 : curl -XGET –tlsv1.2 –negotiate -k -v -u : “https://ip:httpport/_search?pretty&timeout=10ms&terminate_after=10″
作者 east
Elasticsearch 8月 31,2020

ES常见性能问题与解决方案

常见性能问题与解决方案

当前性能问题很多是硬件资源限制,或者是配置使用不合理,再或者是集群部署不合理,常见问题如下:

  1. 全文检索场景下查询速度慢问题。 分析:对全索引,全字段进行全文检索,发现查询速度很慢。通过集群状态分析发现,index数和shard数偏多,规划不合理,同时索引分片数设置不合理。通过查询慢日志发现,提取阶段需要合并大量的结果,导致整个查询时间慢。 解决方案:关闭swap交换内存,重新规划索引的shard个数,定时的进行索引段合并减少集群segment个数。
  2. 写入数据达到一定量时,指定ID导致读IO很高问题。 分析:在EsNode节点上执行iotop命令,发现大量Elasticsearch线程的磁盘读速率高。通过线程堆栈信息发现,在索引bulk命令的写入流程中,由于写入请求指定文档ID,需要先做一次全量查询,确认该index是否存在指定的文档ID,这个查询过程占用大量的磁盘读IO。 解决方案:业务测进行调整,写入数据时不指定文档ID,而是将其作为一个index字段。

针对性能问题首先排查系统部署是否合理,然后查看硬件资源是否达到瓶颈,结合客户的查询特点,有针对性的利用第3节的调优参数进行调整。

查看日志信息,排查系统后台是否有报错,根据错误信息针对具体问题分析性能不达标的根本原因。

日志分类介绍:

当前Elasticsearch各个实例的日志保存在“${BigdataLogHome}/elasticsearch/${Rolename}”和“${BigdataLogHome}/audit/elasticsearch/${Rolename}”目录下。

  • 安装日志如下:
日志文件名 分析描述
es-postinstall.log Elasticsearch安装日志
es-start.log Elasticsearch启动日志
es-stop.log Elasticsearch停止日志
  • 运行日志如下:
日志文件名 分析描述
elasticsearch_cluster.log Elasticsearch集群日志,实例运行日志
es-process-check.log Elasticsearch健康检查日志
es-sevice-check.log Elasticsearch服务检查日志
elasticsearch_cluster_index_indexing_slowlog.log Elasticsearch索引慢日志
elasticsearch_cluster_index_search_slowlog.log Elasticsearch查询慢日志
es-gc.log Elasticsearch实例的GC日志
elasticsearch_cluster-audit.log 记录对索引级别的操作,比如迁移shard,删除索引等
  • 开启慢日志: 默认的情况下,Elasticsearch的查询慢日志和索引慢日志是没有启用的。需要通过设置日志的级别(warn, info, debug, trace)和阀值来开启慢日志。 首先设置日志级别,如下所示将日志级别设置为debug:curl -XPUT –tlsv1.2 –negotiate -k -v -u : ‘https://ip:httpport/_cluster/settings?pretty’ -H ‘Content-Type: application/json’ -d’ { “transient”: { “logger.index.indexing.slowlog”:”DEBUG”, “logger.index.search.slowlog”:”DEBUG” } }’ 设置完日志级别后需要分别设置查询慢日志和索引慢日志的对应日志级别下的阀值,可以在elasticsearch.yml文件里定义这些阀值。没有阀值设置的索引会自动继承在静态配置文件里配置的参数。同时也提供动态API的方式来设置。
    1. 查询慢日志 shard级别的查询慢日志会将慢查询(查询和获取阶段)记录到elasticsearch_cluster_index_search_slowlog.log日志中。 设置查询慢日志各种级别下的阀值,同时也支持多索引(索引名按逗号分隔)和全索引(用*通配符)操作。curl -XPUT –tlsv1.2 –negotiate -k -v -u : ‘https://ip:httport/myindex-001/_settings?pretty’ -H ‘Content-Type: application/json’ -d’ { “index.search.slowlog.threshold.query.warn”: “10s”, “index.search.slowlog.threshold.query.info”: “5s”, “index.search.slowlog.threshold.query.debug”: “2s”, “index.search.slowlog.threshold.query.trace”: “500ms”, “index.search.slowlog.threshold.fetch.warn”: “1s”, “index.search.slowlog.threshold.fetch.info”: “800ms”, “index.search.slowlog.threshold.fetch.debug”: “500ms”, “index.search.slowlog.threshold.fetch.trace”: “200ms”, }’ 说明: index.search.slowlog.threshold.query.*:对应日志级别下的阀值,查询阶段慢于该阀值即打印日志。 index.search.slowlog.threshold.fetch.*:对应日志级别下的阀值,提取阶段慢于该阀值即打印日志。
    2. 索引慢日志 设置索引慢日志各种级别下的阀值,同时也支持多索引(索引名按逗号分隔)和全索引(用*通配符)操作。curl -XPUT –tlsv1.2 –negotiate -k -v -u : ‘https://ip:httpport/myindex-001/_settings?pretty’ -H ‘Content-Type: application/json’ -d’ { “index.indexing.slowlog.threshold.index.warn”: “10s”, “index.indexing.slowlog.threshold.index.info”: “5s”, “index.indexing.slowlog.threshold.index.debug”: “2s”, “index.indexing.slowlog.threshold.index.trace”: “500ms”, “index.indexing.slowlog.source”: “1000” }’ 说明: index.indexing.slowlog.threshold.index.*:对应日志级别下的阀值,索引时间慢于该阀值即打印日志。 index.indexing.slowlog.source:Elasticsearch默认将在慢索引日志中记录_source的前1000个字符,将其设置为false或0将完全跳过记录源,设置为true将记录整个源。
作者 east
运维 8月 23,2020

lnmp一键安装包重新安装mysql

安装mysql好长时间,一直没去管,后来一直频繁重启,各种网上找方案去解决,最后问题太异常,一顿操作猛如虎之后把mysql彻底搞垮,无奈只能进行重装。

#whereis mysql

#mysql: /usr/bin/mysql /usr/lib/mysql /usr/include/mysql /usr/local/mysql

找到五个目录

rm -rf /usr/bin/mysql 五个目录依次删除

然后就可以安装,新的MYSQL了,INIT 启动下的就不用删了,如果还要安装的话,

目前提供了较多的MySQL、MariaDB版本和不安装数据库的选项,需要注意的是MySQL 5.6,5.7及MariaDB 10必须在1G以上内存的更高配置上才能选择!如仅需安装数据库在lnmp安装包目录下执行:

./install.sh db

加上这个DB 就只安装数据库了,别的NGINX就不安 装了

杀死以前安装的mysql进程,然后重启就可以啦

lnmp restart

查看进程

ps -ef|grep mysql

强制杀死进程4328

kill -s 9 4328

作者 east

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (43)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (488)
    • CDH (6)
    • datax (4)
    • doris (30)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (40)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (99)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (70)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (6)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.