本節(jié)書摘來自華章出版社《深入理解Elasticsearch（原書第2版）》一書中的第2章，第2.2節(jié)，作者[美]拉斐爾·酷奇（Rafal Ku）　馬雷克·羅戈任斯基（Marek Rogoziski），更多章節(jié)內(nèi)容可以訪問云棲社區(qū)“華章計(jì)算機(jī)”公眾號查看

2.2　查詢改寫

之前我們探討了評分機(jī)制，這些知識(shí)非常珍貴，特別是當(dāng)你嘗試改進(jìn)查詢相關(guān)性時(shí)。我們還認(rèn)為，在對查詢進(jìn)行調(diào)試時(shí)，也很有必要搞清楚查詢是如何執(zhí)行的。因此我們決定在本節(jié)介紹一下查詢改寫是如何工作的，為什么需要查詢改寫，以及我們應(yīng)該如何控制它。
如果你之前使用過諸如前綴查詢或通配符查詢之類的查詢類型，那么你會(huì)了解這些都是基于多詞項(xiàng)的查詢，它們都涉及查詢改寫。Elasticsearch使用查詢改寫是出于對性能的考慮。從Lucene的角度來看，所謂的查詢改寫操作，就是把費(fèi)時(shí)的原始查詢類型實(shí)例改寫成一組性能更高的查詢類型實(shí)例，從而加快查詢執(zhí)行速度。查詢改寫過程對客戶端不可見，不過最好能夠知道我們可以修改查詢改寫過程。舉個(gè)例子，讓我們看看Elasticsearch是如何處理前綴查詢的。
2.2.1　前綴查詢示例
演示查詢改寫過程的最好方式莫過于通過范例深入了解該過程的內(nèi)部實(shí)現(xiàn)機(jī)制，尤其是要去了解原始查詢中的詞項(xiàng)是如何被改寫成目標(biāo)查詢中那些詞項(xiàng)的。假設(shè)我們索引了下面這些文檔中的數(shù)據(jù)：

現(xiàn)在我們想找出索引中所有name字段以字母j開頭的文檔。簡單起見，我們在clients索引中執(zhí)行以下查詢：

這里使用了一個(gè)簡單的前綴查詢，想檢索出所有name字段以字母j開頭的文檔。我們同時(shí)也設(shè)置了查詢改寫屬性以確定執(zhí)行查詢改寫的具體方法，不過現(xiàn)在我們跳過該參數(shù)，具體的參數(shù)值將在本章的后續(xù)部分討論。
執(zhí)行前面的查詢以后，我們將得到下面的結(jié)果：

如你所見，返回結(jié)果中有3個(gè)文檔，這些文檔的name字段以字母j開頭。我們并沒有顯式設(shè)置待查詢索引的映射，因此Elasticsearch探測出了name字段的映射，并將其設(shè)置為字符串類型并進(jìn)行文本分析。可使用下面的命令進(jìn)行檢查：

Elasticsearch將返回類似下面的結(jié)果：

2.2.2　回到Apache Lucene
現(xiàn)在我們回到Lucene。如果你還記得Lucene倒排索引是如何構(gòu)建的，你會(huì)指出倒排索引中包含了詞項(xiàng)、詞頻以及文檔指針（如果忘了，請重新閱讀1.1節(jié)）。現(xiàn)在我們看看之前存儲(chǔ)到clients索引中的數(shù)據(jù)大概是如何組織的。

Term這一列非常重要。如果我們?nèi)ヌ骄縀lasticsearch和Lucene的內(nèi)部實(shí)現(xiàn)，將會(huì)發(fā)現(xiàn)前綴查詢被改寫為下面這種查詢：

我們可以用Elasticsearch API來檢查重寫片段。首先，使用Explain API執(zhí)行如下命令：

執(zhí)行結(jié)果如下：

可以看到，Elasticsearch對name字段使用了一個(gè)詞項(xiàng)是joe的constant_score查詢。當(dāng)然，這一步發(fā)生在Lucene中，Elasticsearch實(shí)際上只是從緩存中獲取這些詞項(xiàng)。這一點(diǎn)可以用Validate查詢API來驗(yàn)證。

Elasticsearch返回的結(jié)果如下：

