1、企業(yè)級實戰(zhàn) DSL（數(shù)據(jù)已經(jīng)脫敏）

2、大家可以看一下，能發(fā)現(xiàn)哪些問題？

根據(jù)我的實戰(zhàn)和咨詢經(jīng)驗，我發(fā)現(xiàn)如下幾個問題。

當(dāng)然，這是在和球友交流確認(rèn)問題之后總結(jié)出來的。

2.1 問題1：bool 組合嵌套過深。

官方實際是有參數(shù)來約束的，indices.query.bool.max_nested_depth——bool 最大支持的嵌套層數(shù)是 20，并且過大的嵌套層數(shù)會導(dǎo)致“堆棧溢出”異常問題。

那 bool 組合嵌套越深是不是越慢呢？

我拿 228 萬+的微博數(shù)據(jù)（JMeter 模擬100用戶并發(fā)）作為樣例索引數(shù)據(jù)進(jìn)行驗證。

• 實驗1：嵌套 10 層；執(zhí)行 5 次，平均耗時：835 ms。

• 實驗2：嵌套 2 層；執(zhí)行 5 次，平均耗時：674.8 ms。

對比看實驗 2 執(zhí)行查詢較實驗 1 的查詢要快！

其實，初步結(jié)論是嵌套越深，執(zhí)行越慢！

2.2 問題2：大量使用 wildcard 查詢。

我之前血淋淋的教訓(xùn)告訴大家，非必要不使用 wildcard ！

尤其數(shù)據(jù)量大的場景。

參見：Elasticsearch 警惕使用 wildcard 檢索！然后呢？

依然拿 228 萬+的微博數(shù)據(jù)（JMeter 模擬 100 用戶并發(fā)）作為樣例索引數(shù)據(jù)進(jìn)行驗證。

檢索語句如下：

使用：match_phrase 短語匹配較使用 wildcard 模糊匹配效率提升：6.34 倍！

初步結(jié)論：非必要，不使用 ?wildcard。

2.3 問題3："track_total_hits": 2147483647 沒有必要搞這么大？

認(rèn)知前提：Elasticsearch 中 max_result_window 這個參數(shù)大家比較熟悉，就是允許 from + size 翻頁檢索命中的最多文檔數(shù)為：10000 條記錄。

那么問題來了，如果命中數(shù)據(jù)量超過 10000萬怎么辦？

• 一方面：我們可以修改：max_result_window 的默認(rèn)值，但默認(rèn)值修改要慎之又慎。

• 另一方面：我們可以在執(zhí)行檢索的時候加上 track_total_hits 這個參數(shù)。

問題來了？什么場景需要單獨設(shè)置 track_total_hits 參數(shù)？什么時候不需要呢？

• 場景一：當(dāng)索引設(shè)置層面設(shè)置了 index.sort 后，本質(zhì)上寫入的數(shù)據(jù)已經(jīng)進(jìn)行了預(yù)排序。如果只對前 N 個結(jié)果感興趣，而不關(guān)心總命中數(shù)，可以簡單地將 track_total_hits 設(shè)置為 false。

• 場景二：針對 filter 過濾檢索的場景，用戶僅關(guān)注是否存在，不關(guān)注相關(guān)性?？梢苑譃槿缦聝煞N情況：

（1）情況2.1：將 track_total_hits 設(shè)置為 false，檢索結(jié)果將不再返回 hits.total 的具體值。

（2）情況2.2：將 track_total_hits 設(shè)置為給定的 N, 那么每個分片待召回 N 個文檔后就返回。除此之外的業(yè)務(wù)場景，建議慎用 track_total_hits:true 的場景。

我們同樣對比一下性能。

初步結(jié)論：加上 track_total_hits，檢索會變慢，我們要結(jié)合業(yè)務(wù)場景謹(jǐn)慎使用。

2.4 問題4：track_scores 確認(rèn)是否必要使用！

track_scores 含義如下：When sorting on a field, scores are not computed. By setting track_scores to true, scores will still be computed and tracked.

也就是說這是個和排序相關(guān)的參數(shù)，如果走排序，就不計算評分。

如果想對排序加上評分處理，需要加這個參數(shù)。

2.5 問題5："_source": {"includes": [ 確認(rèn)是否必須

其實有更快的建模方式，就是 store 設(shè)置 true 對字段單獨建模。當(dāng)然，這涉及到數(shù)據(jù)建模和寫入。

_source 下召回的數(shù)據(jù)字段越多，肯定會越慢。暫且不說別的，網(wǎng)絡(luò)傳輸?shù)慕嵌染涂梢娨话摺?/p>

網(wǎng)絡(luò)傳輸中，網(wǎng)速一定，但是 _source 字段多，意味著傳輸?shù)淖止?jié)數(shù)多，必然會越慢。

還是拿微博數(shù)據(jù)驗證一下，

初步結(jié)論，僅指定一個字段比全部默認(rèn)字段（10個以上），影響時間要快很多！

2.6 問題6：match，match_phrase, wildcard 都混合使用，考慮分詞問題解決。

推薦：字詞混合索引方案。

一個線上問題引發(fā)的思考——Elasticsearch 8.X 如何實現(xiàn)更精準(zhǔn)的檢索？

2.7 問題7：建議線上使用復(fù)雜DSL，可以使用性能測試驗證一下。

文中 JMeter 測試工具使用，推薦視頻：

https://t.zsxq.com/0853Q9epD

3、小結(jié)

不要小瞧 DSL 的使用，不要堆砌一些不太理解的參數(shù)不加驗證直接用于實戰(zhàn)環(huán)境，后面的風(fēng)險會變得很大。

DSL 的調(diào)優(yōu)其實直接影響到檢索性能。

大家對文中的 DSL 還有哪些調(diào)優(yōu)建議，歡迎留言交流！

推薦閱讀

1. 全網(wǎng)首發(fā)！從 0 到 1 Elasticsearch 8.X 通關(guān)視頻
   

2. 重磅 | 死磕 Elasticsearch 8.X 方法論認(rèn)知清單（2022年國慶更新版）
   

3. 如何系統(tǒng)的學(xué)習(xí) Elasticsearch ？

4. esrally 如何進(jìn)行簡單的自定義性能測試？

5. Elasticsearch 性能調(diào)優(yōu)指南——推薦實戰(zhàn) DSL

6. 讓Elasticsearch飛起來!——性能優(yōu)化實踐干貨
   

更短時間更快習(xí)得更多干貨！

和全球?1800+?Elastic 愛好者一起精進(jìn)！

比同事?lián)屜纫徊綄W(xué)習(xí)進(jìn)階干貨！文章來源地址http://www.zghlxwxcb.cn/news/detail-573667.html