❶ lucene完全匹配放置首位的問題
可是我用IK分詞器搜索的時候，就是完全匹配的在前面啊，你使用的是哪個Query對象？
還有 StandardAnalyzer切分中文時 ，你輸入的是王小平，他會切分成」王 小 平「三個字，所以不管是」王小平33066「還是」王大小平「 都是100%匹配的，我覺得主要還是分詞的原因
❷ 倒排索引在lucene中的應用
全文檢索是信息檢索技術的一種，主要是把用戶的查詢請求和全文中的每一個詞進行比較，不考慮查詢請求與文本語義上的匹配。在信息檢索工具中，全文檢索是最具通用性和實用性的。Lucene是apache軟體基金會4 jakarta項目組的一個子項目，是一個開源的全文檢索引擎工具包，基於倒排文件索引結構來實現檢索功能。
什麼是倒排索引？與正排索引有什麼區別呢？
正排表是以文檔的ID為關鍵字，表中記錄文檔中每個字的位置信息，查找時掃描表中每個文檔中字的信息直到找出所有包含查詢關鍵字的文檔。
正排表結構如圖所示，這種組織方法在建立索引的時候結構比較簡單，建立比較方便且易於維護;因為索引是基於文檔建立的，若是有新的文檔加入，直接為該文檔建立一個新的索引塊，掛接在原來索引文件的後面。若是有文檔刪除，則直接找到該文檔號文檔對應的索引信息，將其直接刪除。但是在查詢的時候需對所有的文檔進行掃描以確保沒有遺漏，這樣就使得檢索時間大大延長，檢索效率低下。
倒排表以字或詞為關鍵字進行索引，表中關鍵字所對應的記錄表項記錄了出現這個字或詞的所有文檔，一個表項就是一個字表段，它記錄該文檔的ID和字元在該文檔中出現的位置情況。
由於每個字或詞對應的文檔數量在動態變化，所以倒排表的建立和維護都較為復雜，但是在查詢的時候由於可以一次得到查詢關鍵字所對應的所有文檔，所以效率高於正排表。在全文檢索中，檢索的快速響應是一個最為關鍵的性能，而索引建立由於在後台進行，盡管效率相對低一些，但不會影響整個搜索引擎的效率。
倒排表的結構圖如圖所示：
Lucene經多年演進優化，現在的一個索引文件結構如圖所示，基本可以分為三個部分：詞典、倒排表、正向文件、列式存儲DocValues。
倒排索引中的詞典位於內存，其結構尤為重要，有很多種詞典結構，各有各的優缺點，最簡單如排序數組，通過二分查找來檢索數據，更快的有哈希表，磁碟查找有B樹、B+樹，但一個能支持TB級數據的倒排索引結構需要在時間和空間上有個平衡，下圖列了一些常見詞典的優缺點：
Lucene3.0之前使用的也是跳躍表結構，後換成了FST，但跳躍表在Lucene其他地方還有應用如倒排表合並和文檔號索引。
Lucene現在採用的數據結構為FST，它的特點就是：
1、詞查找復雜度為O(len(str))
2、共享前綴、節省空間
3、內存存放前綴索引、磁碟存放後綴詞塊
這跟我們前面說到的詞典結構三要素是一致的：1. 查詢速度。2. 內存佔用。3. 內存+磁碟結合。
已知FST要求輸入有序，所以Lucene會將解析出來的文檔單詞預先排序，然後構建FST，我們假設輸入為abd,abd,acf,acg，那麼整個構建過程如下：
生成的FST：
100萬數據性能測試
可以看出，FST性能基本跟HaspMap差距不大，但FST有個不可比擬的優勢就是佔用內存小，只有HashMap10分之一左右，這對大數據規模檢索是至關重要的，畢竟速度再快放不進內存也是沒用的。
倒排表就是文檔號集合，但怎麼存，怎麼取也有很多講究，Lucene現使用的倒排表結構叫Frame of reference,它主要有兩個特點：
1. 數據壓縮，可以看下圖怎麼將6個數字從原先的24bytes壓縮到7bytes。
假設現在有兩篇文章：
文章1的內容為：Tom lives in Guangzhou,I live in Guangzhou too
文章2的內容為：He once lived in Shanghai.
倒排索引建立過程如下：
（1）取得關鍵詞
由於lucene是基於關鍵詞索引和查詢的，首先我們要取得這兩篇文章的關鍵詞，通常我們需要如下處理措施：
a.我們現在有的是文章內容，即一個字元串，我們先要找出字元串中的所有單詞，即分詞。英文單詞由於用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理(註：中文分詞比英文分詞更加復雜，如：「帽子和服裝」、「中華人民共和國」等，有興趣可以單獨研究)。
b.文章中的」in」, 「once」 「too」等詞沒有什麼實際意義，中文中的「的」「是」等字通常也無具體含義，這些不代表概念的詞可以過濾掉
c.用戶通常希望查「He」時能把含「he」，「HE」的文章也找出來，所以所有單詞需要統一大小寫。
d.用戶通常希望查「live」時能把含「lives」，「lived」的文章也找出來，所以需要把「lives」，「lived」還原成「live」
e.文章中的標點符號通常不表示某種概念，也可以過濾掉
在lucene中以上措施由Analyzer類完成。 經過上面處理後，
文章1的所有關鍵詞為：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有關鍵詞為：[he] [live] [shanghai]
（2）建立倒排索引
有了關鍵詞後，我們就可以建立倒排索引了。上面的對應關系是：「文章號」對「文章中所有關鍵詞」。倒排索引把這個關系倒過來，變成: 「關鍵詞」對「擁有該關鍵詞的所有文章號」。
文章1，2經過倒排後變成
通常僅知道關鍵詞在哪些文章中出現還不夠，我們還需要知道關鍵詞在文章中出現次數和出現的位置，通常有兩種位置：
a.字元位置，即記錄該詞是文章中第幾個字元（優點是關鍵詞亮顯時定位快）；
b.關鍵詞位置，即記錄該詞是文章中第幾個關鍵詞（優點是節約索引空間、片語（phase）查詢快），lucene中記錄的就是這種位置。
加上「出現頻率」和「出現位置」信息後，我們的索引結構變為：
（3）檢索過程
lucene的檢索過程分為以下幾個步驟：
1. 內存載入tip文件，通過FST匹配前綴找到後綴詞塊位置。
2. 根據詞塊位置，讀取磁碟中tim文件中後綴塊並找到後綴和相應的倒排表位置信息。
3. 根據倒排表位置去doc文件中載入倒排表。
（4）檢索結果
如果此時檢索「tom live」，那麼只需要檢索包含[tom]和[live]這兩個詞的文檔
可以看到，兩個詞都在文檔1中出現，且詞頻更高. 而文檔2隻被live命中一次。因此，檢索結果中文檔1的相關度更高。lucene默認使用TF/IDF演算法來計算文檔的相關度。
❸ 什麼是檢索在Lucene的查詢中所有匹配文檔的最有效方法，未排序
關鍵詞:信息檢索模型;相關性;查詢;搜索引擎中圖分類號:TP391 文獻標識碼:A 文章編號:1007-9599 (2010) 05-0000-02Comparision on Information Retrieva ModelsSong Yawei,Xiao Cheng(Jiangsu Provincial Communications Planning and Design Institute Co.,LTD,Nanjing 210005,China)Abstract:This article described the main contents and the construction strategy of the models of information retrieval,demonstrated a lot of methods in common usages,which is to calculate the model of information retrieval.And in this article,the advantages and disadvantages were analyzed,the problems that is still existing have been researched.In addition,the current situation of this research and the development tendency of the model of information retrieval were deeply summarizad in this article.Keywords:Information retrieval models;Relativity;Inquiry;Search engine當前，隨著互聯網的普及和網上信息的爆炸式增長，信息檢索系統及其核心技術搜索引擎的性能和效率問題已成為人們研究和關注的焦點。影響一個搜索引擎系統的性能有很多因素，但最主要的是信息檢索模型，其研究內容包括文檔和查詢的表示方法、評價文檔和用戶查詢相關性的匹配策略、查詢結果的排序方法和用戶進行相關度反饋的機制。本文從研究文檔與用戶查詢「相關性」匹配的角度出發，對信息檢索模型研究的主要內容和構建策略進行了詳細的描述，並給出了幾種常用的信息檢索模型相關性演算法，分析了它們的優缺點及存在的問題，總結了當前信息檢索模型的研究現狀和發展趨勢，其目的在於提高信息檢索、查詢的性能和效率。一、構建信息檢索模型的策略當前，構建信息檢索模型的主要策略有以下兩個:(一)通用的信息檢索模型構建一個通用的信息檢索模型，研究優化的匹配演算法，提高查詢速度、查全率和查准率，最大程度地滿足一般用戶的查詢需求。(二)用戶興趣模型根據特定用戶查詢興趣要求構建用戶興趣模型或共同興趣模型，能夠盡可能地滿足特殊用戶查詢的需求。它可以構建一個適合行業或專業應用語義要求信息獲取模型。如google就能推斷用戶的使用意圖，提供動態的、即時的用戶「個性化定製」信息，幫助用戶快速、准確地定位到所需要的信息。二、常用的信息檢索相關性演算法(一)布爾模型布爾模型是基於特徵項的嚴格匹配模型，文本查詢的匹配規則遵循布爾運算的法則。用戶可以根據檢索項在文檔中的布爾邏輯關系提交查詢，搜索引擎則根據事先建立的倒排文件結構，確定查詢結果。標準的布爾邏輯模型為二元邏輯，所搜索的文檔要麼與查詢相關，要麼與查詢無關。查詢結果一般不進行相關性排序。在布爾模型中，一個文檔通過一個關鍵詞條的集合來表示，這些詞條都來自一個詞典。在查詢與文檔匹配的過程中，主要看該文檔中的詞條是否滿足查詢條件。布爾模型用文檔的檢索狀態值作為一種評價查詢和文檔相似性的一種方法。這里，首先定義關鍵詞集合S，關鍵詞為t1，t2，…，tn。這些關鍵詞可以和邏輯操作符AND，OR和NOT形成不同的條件查詢。如果得到條件表達式的值為True，該文檔相對於此條查詢的檢索狀態值為1;如果若干文檔相對於此條查詢的檢索狀態值都為1，則可以認為，這些文檔與此用戶的查詢是相關的。布爾模型的主要優點有兩點:一是實現起來比較容易，速度快，計算的代價相對較少。二是查詢語言表達簡單，用戶可以使用任意復雜的查詢表達式，易於表示同義關系(如:聾教育OR特殊教育)和片語(如:計算機AND基礎AND課程改革)。它的缺點是，由於所有檢索到的與用戶查詢條件相關的文檔具有相同的檢索狀態值，則不能對查詢結果按照相關性進行排序;另外關鍵詞也沒有考慮權重的影響，缺乏定量分析和靈活性以及不能表述模糊匹配。而為了克服布爾型信息獲取模型查詢結果的無序性，在查詢結果處理中引進了模糊邏輯運算，將所檢索的資料庫文檔信息與用戶的查詢要求進行模糊邏輯比較，按照相關的優先次序排列查詢結果。(二)向量空間模型向量空間模型把信息庫中的文本以及用戶的查詢都表示成向量空間中的點(向量)，用它們之間夾角的餘弦作為相似性度量。向量空間模型是現在的文本檢索系統以及網路搜索引擎的基礎。在向量空間模型中，信息檢索系統如果涉及n個關鍵詞Term，則建立n維的向量空間，每一維都代表不同的關鍵詞Term。首先要建立文本和用戶查詢的向量，一個n元組的文檔向量Di的每個坐標都通過對應關鍵字的權重來表示，查詢向量中的權重表示對應關鍵詞對於用戶來說的重要程度。然後進行查詢向量和文本向量的相似性計算。並可以在匹配結果的基礎上進行相關反饋，優化用戶的查詢。在知道了文檔向量與查詢向量後，查詢與文檔的相似性就可以通過公式(2)求解。 (2)在公式(2)中，文檔Di可以用n維的向量表示，其中每個分量表示某一Term在整篇文檔中的權重。Q = (q1，q2，…，qn)中ql表示Terml在Q中的權重。向量空間模型的優點在於:1.檢索詞加權改進了檢索效果。2.部分匹配策略允許檢索出與查詢條件相近的文獻。3.可以根據相似度對文獻進行排序。它的缺點是，在這種模型中的基本假設，關鍵詞Term向量之間被假設為相互無關的，而實際是有時它們之間大多是依賴關系，如在自然語言中，詞或短語之間存在著十分密切的聯系。所以這一假設對計算結果的可靠性造成一定的影響。另外，在查詢中，也不能像布爾模型一樣使用關鍵詞之間的邏輯運算關系。(三)概率模型概率模型主要是基於概率排序原則:即如果文檔按照與查詢的概率相關性的大小排序，那麼排在最前面的是最有可能被獲取的文檔。它主要針對信息檢索中相關性判斷的不確定性以及查詢信息表示的模糊性。在前面的向量模型中，我們假定關鍵詞Term向量是正交的，不考慮Term向量之間的依賴關系。而在概率模型中，可以通過概率計算表達關鍵詞Term之間，以及關鍵詞Term和文檔之間的依賴關系，預測文檔與用戶查詢的相關概率，並可以對獲取的結果按照相關度概率的大小進行排序(簡稱PRP)。概率模型有兩個主要的參數:一個文檔和用戶查詢的相關概率Pr(rel)及不相關概率Pr(nonrel)，並且Pr(rel)=1-Pr(nonrel)。即Pr[term t in documentdocument is relevant]=Rt/R (3)Pr[term t in document document is irrelevant]= (ft-Rt)/(N- Rt) (4)其中:R表示與用戶查詢相關的文檔數;Rt表示在相關R中出現關鍵詞Term t的文檔數;N表示文檔數;ft表示在N個文檔中出現關鍵詞Term t的文檔數。由式(3)和(4)，可以得到:Pr[term t is not in document document is relevant]= (R- Rt)/R (5)Pr[term t is not in document document is irrelevant]=(N-ft-(R- Rt))/(N- Rt) (6)根據上面所給的「條件概率」，可以計算出關鍵詞Term t的權重: (7)在公式(7)中，如果wt>0，表明詞Term t出現的文檔與用戶查詢相關;如果wt<0，出現Term t的文檔與用戶查詢無關。概率模型的主要缺點是對文本集的依賴性過強，而且條件概率值很難估計。概率模型的一個特例是貝葉斯網路，該網路以概率的方式定義了關鍵詞的權重隨著與其相關的關鍵詞的權重的改變而改變方式。由於該模型適用於超文本信息系統，因而該模型的應用越來越廣泛。但是該模型的缺點是，計算復雜度很大，因而該模型不適合很大的網路。三、結束語目前，大多數信息檢索模型都依賴於布爾模型，而在實驗環境中用的最多並居於主導地位的是傳統的向量空間模型。信息檢索模型還有許多其他變種，如基於布爾模型的變種有:模糊集合模型、擴展布爾模型;基於矢量空間模型的變種有:通用矢量空間模型、潛在語義索引模型、神經網路模型;基於概率模型的變種有:推理網模型、可信網模型。而總體上來看，這些模型及其變種都是「語法」層次的信息檢索模型，沒有具有「語義」特徵的規范的詞彙集。
❹ 為什麼說Lucene不好
在Lingway公司，我們使用了Lucene至進今已有好幾年時間。對那些剛接觸Lucene的人來說，這里是使用它的關鍵：Apache Lucene是一個由java編寫的高性能，全方位的單詞搜索引擎庫。
在批評它之前，我必須承認Lucene是一個高性能的劃詞搜索引擎。幾年來，Lucene已經被看作是用java編寫的嵌入式搜索引擎中的一等公民。它的聲譽每日劇增，並且仍然是開源java搜索引擎中的最佳。每個人都在說：「Doug Cutting做了一項偉大的工作」。然而，最近的幾個月內，開發的進程變得緩慢，我認為Lucene將不會滿足現代的文檔處理需求。不要把東西搞糟：我不是搜索引擎開發者，我只是個開發者，使用搜索引擎，來提供合適信息的檢索科技。
Lucene不是最好選擇，至少對我們而言如此，並且情況並沒有得到改變。我們列出Lucene的局限性：Lingway公司基於語意來生成復雜的查詢。例如當你正在查找關於「中東地區沖突」的文章，你也許還需要找關於「伊拉克戰爭」文章。在上面這個用例中，「戰爭」和「伊拉克」分別是「沖突」和「中東」的擴展。我們使用一種技術能分析你的查詢，產生相應的最合適的擴展，為它們生成查詢。然而，為了得到相關的結果，這些還是不夠的：通過Lucene實現的類似Google的等級或是經常變化積分的並不能滿足語意級別積分。例如，一個包含「中」和「東」短語，但是被超過一個以上的單詞隔開，這種情況並不是我們想要查找的。更重要的是，相對常規的單詞，我們應該給擴展更低的分數。比如，我們應該給「中東地區沖突」這個短語更高的分數，而不是「伊拉克戰爭」。
在Lingway公司，我們認為這種文章相關性技術是一種未來的搜索引擎。Google在文章搜索上做的很出色。但我們想要的卻是最相關的文章。但是，大部分的當代搜索引擎都沒有對這樣復雜查詢做相關的設計…Lucene被wikipedia使用，如果你注意到當你查詢查過一個單詞時，大多數的查詢結果並不是由關聯的…
為了演示需求，這里有一個Lingway公司即將上線的KM3.7產品的界面截圖。這里我們用法語寫一個查詢，用來查找那些同樣主題，而用英語寫的文章。注意，這可不僅僅是簡簡單單的翻譯，我們稱之為語言交叉模式：
注意到那些綠色的匹配:chanteur變成了singer,但是我們也發現singing被匹配了。同樣情況流行樂成為藍調的擴展。
6大理由不選用Lucene
6. 沒有對集群的內置支持。
如果你創建集群，你可以寫出自己對Directory的實現，或是使用Solr或者使用Nutch+Hadoop。Solr和Nutch都支持Lucene，但不是直接的替代。Lucene是可嵌入的，而你必須支持Solr和Nutch..我認為Hadoop從Lucene團隊中產生並不驚訝:Lucene並不是通用的。它的內在性決定了對大多數場合來說它是非常快速的，但是對大型文檔集合時,你不得不排除Lucene。因為它在內核級別上並沒有實現集群，你必須把Lucene轉換到別的搜索引擎，這樣做並不直接。轉換到Solr或者Nutch上的問題會讓你遇到許多不必要的麻煩:Nutch中的集成crawling和Solr中的檢索服務。
5.跨度查詢太慢
這對Lingway公司來說可能是個特殊的問題。我們對跨度查詢有很強要求,Lucene檢索結構已經開始添加這一細節，但它們當初可沒這么想。最基礎的實現導致了復雜的演算法並且運行緩慢，尤其是當某些短語在一份文檔中重復了許多次出現。這是為什麼我傾向說Lucene是一個高性能的劃詞檢索引擎當你僅僅使用基本的布爾查詢時。
4.積分不能被插件化
Lucene有自己對積分演算法的實現,當條件增加時使用Similarity類。但很快它顯示出局限性當你想要表示復雜的積分,例如基於實際匹配和元數據的查詢。如果你這樣做，你不得不繼承Lucene的查詢類。因為Lucene使用類似tf/idf的積分演算法，然而在我們遇到的場合，在語意上的積分上Lucene的積分機制並不合適。我們被迫重寫每一個Lucene的查詢類使得它支持我們自定義的積分。這是一個問題。
3.Lucene並非良好設計
作為一個系統架構師，我傾向認為(1)Lucene有一個非常糟糕的OO設計。雖然有包，有類的設計，但是它幾乎沒有任何設計模式。這讓我想起一個由C(++)開發者的行為，並且他把壞習慣帶到了java中。這造成了，當你需要自定義Lucene來滿足你的需求(你將來必定會遇到這樣的需求)，你必須面對這樣的問題。例如：
<!--[if !supportLists]--> <!--[endif]-->幾乎沒有使用介面。查詢類（例如BooleanQuery,SpanQuery,TermQuery…）都是一個抽象類的子類。如果你要添加其中的一個細節，你會首先想到寫一個介面來描述你擴展的契約，但是抽象的Query類並沒有實現介面，你必須經常的變化自己的查詢對象到Query中並在本地Lucene中調用。成堆的例子如(HitCollecor,…)這對使用AOP和自動代理來說也是一個問題.
<!--[if !supportLists]--> <!--[endif]-->別扭的迭代實現.沒有hasNext()方法,next()方法返回布爾類型並刷新對象內容.這對你想要保持對迭代的元素跟蹤來說非常的痛苦.我假定這是故意用來節省內存但是它又一次導致了演算法上的雜亂和復雜.
2.一個關閉的API使得繼承Lucene成為痛苦
在Lucene的世界中,它被稱之為特性。當某些用戶需要得到某些細節，方針是開放類。這導致了大多數的類都是包保護級別的，這意味著你不能夠繼承他們（除非在你創建的類似在同一個包下，這樣做會污染客戶代碼）或者你不得不復制和重寫代碼。更重要的是，如同上面一點提到的，這個嚴重缺乏OO設計的結構，一些類應該被設為內部類卻沒有，匿名類被用作復雜的計算當你需要重寫他們的行為。關閉API的理由是讓代碼在發布前變得整潔並且穩定。雖然想法很光榮，但它再一次讓人感到痛苦。因為如果你有一些代碼和Lucene的主要思路並不吻合，你不得不經常回歸Lucene的改進到你自己的版本直到你的補丁被接受。
然而當開發者開始越來越長的限制API的更改，你的補丁很少有機會被接受。在一些類和方法上加上final修飾符會讓你遇到問題。我認為如果Spring框架有這樣的限制，是覺不會流行起來。
<!--[if !supportLists]-->1. Lucene搜索演算法不適合網格計算<!--[endif]-->
Lucene被寫出來的時候硬體還沒有很大的內存，多處理器也不存在。因此，索引結構是被設計成使用線性的內存開銷很小的方式。我花了很長的時間來重寫跨度查詢演算法，並使用多線程內容（使用雙核處理器），但是基於迭代器的目錄讀取演算法幾乎不能實現。在一些罕見的場合你能做一些優化並能迭代一個索引通過並行方式，但是大多數場合這是不可能的。我們遇到的情況是，當我們有一個復雜的，超過50+的內嵌跨度查詢，CPU還在空閑但I/O卻一直忙�擔踔獵謔褂昧薘AMDirectory.
有沒有替代品？
我認為最後一個觀點充滿疑問:Lucene到達了它的極限當它在現在硬體基礎的條件下，檢索大型數據集合時。那就是我為什麼尋找下一個可以替代Lucene的出現。在閱讀了博客目錄和 Wikia的討論後，我發現並沒有很多的替代品。然而我最後推薦一個有希望的方案：MG4J。它有一個良好的面向對象設計，性能良好的檢索（索引比Lucene慢），內存開銷上也很小，達到10倍於Lucene速度的跨度查詢，在我的跨度查詢基準上，並且是原生上支持集群。同樣它也內置了負載平衡，而Lucene最近才加入這項功能並且還是實驗性質的。然而MG4J仍然缺少一些特性例如簡單的索引指數，文檔移除和更簡單的使用索引處理。讓我感到高興的是我可以自定義Lucene上的功能在MG4J上只需花幾個小時，而在Lucene上卻需要數天。
我認為對開源的搜索引擎來說仍然有發展空間，它不是通過單台電腦用有限的內存來索引批量文檔，而是通過透明的分布式索引來提供對大型數據集合檢索更為快捷的答案。你不必利用應用來獲得集群特性。Lucene對第一類搜索引擎有了很好的實現，單我認為它並不符合我們的需求：在一個合理的時間內找到最佳的答案。基於tf/idf的搜索演算法和google的等級並不是未來搜索引擎的趨勢。實現對原數據和語義的復雜查詢並找出相關的信息，這是Lingway公司(通過Lucene和其他搜索引擎技術)所作的，不過它要求有更多支持新硬體的新技術。
使用Lucene的一個好理由
無論我如何指責Lucene,它仍然是java開源解決方案中的最佳實現。
❺ lucene的底層數據結構
lucene是很有深度的，特別是文件存儲、讀取、排序部分。需要一定的編程經驗。沒有經驗的話，最好不要去硬鑽。
要明白文本是以何種形式存儲在磁碟上，為什麼要這樣存儲，以及如何讀取出來，如何算分，如何排序。
❻ lucene 功能強大嗎相比百度谷歌差多遠
一點都不難，我們畢業設計就用lucene做的，寫一個簡單的搜索引擎，幾百行代碼就成了。佔多大內存影響因素很多：1、你存儲lucene索引位置（硬碟還是內存），2、你程序寫的好不好，3你要索引站內文件還是這個互聯網的，至於第三個問題，你自己想想看，人家網路和google是專門有公司運營的，當然比你一個人寫的強大多了，在一個問題就是lucene只是一個工具包，不能和網路，google比的
❼ lucene按匹配度排序是怎麼做到的
Lucene的搜索結果默認按相關度排序，這個相關度排序是基於內部的Score和DocID，Score又基於關鍵詞的內部評分和做索引時的boost。默認Score高的排前面，如果Score一樣，再按索引順序，先索引的排前面。那麼有人問了，如果我要先索引的排後面怎麼辦呢？隱士研究了源碼後發現這是相當簡單的事情。以下代碼基於Lucene 2.0。
看Sort的默認構造函數，相關度就是SortField.FIELD_SCORE和SortField.FIELD_DOC的組合。
java 代碼
/**
* Sorts by computed relevance. This is the same sort criteria as calling
* {@link Searcher#search(Query) Searcher#search()}without a sort criteria,
* only with slightly more overhead.
*/
public Sort() {
this(new SortField[] { SortField.FIELD_SCORE, SortField.FIELD_DOC });
}
那麼該如何構造我們需要的SortField呢？請看SortField的一個構造函數，有一個參數reverse可供我們調整結果集的順序。
java 代碼
/** Creates a sort, possibly in reverse, by terms in the given field with the
* type of term values explicitly given.
* @param field Name of field to sort by. Can be <code>null</code> if
* <code>type</code> is SCORE or DOC.
* @param type Type of values in the terms.
* @param reverse True if natural order should be reversed.
*/
public SortField (String field, int type, boolean reverse) {
this.field = (field != null) ? field.intern() : field;
this.type = type;
this.reverse = reverse;
}
由此可見，只要構造一個SortField[]就可以實現我們要的功能，請看：
java 代碼
// 評分降序，評分一樣時後索引的排前面
new SortField[] { SortField.FIELD_SCORE, new SortField(null, SortField.DOC, true) }
// 評分升序，評分一樣時後索引的排前面，呵呵，此為最不相關的排前面，挺有趣的
new SortField[] { new SortField(null, SortField.SCORE, true), new SortField(null, SortField.DOC, true) }
呵呵，只要將此SortField[]作為參數傳入Sort的構造函數得到Sort的一個instance，將此instance傳入searcher.search(query, sort)即可得到了期望的結果。
❽ 用Lucene searchafter分頁，怎樣排序
TopFieldDocs tds = searcher.search(query, num, sort);
return (FieldDoc) tds.scoreDocs[num - 1];
在獲取上一頁最後一個ScoreDoc方法中，也需要將sort傳入。 TopDocs tds = searcher.search(query, num, sort); return tds.scoreDocs[num - 1];