constant_score的用處

當我們不關心檢索詞頻率TF（Term Frequency）對搜索結果排序的影響時，可以使用constant_score將查詢語句query或者過濾語句filter包裝起來。

檢索詞頻率：檢索詞在該字段出現的頻率。出現頻率越高，相關性也越高。字段中出現過5次要比只出現過1次的相關性高。

合理使用filters優化查詢

ElasticSearch支持多種不同類型的查詢方式，這一點大家應該都已熟知。但是在選擇哪個文檔應該匹配成功，哪個文檔應該呈現給用戶這一需求上，查詢并不是唯一的選擇。ElasticSearch 查詢DSL允許用戶使用的絕大多數查詢都會有各自的標識，這些查詢也以嵌套到如下的查詢類型中：

constant_score
filterd
custom_filters_score
那么問題來了，為什么要這么麻煩來使用filtering？在什么場景下可以只使用queries？ 接下來就試著解決上面的問題。
過濾器(Filters)和緩存
首先，正如讀者所想，filters來做緩存是一個很不錯的選擇，ElasticSearch也提供了這種特殊的緩存，filter cache來存儲filters得到的結果集。此外，緩存filters不需要太多的內存(它只保留一種信息，即哪些文檔與filter相匹配)，同時它可以由其它的查詢復用，極大地提升了查詢的性能。設想你正運行如下的查詢命令：

?

{"query" : {"bool" : {"must" : [{"term" : { "name" : "joe" }},{"term" : { "year" : 1981 }}]}} }

該命令會查詢到滿足如下條件的文檔：name域值為joe同時year域值為1981。這是一個很簡單的查詢，但是如果用于查詢足球運動員的相關信息，它可以查詢到所有符合指定人名及指定出生年份的運動員。

如果用上面命令的格式構建查詢，查詢對象會將所有的條件綁定到一起存儲到緩存中；因此如果我們查詢人名相同但是出生年份不同的運動員，ElasticSearch無法重用上面查詢命令中的任何信息。因此，我們來試著優化一下查詢。由于一千個人可能會有一千個人名，所以人名不太適合緩存起來；但是年份比較適合(一般year域中不會有太多不同的值，對吧？)。因此我們引入一個不同的查詢命令，將一個簡單的query與一個filter結合起來。

?

{"query" : {"filtered" : {"query" : {"term" : { "name" : "joe" }},"filter" : {"term" : { "year" : 1981 }}}} }

我們使用了一個filtered類型的查詢對象，查詢對象將query元素和filter元素都包含進去了。第一次運行該查詢命令后，ElasticSearch就會把filter緩存起來，如果再有查詢用到了一樣的filter，就會直接用到緩存。就這樣，ElasticSearch不必多次加載同樣的信息。

?

總結

以上是生活随笔為你收集整理的Elasticsearch查询性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。