2.2.3　查詢改寫的屬性
當(dāng)然，多詞項(xiàng)查詢的rewrite屬性也可以支持除了“constant_score_boolean”之外的其他取值。我們可以通過這個(gè)屬性來控制查詢在Lucene內(nèi)部的改寫方式。我們可以將rewrite參數(shù)存放在代表實(shí)際查詢的JSON對象中，例如，像下面的代碼這樣：

現(xiàn)在讓我們來看看rewrite參數(shù)有哪些選項(xiàng)可以配置。
scoring_boolean：該選項(xiàng)將每個(gè)生成的詞項(xiàng)轉(zhuǎn)化為布爾查詢中的一個(gè)或從句（Boolean should clause）。這種改寫方法需要針對每個(gè)文檔都計(jì)算得分。因此，這種方法比較耗費(fèi)CPU（因?yàn)橐?jì)算和保存每個(gè)詞項(xiàng)的得分），而且有些查詢生成了太多的詞項(xiàng)，以至于超出了布爾查詢默認(rèn)的1024個(gè)從句的限制。默認(rèn)的布爾查詢限制可以通過設(shè)置Elasticsearch.yml文件的index.query.bool.max_clause_count屬性來修改。用戶需謹(jǐn)記，改寫后的布爾查詢的從句數(shù)越多，查詢性能越低。
constant_score_boolean：該選項(xiàng)與前面提到過的scoring_boolean類似，但是CPU耗費(fèi)更少，這是因?yàn)椴⒉挥?jì)算每個(gè)從句的得分，而是每個(gè)從句得到一個(gè)與查詢權(quán)重相同的一個(gè)常數(shù)得分，默認(rèn)情況下等于1，我們也可以通過設(shè)置查詢權(quán)重來改變這個(gè)默認(rèn)值。與scoring_boolean類似，該選項(xiàng)也有布爾從句數(shù)的限制。
constant_score_filter：正如Lucene的Javadocs描述的那樣，該選項(xiàng)按如下方式改寫原始查詢—通過順序遍歷每個(gè)詞項(xiàng)來創(chuàng)建一個(gè)私有的過濾器，標(biāo)記所有包含這個(gè)詞項(xiàng)的文檔。命中的文檔被賦予一個(gè)與查詢權(quán)重相同的常量得分。當(dāng)命中詞項(xiàng)數(shù)或文檔數(shù)較大時(shí)，該方法比scoring_boolean 和constant_score_boolean執(zhí)行速度更快。
top_terms_N：該選項(xiàng)將每個(gè)生成的詞項(xiàng)轉(zhuǎn)化為布爾查詢中的一個(gè)或從句，并保存計(jì)算出來的查詢得分。與scoring_boolean不同之處在于，該方法只保留最佳的N個(gè)詞項(xiàng)，以避免觸及布爾從句數(shù)的限制，并提升查詢整體性能。
top_terms_boost_N：該選項(xiàng)與top_terms_N類似，不同之處在于它的文檔得分不是通過計(jì)算得出的，而是被設(shè)置為跟查詢權(quán)重（boost）一致，默認(rèn)值為1。
　當(dāng)rewrite屬性設(shè)置為constant_score_auto或者沒有設(shè)置時(shí)，Elasticsearch會(huì)根據(jù)查詢的類型及其構(gòu)造方式來決定是使用constant_score_filter還是constant_score_boolean。
現(xiàn)在，讓我們再看一個(gè)例子。如果我們想在范例查詢中使用top_terms_N選項(xiàng)，并且N的值設(shè)置為2，那么查詢看起來與下面的代碼類似：

從Elasticsearch返回的結(jié)果中可以看出，和我們之前使用的查詢不同，這里的文檔得分都不等于1.0。

這是因?yàn)閠op_terms_N需要保留得分最高的N個(gè)詞項(xiàng)。
結(jié)束本節(jié)之前，讀者應(yīng)該會(huì)產(chǎn)生一個(gè)疑問，我們?nèi)绾螞Q定何時(shí)采用何種查詢改寫方法？該問題的答案更多地取決于您的應(yīng)用場景。簡單來說，如果您能接受較低的精度和相關(guān)性（但是追求更高的性能），那么可以采用top-N查詢改寫方法。如果您需要更高的查詢精度和更好的相關(guān)性（同時(shí)可以接受較低的性能），那么應(yīng)該采用布爾方法。

總結(jié)

以上是生活随笔為你收集整理的《深入理解Elasticsearch（原书第2版）》一2.2　查询改写的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。