一、搜索優(yōu)化：

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

? ? 以下為百萬條數(shù)據(jù)級（適用于千萬級）快速滾動數(shù)據(jù)近實時搜索引擎實踐經(jīng)驗總結(jié)：

?

?1. 針對技術(shù)優(yōu)化

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

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

?

?2. 針對業(yè)務(wù)優(yōu)化

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

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

?

二、索引優(yōu)化：

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

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

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

?

三、分布式平衡

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

?

?

總結(jié)：

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

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

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

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

總結(jié)

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

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