sphinx搜尋引擎優化及測試

2年前工作中的內容，已成過眼煙雲，分享一下，歡迎交流。

1.之前的優化效果

之前對sphinx執行緒處理，網路io做了很多優化（netty、epoll、libevent），索引部分也做了優化，從目前測試結果來看，效能提公升已經到了瓶頸，尤其是全部搜尋，執行緒排程，網路 io優化對於這種查詢方式幫助很小。對於單節點效能提公升，還得從索引本身查詢演算法入手優化。sphinx的屬性過濾對效能本身有很大影響，但是優化空間不是很大，讀取的屬性是離散的，不像索引是可以連續讀取的，這種操作受限於物理硬體效能。目前可以優化的主要還是索引查詢部分，這兩天通過寫一些demo，模擬索引和查詢演算法對搜尋流程定量分析。

2.索引分析

目前只考慮了兩種演算法和索引的效能分析，第一種是sphinx現在的查詢方式和索引結構，第二種是某兄之前說的某搜尋公司的點陣圖索引。

現在的查詢方式效能統計：

1.1000萬資料，通過增量壓縮的方式（這裡面為了方便對比，增量都是1個位元組），壓縮後讀取索引時間是2597us。

在讀取快取區大於8k以後，基本上變化不大。載入到記憶體後，迴圈乙個乙個讀取位元組，不做解壓縮，需要時間65645us，

迴圈了1000萬次；如果邊讀取邊解壓，需要142438us, 相當於77ms的時間用在了解壓操作上。

2.1000萬資料，不做壓縮，以int的方式直接儲存（目前sphinx用的long,對於我們來說，只儲存記憶體屬性偏移位址，

int就足夠了），儲存檔案是原來的4倍，讀取時間10470us,多了8ms的讀取時間，迴圈讀取int ，無需解壓操作，

用了86493us。

3.兩個1000萬資料列表做and操作，都採用不壓縮的形式儲存，整個操作時間為482461us,平均下來300ms的時間

用在了比較操作上了

基於位圖運算：

1. 2000萬位的兩個位圖列表，對位圖執行and 操作，用時1855us，基本上不耗什麼時間。對位圖結果，遍歷查詢結果，

這個時間受結果集的大小限制。結果為空的時候，時間最短，不到2ms,如果結果很多，需要27ms。

2.點陣圖壓縮操作使用的是zlib，這個比較耗時，2000萬的點陣圖壓縮需要300-600ms, 壓縮的大小和點陣圖相關，即時空位

圖，壓縮後也有2k，最大不會超過原始大小。

3.位**壓操作，耗時需要10-30ms，即時空位圖，最小耗時也會在10ms。

讀取檔案逐個讀取解壓縮 and操作提取結果

sphinx壓縮索引 <3ms <65ms <77ms 未測試無需此項操作

sphinx不壓縮索引 <12ms <86ms 無需解壓縮 300ms 無需此項操作

位圖 <1ms 無需此項操作 10~30ms <2ms <27ms

對比結果：

sphinx 查詢方式查詢時間在1ms~500ms

位圖查詢方式查詢時間在30ms~90ms

點陣圖and 操作快，是因為採用64位與運算，相當於一次對64個資料比較，在倒排列表很大的情況下，效能優勢就很突出了，如果倒排列表很小，大部分操作都是無用功。

新的測試結果

使用點陣圖的資料直接儲存並不合適，只有倒排列表超過兩百萬的時候，位圖儲存有優勢，解壓縮時間優於儲存未壓縮倒排

列表時間。在實際中，2000萬資料中乙個倒排列表超過200萬的資料是少數。所以還是使用未壓縮的int儲存比較合適，在

讀的時候再設定位圖,用位圖做後續與或運算，這樣可以既可以相容之前的索引結構，又可以提高倒排列表合併的效能。

3.結論

總體上來看，sphinx 查詢方式效能波動很大，在大資料量的情況下，下降很明顯，位圖相比之下效能波動更加平滑。sphinx目前採用的這種壓縮方式，實際上意義不大，反而增加了cpu開銷。對於普通搜尋（查詢結果，返回結果數），這種查詢方式使用位圖優勢更加明顯一些。對於不需要結果數，只返回前n條結果的這種查詢方式，sphinx的查詢可能會快一些，位**壓縮有乙個最低消耗時間。

sphinx搜尋引擎優化及測試

搜尋引擎優化

搜尋引擎優化

搜尋引擎優化基礎

相關推薦