elasticsearch索引量大怎么定时删除

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了elasticsearch索引量大怎么定时删除相关的知识,希望对你有一定的参考价值。

参考技术A 主要看数据量ES索引优化篇主要从两个方面解决问题,一是索引数据过程;二是检索过程。(本文主要介绍)索引数据过程我在上面几篇文章中有提到怎么创建索引和导入数据,但是大家可能会遇到索引数据比较慢的过程。其实明白索引的原理就可以有针对性的进行优化。ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡。所以从上我可以通过索引的settings进行第一优化:“index.translog.flush_threshold_ops”:“100000″“index.refresh_interval”:“-1″,这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的。所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡。第二参数是刷新频率,默认为120s是指索引在生命周期内定时刷新,一但有数据进来能refresh像lucene里面commit,我们知道当数据addDoucment会,还不能检索到要commit之后才能行数据的检索所以可以将其关闭,在最初索引完后手动refresh一之,然后将索引setting里面的index.refresh_interval参数按需求进行修改,从而可以提高索引过程效率。另外的知道ES索引过程中如果有副本存在,数据也会马上同步到副本中去。我个人建议在索引过程中将副本数设为0,待索引完成后将副本数按需量改回来,这样也可以提高索引效率。“number_of_replicas”:0上面聊了一次索引过程的优化之后,我们再来聊一下检索速度比较慢的问题,其实检索速度快度与索引质量有很大的关系。而索引质量的好坏与很多因素有关。一、分片数分片数,与检索速度非常相关的的指标,如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件别外也会导致多台服务器之间通讯。而分片数过少为导至单个分片索引过大,所以检索速度慢。在确定分片数之前需要进行单服务单索引单分片的测试。比如我之前在IBM-3650的机器上,创建一个索引,该索引只有一个分片,分别在不同数据量的情况下进行检索速度测试。最后测出单个分片的内容为20G。所以索引分片数=数据总量/单分片数目前,我们数据量为4亿多条,索引大小为近1.5T左右。因为是文档数据所以单数据都中8K以前。现在检索速度保证在100ms以下。特别情况在500ms以下,做200,400,800,1000,1000+用户长时间并发测试时最坏在750ms以下.二、副本数副本数与索引的稳定性有比较大的关系,怎么说,如果ES在非正常挂了,经常会导致分片丢失,为了保证这些数据的完整性,可以通过副本来解决这个问题。建议在建完索引后在执行Optimize后,马上将副本数调整过来。大家经常有一个误去副本越多,检索越快,这是不对的,副本对于检索速度其它是减无增的我曾做过实现,随副本数的增加检索速度会有微量的下降,所以大家在设置副本数时,需要找一个平衡值。另外设置副本后,大家有可能会出现两次相同检索,出现出现不同值的情况,这里可能是由于tranlog没有平衡、或是分片路由的问题,可以通过?preference=_primary让检索在主片分上进行。三、分词其实分词对于索引的影响可大可小,看自己把握。大家越许认为词库的越多,分词效果越好,索引质量越好,其实不然。分词有很多算法,大部分基于词表进行分词。也就是说词表的大小决定索引大小。所以分词与索引膨涨率有直接链接。词表不应很多,而对文档相关特征性较强的即可。比如论文的数据进行建索引,分词的词表与论文的特征越相似,词表数量越小,在保证查全查准的情况下,索引的大小可以减少很多。索引大小减少了,那么检索速度也就提高了。四、索引段索引段即lucene中的segments概念,我们知道ES索引过程中会refresh和tranlog也就是说我们在索引过程中segmentsnumber不至一个。而segmentsnumber与检索是有直接联系的,segmentsnumber越多检索越慢,而将segmentsnumbers有可能的情况下保证为1这将可以提到将近一半的检索速度。$curl-XPOST‘_optimize?only_expunge_deletes=true本回答被提问者采纳

Elasticsearch索引定时清理

问题

近期,kibana页面上出现Elasticsearch plugin is red错误信息,重启elasticsearch后又频繁出现该问题,观察elasticsearch发现各节点之间出现连接超时的现象.

