一、綜合排序檢索性能提升

1.1 性能提升效果

優(yōu)化前后響應時間如下圖1所示

圖1

1.1.1 性能對比說明

1. 其中橫軸為普通檢索場景，由檢索時間范圍和檢索關鍵詞個數(shù)組成。縱軸是請求平均響應時間，單位為秒。
2. 在坐標軸上，紅色代表的是性能優(yōu)化前的請求響應時間，綠色代表的是優(yōu)化后的請求響應時間。黑色虛線代表的是目標線，目標為，單次請求在5s內(nèi)。

1.1.2 響應時間影響因素：

1. 檢索資源越多（服務器），響應時間越短。
2. 檢索時間范圍越大（一次檢索數(shù)據(jù)越多），響應時間越長。目前支持最大的檢索時間跨度為3個月。
3. 檢索關鍵詞越多，響應時間越長。目前能夠給業(yè)務開放支持的是 100個檢索詞。

1.1.3 優(yōu)化后效果

1. 整體性能提升效果明顯，提升在 1~ 30倍。
2. 其中對于慢查詢提升效果更好。對于檢索時間范圍越長，效果提升越好；對于檢索關鍵詞越多，效果提升越好。
3. 最終的檢索效果，檢索關鍵詞小于等于50個，響應時間可以控制在5s內(nèi)，能夠達到目標。其中只有檢索時間跨度到3個月，檢索關鍵詞100無法達到5s內(nèi)，目前是7s。

1.3 測試數(shù)據(jù)說明

性能提升前后測試數(shù)據(jù)如下圖2：

1. 測試對比數(shù)據(jù)由測試組同事提供。
2. 測試接口為服務總線生產(chǎn)環(huán)境，檢索邏輯為實際的業(yè)務檢索條件。響應時間略大于ES的響應時間。其中有0.3~0.5花在網(wǎng)絡傳輸上。
3. 其中提升前，是指綜合排序，使用腳本實現(xiàn)，是聞海2.0實現(xiàn)思路。提升后是指使用cutting off機制，對搜索進行優(yōu)化。

圖2

1.4 關于綜合排序說明

綜合排序，是業(yè)務上使用最頻繁的一種數(shù)據(jù)排序方式，也是默認的排序方式。其可以結(jié)合多個字段以及ES的BM25相關性分數(shù)，做一個綜合的排序。在實現(xiàn)上，使用script提取每一條數(shù)據(jù)的N個字段，然后計算一個分數(shù)，并和ES的相關性分數(shù)做融合。

其最大的優(yōu)點是召回的數(shù)據(jù)質(zhì)量好，可以滿足相關性的排序效果。

其最大的缺點是單次檢索，有非常大的計算量，需要花費大量的資源。單個檢索隨著命中的數(shù)據(jù)變多，檢索的時間復雜度增加，響應時間增加。使用script，需要對命中的所有數(shù)據(jù)做實時計算，計算過程需要將所需要的字段IO出來，會產(chǎn)生大量小文件的IO。由于每一條數(shù)據(jù)都需要做計算，索引，會占用大量的CPU資源，最終導致整體檢索效果慢N倍，N>5。且隨著關鍵詞命中的結(jié)果集合增大，額外的IO和CPU計算導致檢索性能越來越差。50個檢索詞在三個月中，耗時39s。150個詞在三個月數(shù)據(jù)中檢索時間300s。

1.5 優(yōu)化說明

1.5.1上述綜合排序中的問題，歸結(jié)為兩點。

1. 有腳本的存在，且需要實時計算。ES中腳本排序是一種低性能的檢索方式。
2. 單次檢索需要掃描全量的數(shù)據(jù)，且要對命中的數(shù)據(jù)做計算。單次檢索復雜度高。其中最大檢索時間跨度下，全部數(shù)據(jù)約450億數(shù)據(jù)。最大檢索關鍵詞數(shù)下，100個檢索關鍵詞OR的邏輯，能夠命中上億的數(shù)據(jù)。

1.5.2 針對問題，提出解決方案：

1. 分數(shù)預處理機制：對于多個要參與排序的字段分數(shù)，可以提前計算好，用一個額外的字段承接此分數(shù)。此操作可避免實時計算，從IO多個字段，變?yōu)镮O 一個字段。如下圖所示，在數(shù)據(jù)處理層，在數(shù)據(jù)入ES前，通過對數(shù)據(jù)的預處理，計算文檔的質(zhì)量分數(shù)。利用ES的插入排序能力，將高質(zhì)量的文檔在插入的時候放在最前邊檢索。

1. 避免掃描全量數(shù)據(jù)。利用數(shù)據(jù)寫入排序，可以做到將高質(zhì)量數(shù)據(jù)在存儲上總是排在前邊，優(yōu)先被檢索到。在數(shù)據(jù)根據(jù)質(zhì)量有序以后，則請求可以做截斷。優(yōu)先遍歷高質(zhì)量數(shù)據(jù)，找到topK的滿足條件的數(shù)據(jù)，此時分數(shù)也是最高的，達到召回條件后，則提前終止請求。

文章來源地址http://www.zghlxwxcb.cn/news/detail-719810.html