内容简介:马云演讲中曾经提到:很多时候少听成功专家的话。所有的创业者多花点时间学习别人是怎么失败的,因为成功的原因有千千万万,创业需要关注别人的失败,而开发实战,别人的错误经验、别人的问题也非常有价值。开发
题记
马云演讲中曾经提到:很多时候少听成功专家的话。所有的创业者多花点时间学习别人是怎么失败的,因为成功的原因有千千万万, 失败的原因就一两个点 。
创业需要关注别人的失败,而开发实战,别人的错误经验、别人的问题也非常有价值。
开发 最懊悔的事 莫过于:自己费尽脑汁、花费了很长时间解决了问题,原来别人在社区或者别的地方早已经给出了更优化的方案。
开发 最最懊悔的事 莫过于:别人已经给出了方案,但是我们仍然在黑暗中苦逼的摸索。
因此,我从2018年4月——至今,每月都会梳理出了Elasticsearch中文社区的精华干货——简称: Elastic错题本 ,
问题大多来自Medcl、wood大叔等大牛的精彩回复,结合实战严选的核心问题,必要的地方,我增加了注释+解读, 放在了GitHub上。
GitHub地址: http://t.cn/Ec8IvKA
目的:提前加深认知,少重复走别人的弯路!
1、kibana根据历史数据预测未来数据
Elastic 的机器学习功能刚好就能做
https://www.elastic.co/products/stack/machine-learning
2、es查询问题。
另外你要注意一下 Lucene 的语法规则:
https://lucene.apache.org/core/2_9_4/queryparsersyntax.html
a+(D|d) 这里 a 是可选,括号内的必要的。如果要 a 是必要条件,加号要放前面。如果是两个关键字直接是任意满足的关系,一般是用||。另外注意括号的全角和半角。
如:+a +(c||d)
3、【重要】关于elasticsearch中filter的粒度的疑问
推荐阅读: https://elasticsearch.cn/question/6667
filter是单个缓存的,不过对于term 类型的filter是否缓存要看版本。
因为term filter开销很小,所以从5.1.1之后不再做缓存。
filter上下文中的查询是独立被cache的,所以按照你给的例子,应该是三个。
相关的资料
在这里: http://t.cn/Ec8fRPc
只不过从5.1.1版本以后开始,term query不会被cache了。
其他类型的query,比方说range query,各种geo的query依然会被cache起来。 这点只有在5.1.1的release notes有提及。
4、ES2.3版本,delete一个索引,master日志并没有记录相关delete操作?
【原因】
1PUT _cluster/settings 2{ 3 "persistent": { 4 "logger.cluster.service": "DEBUG" 5 } 6}
打开 cluster.service的debug ,能看到创建、删除索引的日志
低版本地址:
https://www.elastic.co/guide/en/elasticsearch/guide/current/logging.html
高版本地址;
https://www.elastic.co/guide/en/elasticsearch/reference/6.6/logging.html
5、【重要】es gc overhead 报错
通过scroll方式查询时,特别注意要设置游标有效时间不能太久,
例如scroll=30min,过期时间越长对应数据保存在ES内存中就越久,ES内存越大。
srcoll查询完后要及时调用 clearScroll(scrollId)
来清理对应游标数据。
https://elasticsearch.cn/question/6578
6、es5.5版本,当文档字段是1100多个的时候,报异常
Limit of total fields [1000] in index [nfvoemspm] has been exceeded
修改settings
1{ 2"index.mapping.total_fields.limit": 2000 3}
话说真的需要这么多字段放在一起吗,能不能从设计上优化一下。
7、Elasticsearch技术栈选型推荐
https://elasticsearch.cn/question/6676
方案1: SpringBoot+Thymeleaf+RestHighLevelClient
方案2:SpringBoot
简单的语句用String.format复杂语句用Freemarker
然后用RestHighLevelClient甚至直接自己包装一个HttpClient
结合ES自己的template使用
git封装参考:https://github.com/godlockin/searchHandler
8、【警惕】数据丢失啦
https://elasticsearch.cn/question/6650
问题:今天发现ES 服务器上所有机器的所有数据都消失了。 没有进行过任何操作。
求教有什么原因可以导致这种结果.不管是正常的非正常的,能给个指教就是好事。
运维同学抓破头也没找到问题出在哪
【根因】:运维人员通过head插件把 相关index删除 了,而且是愤世嫉俗一般的全部删掉。 现在我更关心如何做安全策略
推荐阅读: 你的Elasticsearch在裸奔吗?
【注意事项】
1.是否暴露了公网访问
2.是否有团队/公司里其他人知道地址
3.检查一下数据导入的脚本有没有重启、oom、做过滤…
4.差不差钱,不差钱的买个xpack做安全策略,差钱就内网隔离部署+黑白名单,亡羊补牢犹未晚矣
5.rerun一下数据导入脚本进行数据修复
6.找到原因了之后不管多妖或者多蠢,都记得回来这里发个帖子,详细的聊聊整个issue的前因后果
7、先看一下数据路径里面的数据是否正常;
8、看一下是否开启了
通配符数据删除;
9、看一下 ES 日志,从中找是否集群启停过之类的操作
10、确认下磁盘是不是满了,导致的异常或者磁盘路径的问题
9、有关es forceMerge问题
https://elasticsearch.cn/question/6563
通过Kibana观察到 每次强制给某个索引合并段时 都会发现该索引的所占空间会跟随段合并暴涨一倍;
现在问题是这样的;磁盘空间所剩的空间 不足以撑起某个要合并段的索引的体积的两倍大小
那么这个索引是不是就不能合并了 如果仍执行强制合并段 会发生什么?
回复:es的合并,是将要合并的segment读取出来,再写入到新的segment,然后删除老的segment,所以,消耗大量的资源和磁盘空间。
你这样的情况, 建议加大磁盘 ,或者限制索引合并的线程数量,减小每次合并的segment数量。
10、beats如何通过配置删除host字段
最近在做日志采集,发现filebeat和winlogbeat采集日志的时候,会有host这个字段,但是是个object字段,es里日志索引host是text类型,想在agent里直接通过参数把host字段,可以做到么?看了下配置,好像没有找到
你可以通过添加 processors 实现字段过滤的功能,例如
1processors: 2 - drop_fields: 3 when: 4 condition 5 fields: ["field1", "field2", ...]
具体请参考:
https://www.elastic.co/guide/en/beats/filebeat/current/defining-processors.html11、有没有 ngram 和 wildcard 折中方案?
https://elasticsearch.cn/question/6733
想支持英文的部分搜索,比如 good,搜索oo也可以匹配出来。这就需要 ngram,但是 ngram 使得 index 占用空间10X+增大,有点无法接受。wildcard 搜索效率又实在太低。有什么折中方案么?
你可以试试前缀搜索
good 你分词为 good/ood/od/
这样使用前缀搜索就可以实现你需要的效果;
同时设置一下 mapping,可进一步加快搜索速度
1"index_prefixes": { 2 "min_chars": 1, 3 "max_chars": 10 4 }
12、 logstash吞吐量太低了怎么优化呢?
https://elasticsearch.cn/question/6739
Logstash 性能调优主要参数
1pipeline.workers:
设置启动多少个线程执行 fliter 和 output;
当 input 的内容出现堆积而 CPU 使用率还比较充足时,可以考虑增加该参数的大小;
1pipeline.batch.size:
设置单个工作线程在执行过滤器和输出之前收集的最大事件数,较大的批量大小通常更高效,但会增加内存开销。输出插件会将每个批处理作为一个输出单元。;
例如,ES 输出会为收到的每个批次发出批量请求;调整 pipeline.batch.size 可调整发送到 ES 的批量请求(Bulk)的大小;
1pipeline.batch.delay:
设置 Logstash 管道的延迟时间, 管道批处理延迟是 Logstash 在当前管道工作线程中接收事件后等待新消息的最长时间(以毫秒为单位);
简单来说,当 pipeline.batch.size 不满足时,会等待 pipeline.batch.delay 设置的时间,超时后便开始执行 filter 和 output 操作。
请根据具体情况,调整 batch.size 或者 works 的数量
https://elasticsearch.cn/question/6739
13、请教一个多索引字段比对查询写法的问题
想要实现的功能例子如下:
有2个索引: company person
里面都包含goods和price字段
需要查询出来company和persion中当goods字段的值一样时price字段的值不一样的数据,目前没有头绪,请问该怎样写呢。
对 goods 字段进行 termsAgg,然后设置其子聚合为对 _index 的 termsAgg 子聚合,并设置 min_doc_count 为 2;
最后设置 _index 的子聚合为 topHits,这样就可以找到你需要的数据。
1{ 2 "size": 0, 3 "query": { 4 "match_all": { 5 "boost": 1.0 6 } 7 }, 8 "aggregations": { 9 "goods": { 10 "terms": { 11 "field": "goods", 12 "size": 10000, 13 "min_doc_count": 1, 14 "shard_min_doc_count": 0, 15 "show_term_doc_count_error": false, 16 "order": [{ 17 "_count": "desc" 18 }, { 19 "_key": "asc" 20 }], 21 "collect_mode": "breadth_first" 22 }, 23 "aggregations": { 24 "index": { 25 "terms": { 26 "field": "_index", 27 "size": 10, 28 "min_doc_count": 2, 29 "shard_min_doc_count": 0, 30 "show_term_doc_count_error": false, 31 "order": [{ 32 "_count": "desc" 33 }, { 34 "_key": "asc" 35 }] 36 }, 37 "aggregations": { 38 "top": { 39 "top_hits": { 40 "from": 0, 41 "size": 100, 42 "version": false, 43 "explain": false 44 } 45 } 46 } 47 } 48 } 49 } 50 } 51}
14、search_after的SearchAfterBuilder使用范例:
search_after 这个功能;
例如你现在需要安装 id 和 time 进行排序;
你获取了第一页的结果后,现在需要获取第二页内容
你需要使用第一页最后一条的 id 和 time,作为 search_after 的参数chuan传递到查询请求中。
下面是样例:
1SearchAfterBuilder searchAfterBuilder = new SearchAfterBuilder(); 2searchAfterBuilder.setSortValues(new Object[]{"上一页的ID", "上一页的时间"});
15、ES数据恢复,从red恢复到yellow速度很快,从yellow到green恢复很慢
https://elasticsearch.cn/question/6714
red恢复的时候是从本地加载之前的索引文件,没有从别的地方同步,所以比较快。
yellow恢复成GREEN的时候,很大部分都可能是从主shard同步数据,在6.x之前,通常都会很慢。
6.x之后由于translog机制的变更可能会变快,但这里还要考虑集群在恢复的时候可能会自己 做reblance ,同样涉及到shard跨节点的搬迁
16、ElasticSearch java api,想要实现一次请求查询多个类型的同时,每个类型只取固定数量的数据
最近在做系统的搜索功能,在一个索引下建了一些不同的类型。
页面上的全局搜索功能是要求展示所有类型的数据。
一开始想的是按找类型发起请求,每个类型一次,只取几条数据。
但是发现查全部类型的时候,虽然单个类型的数据查询已经解析工作只需要几十毫秒,但全部执行完就需要一秒左右了。
所以想要实现只请求一次,查询所有类型的数据,并且每个类型只取固定数量的数据。
请问java api能实现这样的功能吗?
【实现】
换一种思路,这么实现一下,能满足你的要求。
1POST weibo_index/weibo_type,weibo_cm_type/_search 2{ 3 "size": 0, 4 "query": { 5 "bool": { 6 "must": { 7 "match": { 8 "cont": "北京" 9 } 10 } 11 } 12 }, 13 "aggs": { 14 "type_aggs": { 15 "terms": { 16 "field": "_type", 17 "size": 2 18 }, 19 "aggs": { 20 "top_hits_aggs": { 21 "top_hits": { 22 "size": 5, 23 "_source": [ 24 "pt", 25 "url" 26 ] 27 } 28 } 29 } 30 } 31 } 32}
17、请问copy_to字段 和 mutil_fields哪种性能好一些呢?
https://elasticsearch.cn/question/6698
因为我们公司业务的原因,我们需要copy_to字段后,然后做全文检索,那么我想问一下大家,copy_to字段和直接mutil_field哪种性能更好一些呢?
【参考1】如果只是简单的全文搜索推荐使用 copy_to,性能更佳;
使用 mutil_field 的优点在于每个字段可用设置不同的权重,这样更有助于优化搜索结果排名;
此外 copy_to 会比 mutil_field 占用更多一些的存储
【参考2】
如果是全文检索,建议使用copy_to,使用更少的字段,性能会更好一些。如果只是对某个字段单独去做,就基本上没有什么差别。
18、ES重启后head插件显示粉红色
粉红色是分片relocating阶段正常的颜色变化,稍安勿躁,一会就好了。
粉红色表示分片在重新分配
如果只是临时重启机器,推荐配置分配延迟分配策略:
1PUT _all/_settings 2{ 3 "settings": { 4 "index.unassigned.node_left.delayed_timeout": "5m" 5 } 6}
【引申可能原因】:
好像硬盘出问题了吧。把副本调整下,再调整回来,让他重新分配下。1G应该是秒级恢复的。
19、【很有代表性问题】ES匹配度的打分问题
使用ES默认的打分规则(TF-IDF),搜索“葡萄糖”时,搜索结果中“纯净葡萄糖(食用葡萄糖)”比全匹配的“葡萄糖”的得分还要高。因为在前者中“葡萄糖”出现过两次。
但是我更想要全匹配的或匹配度更高的,而不关心出现的次数。对我来说,相比“纯净葡萄糖(食用葡萄糖)”,我希望“葡萄糖液”得分更好。
因为“葡萄糖液”中关键字占了3/4,即使前者出现两次“葡萄糖”。
我该怎么修改?是修改TF-IDF配置,或者修改打分算法,还是自定义打分规则?
【回复】
ES 支持关闭词频统计,设置 mapping 即可
1PUT /my_index 2{ 3"mappings": { 4 "doc": { 5 "properties": { 6 "text": { 7 "type": "string", 8 "index_options": "docs" 9 } 10 } 11 } 12} 13}
将参数 index_options 设置为 docs 可以禁用词频统计及词频位置,这个映射的字段不会计算词的出现次数,对于短语或近似查询也不可用。要求精确查询的 not_analyzed 字符串字段会默认使用该设置。
推荐阅读: https://blog.csdn.net/paditang/article/details/79098830
20、单索引大数据量,如何优化?
【问题】单索引当前已经存储1.5亿多文档,3节点5分片1副本,每个分片20G多。有定期删除老数据,但是预计在删除老数据前,可能最大存储文档达到24亿多。
当前想到的解决方案:
1、根据预估的最大24亿最大文档,对当前资源进行扩容。
但是根据之前的数据计算,应该如何合理分配分片?如何计算需要扩容几个节点满足要求?
2、使用rollover根据条件,索引太大后,写入数据切换至新索引,但是查询数据还是对全部索引进行查询。
这样可能是多索引,每个索引5分片1副本。
现在疑惑是哪种方案更合理?个人倾向于方案2,比较扩容也是需要成本。
但是方案2后续索引增加,分片增加后,每次查询是设置查询别名指向所有索引,这样查询性能是不是也会持续下降?
【回复】
这个推荐先在搜索压力小的时段对索引进行一次 ForceMerge,这样会之前已经删除的文档进行真正删除操作;
此外,如果搜索压力大的化,可以多增加一个副本,这样副本也可以分担搜索的压力;
别名
可以指定多个索引的某一个索引是可以写入数据的;
搜索的时候是全部索引一起搜索.
【铭毅回复】:
针对方案2:结合template+rollover+别名+curator可以解决问题,不存在性能问题。
相反,针对最新数据的索引,反而通过制定日期索引,会缩减检索样本空间,反而效率更高。
【进一步推进阅读】
6.6 版本索引生命管理
https://elasticsearch.cn/article/635821、推荐阅读新文章
自研基于StanfordNLP的ES分词插件
https://elasticsearch.cn/article/6341推荐:
重磅 | 死磕Elasticsearch方法论认知清单(2019春节更新版)
Elasticsearch基础、进阶、实战第一公众号
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Elastic 中文社区 201902 错题本
- 英国卫报迁移, MongoDB 躺枪背锅?MongoDB 中文社区有话说
- SpringCloud中文社区转型Spring4All欢迎您的加入
- http://ruster.xyz 实验上线,用 Rust 写的中文 Rust 社区
- Go语言错题整理(一)????
- 牛客网 Java专项练习 选择题错题 [4]
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。