一、搜索優化：

? ? 在工程領域，越是看起來“簡單、確定”的問題，越是難以解決。近實時搜索引擎需要解決的問題只有一個：性能！它包含快速索引，快速搜索，以及索引到搜索的快速生效。

? ? 以下為百萬條數據級（適用于千萬級）快速滾動數據近實時搜索引擎實踐經驗總結：

?

?1. 針對技術優化

? ? 1.1 數值搜索優化： 將數值的范圍縮小，能用 int值 的不要用 long值，能用 float值 的不用要 double值；能用string 替換的，就不要用范圍查詢(特別是大范圍查詢)，這些都基于Lucene搜索引擎對數值建索引和范圍查詢的原理和特點所決定;

? ? 1.2 搜索語法的簡化和高級搜索的支持取得一個平衡點： 謹慎用"*","?"(Wildcard搜索)，禁止出現 "*AA"的查詢，如果必須支持這樣的查詢，則需要培訓用戶了解"*"可能引起的性能問題。

?

?2. 針對業務優化

? ? 2.1 特別強調范圍查詢，必須優化。避免大范圍數值查詢，數值范圍查詢不可避免的情況下，盡量使用小范圍，這是由業務性質決定的，比如：說 A > 0的查詢，需要優化為某個更有意義的查詢: [A : 0-100]。

? ? 2.2 能使用短字符串（特別是不做分詞的字符串）搜索的來替代，一定不要用數值搜索。數值搜索的特定雖然快，但對范圍查詢，它有一定的代價，如果使用不合適，代價會很大。

?

二、索引優化：

? ? 優秀的搜索引擎是快速創建索引和快速搜索的一個平衡體。特別對近實時搜索引擎而言，這個平衡點更為難以達到。

? ? 通過一系列測試和驗證，Lucene在【搜索】，【索引】以及【優化】之間要達到平衡其實很不容易。在頻繁的搜索和索引下，在線的優化難以真正起效果。可以理解為優先級有這樣的特性：搜索 > 索引 > 優化。搜索的時間相對最短，優化的時間最長。在前二者頻繁操作下，優化沒有機會（強行優化只能導致，搜索和索引停頓，對近實時系統來說不可接受）。因而必須設置好相應的參數，主要包括：緩存大小，索引內存大小，索引單次提交數量上限(等同Merge因子，Lucene不一定嚴格執行)，搜索最大并發數等。

? ? 大部分的索引優化是基于搜索業務的，如上述一所描述的用字符串字段替代數值范圍查詢。而索引本身的創建方式又直接影響到搜索，對Lucene來說Merge因子的配置是個關鍵（內存足夠大的情況下）。簡單的說，Merge因子小，索引慢，但對大批量建索引性能影響卻不大（索引內存足夠大為前提），但同時它會使得索引段落數被限制在合理范圍值（直接影響索引段數——搜索性能）。相反如果Merge因子小，搜索會很快，段數也大，如果不及時做索引優化，對搜索性能的影響是致命的。

?

三、分布式平衡

? ? 一臺Lucene服務器要想達到近實時搜索基本是不可能的，除非搜索量非常小。單臺搜索量5個/s以上，一臺基于Lucene的實時搜索基本上會吃不消，原因不在于搜索本身，而在于索引的同時，保證搜索實時性。而建索引的過程如果產生的碎片（段）過多，會直接影響搜索。總結下來，給予建索引的服務器一定的空閑時間是必須的，也就是說在建索引的時間段，搜索不能太過頻繁。因而分布式分攤搜索壓力是很有必要的。

?

?

總結：

? ? 1. 目前3臺基于Lucene的PC服務器，高峰并發數量在15個/s左右；

? ? 2. 數據量為百萬條級別（不到200萬），單條數據80個字段，每條大概為200字符（中文、英文、數字）；

? ? 3. 搜索條件基本在7-20關鍵字，平均搜索速度為98ms；

　 4. 最慢的搜索為350ms（毫秒）。

總結

以上是生活随笔為你收集整理的【转载保存】基于Lucene的近实时搜索引擎优化总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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