解决方法

怀疑是索引条目太多,导致Elasticsearch性能下降造成的,通过查询api发现大量索引是yellow状态:
curl -XGET ‘http://127.0.0.1:9200/_cat/indices/?v

yellow open   user_audit-2018-08-08 Lx5YlsSxSDW7Z6dKwHLy4Q   5   1        159            0    265.5kb        265.5kb
yellow open   user_audit-2018-04-18 Rz7opEo7Tn-mfBsc0SyrDg   5   1        619            0    614.6kb        614.6kb
yellow open   net_switch-2017-11-18 7RZBwJGES1Ck2SI6Zsc_mA   5   1      16504            0      3.7mb          3.7mb
yellow open   user_audit-2018-06-07 _mapb6GpRkKP4bNqxI0tkg   5   1        130            0    212.4kb        212.4kb
yellow open   net_switch-2018-02-02 HL-saNdaSiuvDBfLyGNgrg   5   1        190            0    246.1kb        246.1kb
yellow open   user_audit-2018-01-05 BXO_atQmTl-ud_KCiHnSvw   5   1        288            0    309.1kb        309.1kb
yellow open   user_audit-2018-04-11 lDn7O9ZcRoKO4NwPArPcWg   5   1        166            0      243kb          243kb
yellow open   net_switch-2018-03-29 F7UeMBvZTou1n0OeZJjbyg   5   1        191            0    334.2kb        334.2kb
yellow open   domain_log-2018-07-07 b2hg9sIFSE-Pm6DHom7Q6Q   5   1   11742465            0      5.3gb          5.3gb
yellow open   user_audit-2018-05-12 g1q6jrWtQYaagoUbSigRsw   5   1         23            0    185.4kb        185.4kb
yellow open   net_switch-2018-05-16 yQL5rwlvQD2whqASws1Yaw   5   1        182            0    311.2kb        311.2kb
yellow open   domain_log-2018-08-27 7kM3sl0nTNOPN0XbwmYULw   5   1   13788549            0      6.7gb          6.7gb
yellow open   domain_log-2018-07-06 hb5ZL-Z1Rk6DyhYXTBGnrw   5   1   10434848            0      4.8gb          4.8gb
yellow open   domain_log-2018-05-12 0Q8uLeSVTtW7GyGJNdd5FA   5   1   10753882            0      5.6gb          5.6gb
yellow open   user_audit-2018-05-22 ryLHjAhNS2-5kjqRjccH_A   5   1        653            0      680kb          680kb
yellow open   user_audit-2018-07-23 DSGn1gXTQaub35FS34z28g   5   1         36            0    235.1kb        235.1kb
yellow open   domain_log-2018-03-02 H54jaFt2Rgq-ktC81tROJw   5   1   17530752            0        9gb            9gb

一、api删除

curl -XDELETE ‘http://127.0.0.1:9200/domain_log-2018-*‘
清理掉了所有 2018年domain的索引文件

二、脚本加api删除(推荐)

cat ES-index-clear.sh

#/bin/bash
#指定日期(7天前)
DATA=`date -d "1 week ago" +%Y-%m-%d`

#当前日期
time=`date`

#删除7天前的日志
curl -XGET "http://127.0.0.1:9200/_cat/indices/?v"|grep $DATA
if [ $? == 0 ];then
  curl -XDELETE "http://127.0.0.1:9200/*-${DATA}"
  echo "于 $time 清理 $DATA 索引!"
fi

三、添加到任务计划

#每天定时清理索引
0 1 * * * /bin/sh /root/shscript/ES-index-clear.sh >> /root/shscript/log/es-index-clear.log

以上是关于elasticsearch索引量大怎么定时删除的主要内容,如果未能解决你的问题,请参考以下文章

elasticsearch(es)定时删除7天前索引

liunx 使用crontab定时任务+shell脚本删除tomcat日志elasticsearch日志索引

第六篇 elasticsearch express 删除索引数据

Elasticsearch索引定时清理

elastic search 索引

microsoft search索引缓存能不能删除