【精品学习资源】| Elasticsearch中文社区201901错题本

Love The Way You Lie 2021-09-18 09:38 219阅读 0赞

马云演讲中曾经提到：很多时候少听成功专家的话。所有的创业者多花点时间学习别人是怎么失败的，因为成功的原因有千千万万，**失败的原因就一两个点**。

创业需要关注别人的失败，而开发实战，别人的错误经验、别人的问题也非常有价值。

开发**最懊悔的事**莫过于：自己费尽脑汁、花费了很长时间解决了问题，原来别人在社区或者别的地方早已经给出了更优化的方案。

开发**最最懊悔的事**莫过于：别人已经给出了方案，但是我们仍然在黑暗中苦逼的摸索。

因此，我从2018年4月——至今，每月都会梳理出了Elasticsearch中文社区的精华干货——简称：**Elastic错题本**，  
问题大多来自Medcl、wood大叔等大牛的精彩回复，结合实战严选的核心问题。

放在了GitHub上。

GitHub地址：[https://github.com/laoyang360/deep\_elasticsearch/tree/master/es\_accumulate][https_github.com_laoyang360_deep_elasticsearch_tree_master_es_accumulate]

目的：提前加深认知，少重复走别人的弯路！

# 1、kibana根据历史数据预测未来数据 #

Elastic 的机器学习功能刚好就能做

[https://www.elastic.co/products/stack/machine-learning][https_www.elastic.co_products_stack_machine-learning]

# 2、es查询问题。 #

另外你要注意一下 Lucene 的语法规则：

[https://lucene.apache.org/core/2\_9\_4/queryparsersyntax.html][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][https_elasticsearch.cn_question_6667]

filter是单个缓存的，不过对于term 类型的filter是否缓存要看版本。  
因为term filter开销很小，所以从5.1.1之后不再做缓存。

filter上下文中的查询是独立被cache的，所以按照你给的例子，应该是三个。  
`相关的资料`在这里: [https://www.elastic.co/guide/cn/elasticsearch/guide/current/filter-caching.html\#\_独立的过滤器缓存][https_www.elastic.co_guide_cn_elasticsearch_guide_current_filter-caching.html]

只不过从5.1.1版本以后开始，term query不会被cache了。  
其他类型的query，比方说range query，各种geo的query依然会被cache起来。 这点只有在5.1.1的release notes有提及。

# 4、ES2.3版本，delete一个索引，master日志并没有记录相关delete操作？ #

【原因】

PUT _cluster/settings
    {
      "persistent": {
        "logger.cluster.service": "DEBUG"
      }
    }

打开cluster.service的debug，能看到创建、删除索引的日志

低版本地址：[https://www.elastic.co/guide/en/elasticsearch/guide/current/logging.html][https_www.elastic.co_guide_en_elasticsearch_guide_current_logging.html]

高版本地址;[https://www.elastic.co/guide/en/elasticsearch/reference/6.6/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][https_elasticsearch.cn_question_6578]

# 6、es5.5版本,当文档字段是1100多个的时候,报异常 #

Limit of total fields \[1000\] in index \[nfvoemspm\] has been exceeded

修改settings

{
    "index.mapping.total_fields.limit": 2000
    }

# 7、Elasticsearch技术栈选型推荐 #

[https://elasticsearch.cn/question/6676][https_elasticsearch.cn_question_6676]

方案1：SpringBoot+Thymeleaf+RestHighLevelClient

方案2：SpringBoot  
简单的语句用String.format复杂语句用Freemarker  
然后用RestHighLevelClient甚至直接自己包装一个HttpClient  
结合ES自己的template使用

git封装参考：[https://github.com/godlockin/searchHandler][https_github.com_godlockin_searchHandler]

# 8、【警惕】数据丢失啦 #

[https://elasticsearch.cn/question/6650][https_elasticsearch.cn_question_6650]

问题：今天发现ES 服务器上所有机器的所有数据都消失了。 没有进行过任何操作。  
求教有什么原因可以导致这种结果.不管是正常的非正常的，能给个指教就是好事。

运维同学抓破头也没找到问题出在哪

【根因】：运维人员通过head插件把相关index删除了，而且是愤世嫉俗一般的全部删掉。 现在我更关心如何做安全策略

推荐阅读：[https://blog.csdn.net/laoyang360/article/details/86347480][https_blog.csdn.net_laoyang360_article_details_86347480] 你的Elasticsearch在裸奔吗？

【注意事项】  
1.是否暴露了公网访问  
2.是否有团队/公司里其他人知道地址  
3.检查一下数据导入的脚本有没有重启、oom、做过滤…  
4.差不差钱，不差钱的买个xpack做安全策略，差钱就内网隔离部署+黑白名单，亡羊补牢犹未晚矣  
5.rerun一下数据导入脚本进行数据修复  
6.找到原因了之后不管多妖或者多蠢，都记得回来这里发个帖子，详细的聊聊整个issue的前因后果  
7、先看一下数据路径里面的数据是否正常；  
8、看一下是否开启了通配符数据删除；  
9、看一下 ES 日志，从中找是否集群启停过之类的操作  
10、确认下磁盘是不是满了，导致的异常或者磁盘路径的问题

# 9、有关es forceMerge问题 #

[https://elasticsearch.cn/question/6563][https_elasticsearch.cn_question_6563]

通过Kibana观察到 每次强制给某个索引合并段时 都会发现该索引的所占空间会跟随段合并暴涨一倍；

现在问题是这样的；磁盘空间所剩的空间 不足以撑起某个要合并段的索引的体积的两倍大小  
那么这个索引是不是就不能合并了 如果仍执行强制合并段 会发生什么？

回复：es的合并，是将要合并的segment读取出来，再写入到新的segment，然后删除老的segment，所以，消耗大量的资源和磁盘空间。  
你这样的情况，建议加大磁盘，或者限制索引合并的线程数量，减小每次合并的segment数量。

# 10、beats如何通过配置删除host字段 #

最近在做日志采集，发现filebeat和winlogbeat采集日志的时候，会有host这个字段，但是是个object字段，es里日志索引host是text类型，想在agent里直接通过参数把host字段，可以做到么？看了下配置，好像没有找到

你可以通过添加 processors 实现字段过滤的功能，例如

processors:
     - drop_fields:
         when:
            condition
         fields: ["field1", "field2", ...]

具体请参考：  
[https://www.elastic.co/guide/en/beats/filebeat/current/defining-processors.html][https_www.elastic.co_guide_en_beats_filebeat_current_defining-processors.html]

# 11、有没有 ngram 和 wildcard 折中方案？ #

[https://elasticsearch.cn/question/6733][https_elasticsearch.cn_question_6733]

想支持英文的部分搜索，比如 good，搜索oo也可以匹配出来。这就需要 ngram，但是 ngram 使得 index 占用空间10X+增大，有点无法接受。wildcard 搜索效率又实在太低。有什么折中方案么？

你可以试试前缀搜索  
good 你分词为 good/ood/od/  
这样使用前缀搜索就可以实现你需要的效果；  
同时设置一下 mapping，可进一步加快搜索速度

"index_prefixes": {
        "min_chars": 1,
        "max_chars": 10
      }

# 12、 logstash吞吐量太低了怎么优化呢？ #

[https://elasticsearch.cn/question/6739][https_elasticsearch.cn_question_6739]

Logstash 性能调优主要参数

pipeline.workers：

设置启动多少个线程执行 fliter 和 output；  
当 input 的内容出现堆积而 CPU 使用率还比较充足时，可以考虑增加该参数的大小；

pipeline.batch.size：

设置单个工作线程在执行过滤器和输出之前收集的最大事件数，较大的批量大小通常更高效，但会增加内存开销。输出插件会将每个批处理作为一个输出单元。；

例如，ES 输出会为收到的每个批次发出批量请求；调整 pipeline.batch.size 可调整发送到 ES 的批量请求（Bulk）的大小；

pipeline.batch.delay：

设置 Logstash 管道的延迟时间， 管道批处理延迟是 Logstash 在当前管道工作线程中接收事件后等待新消息的最长时间（以毫秒为单位）；

简单来说，当 pipeline.batch.size 不满足时，会等待 pipeline.batch.delay 设置的时间，超时后便开始执行 filter 和 output 操作。

请根据具体情况，调整 batch.size 或者 works 的数量

[https://elasticsearch.cn/question/6739][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，这样就可以找到你需要的数据。

{
    	"size": 0,
    	"query": {
    		"match_all": {
    			"boost": 1.0
    		}
    	},
    	"aggregations": {
    		"goods": {
    			"terms": {
    				"field": "goods",
    				"size": 10000,
    				"min_doc_count": 1,
    				"shard_min_doc_count": 0,
    				"show_term_doc_count_error": false,
    				"order": [{
    					"_count": "desc"
    				}, {
    					"_key": "asc"
    				}],
    				"collect_mode": "breadth_first"
    			},
    			"aggregations": {
    				"index": {
    					"terms": {
    						"field": "_index",
    						"size": 10,
    						"min_doc_count": 2,
    						"shard_min_doc_count": 0,
    						"show_term_doc_count_error": false,
    						"order": [{
    							"_count": "desc"
    						}, {
    							"_key": "asc"
    						}]
    					},
    					"aggregations": {
    						"top": {
    							"top_hits": {
    								"from": 0,
    								"size": 100,
    								"version": false,
    								"explain": false
    							}
    						}
    					}
    				}
    			}
    		}
    	}
    }

# 14、search\_after的SearchAfterBuilder使用范例： #

首先要理解 search\_after 这个功能；  
例如你现在需要安装 id 和 time 进行排序；  
你获取了第一页的结果后，现在需要获取第二页内容  
你需要使用第一页最后一条的 id 和 time，作为 search\_after 的参数chuan传递到查询请求中。

下面是样例：

SearchAfterBuilder searchAfterBuilder = new SearchAfterBuilder(); 
    searchAfterBuilder.setSortValues(new Object[]{"上一页的ID", "上一页的时间"});
    
     
      
       1
       2

# 15、ES数据恢复，从red恢复到yellow速度很快，从yellow到green恢复很慢 #

[https://elasticsearch.cn/question/6714][https_elasticsearch.cn_question_6714]

red恢复的时候是从本地加载之前的索引文件，没有从别的地方同步，所以比较快。  
yellow恢复成GREEN的时候，很大部分都可能是从主shard同步数据，在6.x之前，通常都会很慢。  
6.x之后由于translog机制的变更可能会变快，但这里还要考虑集群在恢复的时候可能会自己做reblance，同样涉及到shard跨节点的搬迁

# 16、ElasticSearch java api，想要实现一次请求查询多个类型的同时，每个类型只取固定数量的数据 #

最近在做系统的搜索功能，在一个索引下建了一些不同的类型。  
页面上的全局搜索功能是要求展示所有类型的数据。

一开始想的是按找类型发起请求，每个类型一次，只取几条数据。  
但是发现查全部类型的时候，虽然单个类型的数据查询已经解析工作只需要几十毫秒，但全部执行完就需要一秒左右了。  
所以想要实现只请求一次，查询所有类型的数据，并且每个类型只取固定数量的数据。  
请问java api能实现这样的功能吗？

【实现】

换一种思路，这么实现一下，能满足你的要求。

POST weibo_index/weibo_type,weibo_cm_type/_search
    {
      "size": 0,
      "query": {
        "bool": {
          "must": {
            "match": {
              "cont": "北京"
            }
          }
        }
      },
      "aggs": {
        "type_aggs": {
          "terms": {
            "field": "_type",
            "size": 2
          },
          "aggs": {
            "top_hits_aggs": {
              "top_hits": {
                "size": 5,
                "_source": [
                  "pt",
                  "url"
                ]
              }
            }
          }
        }
      }
    }

# 17、请问copy\_to字段 和 mutil\_fields哪种性能好一些呢？ #

[https://elasticsearch.cn/question/6698][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阶段正常的颜色变化，稍安勿躁，一会就好了。

粉红色表示分片在重新分配  
如果只是临时重启机器，推荐配置分配延迟分配策略：

PUT _all/_settings
    {
      "settings": {
        "index.unassigned.node_left.delayed_timeout": "5m"
      }
    }

【引申可能原因】：  
好像硬盘出问题了吧。把副本调整下，再调整回来，让他重新分配下。1G应该是秒级恢复的。

# 19、【很有代表性问题】ES匹配度的打分问题 #

使用ES默认的打分规则（TF-IDF），搜索“葡萄糖”时，搜索结果中“纯净葡萄糖(食用葡萄糖)”比全匹配的“葡萄糖”的得分还要高。因为在前者中“葡萄糖”出现过两次。  
但是我更想要全匹配的或匹配度更高的，而不关心出现的次数。对我来说，相比“纯净葡萄糖(食用葡萄糖)”，我希望“葡萄糖液”得分更好。  
因为“葡萄糖液”中关键字占了3/4，即使前者出现两次“葡萄糖”。  
我该怎么修改？是修改TF-IDF配置，或者修改打分算法，还是自定义打分规则？

【回复】

ES 支持关闭词频统计，设置 mapping 即可

PUT /my_index
    {
    "mappings": {
      "doc": {
        "properties": {
          "text": {
            "type":          "string",
            "index_options": "docs" 
          }
        }
      }
    }
    }

将参数 index\_options 设置为 docs 可以禁用词频统计及词频位置，这个映射的字段不会计算词的出现次数，对于短语或近似查询也不可用。要求精确查询的 not\_analyzed 字符串字段会默认使用该设置。

推荐阅读：[https://blog.csdn.net/paditang/article/details/79098830][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/6358][https_elasticsearch.cn_article_6358]

# 21、推荐阅读新文章 #

自研基于StanfordNLP的ES分词插件  
[https://elasticsearch.cn/article/6341][https_elasticsearch.cn_article_6341]

[https_github.com_laoyang360_deep_elasticsearch_tree_master_es_accumulate]: https://github.com/laoyang360/deep_elasticsearch/tree/master/es_accumulate
[https_www.elastic.co_products_stack_machine-learning]: https://www.elastic.co/products/stack/machine-learning
[https_lucene.apache.org_core_2_9_4_queryparsersyntax.html]: https://lucene.apache.org/core/2_9_4/queryparsersyntax.html
[https_elasticsearch.cn_question_6667]: https://elasticsearch.cn/question/6667
[https_www.elastic.co_guide_cn_elasticsearch_guide_current_filter-caching.html]: https://www.elastic.co/guide/cn/elasticsearch/guide/current/filter-caching.html#_%E7%8B%AC%E7%AB%8B%E7%9A%84%E8%BF%87%E6%BB%A4%E5%99%A8%E7%BC%93%E5%AD%98
[https_www.elastic.co_guide_en_elasticsearch_guide_current_logging.html]: https://www.elastic.co/guide/en/elasticsearch/guide/current/logging.html
[https_www.elastic.co_guide_en_elasticsearch_reference_6.6_logging.html]: https://www.elastic.co/guide/en/elasticsearch/reference/6.6/logging.html
[https_elasticsearch.cn_question_6578]: https://elasticsearch.cn/question/6578
[https_elasticsearch.cn_question_6676]: https://elasticsearch.cn/question/6676
[https_github.com_godlockin_searchHandler]: https://github.com/godlockin/searchHandler
[https_elasticsearch.cn_question_6650]: https://elasticsearch.cn/question/6650
[https_blog.csdn.net_laoyang360_article_details_86347480]: https://blog.csdn.net/laoyang360/article/details/86347480
[https_elasticsearch.cn_question_6563]: https://elasticsearch.cn/question/6563
[https_www.elastic.co_guide_en_beats_filebeat_current_defining-processors.html]: https://www.elastic.co/guide/en/beats/filebeat/current/defining-processors.html
[https_elasticsearch.cn_question_6733]: https://elasticsearch.cn/question/6733
[https_elasticsearch.cn_question_6739]: https://elasticsearch.cn/question/6739
[https_elasticsearch.cn_question_6714]: https://elasticsearch.cn/question/6714
[https_elasticsearch.cn_question_6698]: https://elasticsearch.cn/question/6698
[https_blog.csdn.net_paditang_article_details_79098830]: https://blog.csdn.net/paditang/article/details/79098830
[https_elasticsearch.cn_article_6358]: https://elasticsearch.cn/article/6358
[https_elasticsearch.cn_article_6341]: https://elasticsearch.cn/article/6341