lucene演算法
Ⅰ java 怎麼用lucenes進行分詞
import java.io.IOException;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.StringField;
import org.apache.lucene.document.TextField;
import org.apache.lucene.index.CorruptIndexException;
import org.apache.lucene.index.DirectoryReader;
import org.apache.lucene.index.IndexReader;
import org.apache.lucene.index.IndexWriter;
import org.apache.lucene.index.IndexWriterConfig;
import org.apache.lucene.index.IndexWriterConfig.OpenMode;
import org.apache.lucene.queryparser.classic.ParseException;
import org.apache.lucene.queryparser.classic.QueryParser;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.ScoreDoc;
import org.apache.lucene.search.TopDocs;
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.LockObtainFailedException;
import org.apache.lucene.store.RAMDirectory;
import org.apache.lucene.util.Version;
import org.wltea.analyzer.lucene.IKAnalyzer;
/**
* 使用IKAnalyzer進行Lucene索引和查詢的演示
* 2012-3-2
*
* 以下是結合Lucene4.0 API的寫法
*
*/
public class LuceneIndexAndSearchDemo {
/**
* 模擬：
* 創建一個單條記錄的索引，並對其進行搜索
* @param args
*/
public static void main(String[] args){
//Lucene Document的域名
String fieldName = "text";
//檢索內容
String text = "IK Analyzer是一個結合詞典分詞和文法分詞的中文分詞開源工具包。它使用了全新的正向迭代最細粒度切分演算法。";
//實例化IKAnalyzer分詞器
Analyzer analyzer = new IKAnalyzer(true);
Directory directory = null;
IndexWriter iwriter = null;
IndexReader ireader = null;
IndexSearcher isearcher = null;
try {
//建立內存索引對象
directory = new RAMDirectory();
//配置IndexWriterConfig
IndexWriterConfig iwConfig = new IndexWriterConfig(Version.LUCENE_40 , analyzer);
iwConfig.setOpenMode(OpenMode.CREATE_OR_APPEND);
iwriter = new IndexWriter(directory , iwConfig);
//寫入索引
Document doc = new Document();
doc.add(new StringField("ID", "10000", Field.Store.YES));
doc.add(new TextField(fieldName, text, Field.Store.YES));
iwriter.addDocument(doc);
iwriter.close();
//搜索過程**********************************
//實例化搜索器
ireader = DirectoryReader.open(directory);
isearcher = new IndexSearcher(ireader);
String keyword = "中文分詞工具包";
//使用QueryParser查詢分析器構造Query對象
QueryParser qp = new QueryParser(Version.LUCENE_40, fieldName, analyzer);
qp.setDefaultOperator(QueryParser.AND_OPERATOR);
Query query = qp.parse(keyword);
System.out.println("Query = " + query);
//搜索相似度最高的5條記錄
TopDocs topDocs = isearcher.search(query , 5);
System.out.println("命中：" + topDocs.totalHits);
//輸出結果
ScoreDoc[] scoreDocs = topDocs.scoreDocs;
for (int i = 0; i < topDocs.totalHits; i++){
Document targetDoc = isearcher.doc(scoreDocs[i].doc);
System.out.println("內容：" + targetDoc.toString());
}
} catch (CorruptIndexException e) {
e.printStackTrace();
} catch (LockObtainFailedException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (ParseException e) {
e.printStackTrace();
} finally{
if(ireader != null){
try {
ireader.close();
} catch (IOException e) {
e.printStackTrace();
}
}
if(directory != null){
try {
directory.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}
Ⅱ 為什麼說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大理由不選用Lucene6. 沒有對集群的內置支持。如果你創建集群，你可以寫出自己對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來滿足你的需求(你將來必定會遇到這樣的需求)，你必須面對這樣的問題。例如：幾乎沒有使用介面。查詢類（例如BooleanQuery,SpanQuery,TermQuery…）都是一個抽象類的子類。如果你要添加其中的一個細節，你會首先想到寫一個介面來描述你擴展的契約，但是抽象的Query類並沒有實現介面，你必須經常的變化自己的查詢對象到Query中並在本地Lucene中調用。成堆的例子如(HitCollecor,…)這對使用AOP和自動代理來說也是一個問題. 別扭的迭代實現.沒有hasNext()方法,next()方法返回布爾類型並刷新對象內容.這對你想要保持對迭代的元素跟蹤來說非常的痛苦.我假定這是故意用來節省內存但是它又一次導致了演算法上的雜亂和復雜. 2.一個關閉的API使得繼承Lucene成為痛苦在Lucene的世界中,它被稱之為特性。當某些用戶需要得到某些細節，方針是開放類。這導致了大多數的類都是包保護級別的，這意味著你不能夠繼承他們（除非在你創建的類似在同一個包下，這樣做會污染客戶代碼）或者你不得不復制和重寫代碼。更重要的是，如同上面一點提到的，這個嚴重缺乏OO設計的結構，一些類應該被設為內部類卻沒有，匿名類被用作復雜的計算當你需要重寫他們的行為。關閉API的理由是讓代碼在發布前變得整潔並且穩定。雖然想法很光榮，但它再一次讓人感到痛苦。因為如果你有一些代碼和Lucene的主要思路並不吻合，你不得不經常回歸Lucene的改進到你自己的版本直到你的補丁被接受。然而當開發者開始越來越長的限制API的更改，你的補丁很少有機會被接受。在一些類和方法上加上final修飾符會讓你遇到問題。我認為如果Spring框架有這樣的限制，是覺不會流行起來。1. Lucene搜索演算法不適合網格計算Lucene被寫出來的時候硬體還沒有很大的內存，多處理器也不存在。因此，索引結構是被設計成使用線性的內存開銷很小的方式。我花了很長的時間來重寫跨度查詢演算法，並使用多線程內容（使用雙核處理器），但是基於迭代器的目錄讀取演算法幾乎不能實現。在一些罕見的場合你能做一些優化並能迭代一個索引通過並行方式，但是大多數場合這是不可能的。我們遇到的情況是，當我們有一個復雜的，超過50+的內嵌跨度查詢，CPU還在空閑但I/O卻一直忙碌，甚至在使用了RAMDirectory.有沒有替代品？我認為最後一個觀點充滿疑問:Lucene到達了它的極限當它在現在硬體基礎的條件下，檢索大型數據集合時。那就是我為什麼尋找下一個可以替代Lucene的出現。在閱讀了博客目錄和 Wikia的討論後，我發現並沒有很多的替代品。然而我最後推薦一個有希望的方案：MG4J。它有一個良好的面向對象設計，性能良好的檢索（索引比Lucene慢），內存開銷上也很小，達到10倍於Lucene速度的跨度查詢，在我的跨度查詢基準上，並且是原生上支持集群。同樣它也內置了負載平衡，而Lucene最近才加入這項功能並且還是實驗性質的。然而MG4J仍然缺少一些特性例如簡單的索引指數，文檔移除和更簡單的使用索引處理。讓我感到高興的是我可以自定義Lucene上的功能在MG4J上只需花幾個小時，而在Lucene上卻需要數天。我認為對開源的搜索引擎來說仍然有發展空間，它不是通過單台電腦用有限的內存來索引批量文檔，而是通過透明的分布式索引來提供對大型數據集合檢索更為快捷的答案。你不必利用應用來獲得集群特性。Lucene對第一類搜索引擎有了很好的實現，單我認為它並不符合我們的需求：在一個合理的時間內找到最佳的答案。基於tf/idf的搜索演算法和google的等級並不是未來搜索引擎的趨勢。實現對原數據和語義的復雜查詢並找出相關的信息，這是Lingway公司(通過Lucene和其他搜索引擎技術)所作的，不過它要求有更多支持新硬體的新技術。使用Lucene的一個好理由無論我如何指責Lucene,它仍然是java開源解決方案中的最佳實現。
Ⅲ 怎麼用lucene判斷兩篇文章的相似度 java
用演算法中的求最大相似子字元串的方法LCS或許可以，它可以找到兩個字元串中最大相似的子字元串。
Java code
/*
* @author talent_marquis<甜菜侯爵>
* Email: [email protected]
* Copyright (C) 2007 talent_marquis<甜菜侯爵>
* All rights reserved.
*/
package ustc.mse.algorithms.dynamicProgramming;
/*
* LCS, Longest-Common-Subsequence
*/
public class LCS
{
public enum DIRECTION{ TOP, TOP_LEFT, LEFT };
private char[] first;
private char[] second;
private int[][] lcsTable;
private DIRECTION[][] lcsAssistTable;
private int lcsLength;
private String lcs_str, lcsMatrix_str, lcsAssistMatrix_str;
private StringBuffer str_buffer;
public LCS( String str1, String str2 )
{
first = str1.toCharArray();
second = str2.toCharArray();
lcsTable = new int[ first.length + 1 ][ second.length + 1 ];
lcsAssistTable = new DIRECTION[ first.length + 1 ][ second.length + 1];
lcs_str = null;
Ⅳ Lucene是什麼
Lucene針對中文單字為詞，「我是學生」在standardAnalyzer分割下，分為「我」，「是」，「學」，「生」。
車東做了CJKAnalyzer可以分為「我是」，「是學」，「學生」。
你也可以用Dijkstra演算法來自己做一個，源代碼向家立要，他和我寫過《Lucene分析與應用》，他會告訴你去如何下載這個代碼，這種分詞都是有經驗值的，也就是說「學生」，已經是分割過的，就是有字典存在。
不配合字典你再想一想，自然語言是什麼？是人類的交談工具吧，有沒有規律哪？頻率，位置依賴關系，但是不管如何，人類自己要能明白，沒有人類自身的經驗，就別談「分詞」，「字典」。
分詞與Lucene關系不大，它只是輸入，雖然也會影響索引，與效率，效能，但是Lucene與你談論的問題關系不太大。
Ⅳ (2007-5-22更新)Lucene(Nutch)距離商業文本搜索引擎還有多遠
注（2007-5-22）：最新一次更新的時候，我再次研究了一下Lucene，讀完了Lucene In Action，並且實際的使用Lucene構建了一個小型的搜索系統之後，我感覺到很慚愧，因為我一直對Lucene有不滿的心理，認為它做的不好（可能受了國內的某些使用Lucene構建搜索引擎的網站的影響，因為他們構建的都很差，現在想來，可能是他們和我一樣沒有真正深入理解Lucene）。現在我才發現，Lucene的作者在大方向上考慮問題的全面比我要好很多（雖然有些功能我不知道是否真的有用）。現在我的感受是：1）Lucene對查詢的理解十分深入，幾乎什麼樣的查詢需求它都考慮到了。而對於普通的商業搜索引擎來說（比如，網路），它們只是考慮到了布爾查詢模式，遠不及Lucene裡面的查詢方式多；2）Lucene對過濾和排序的處理已經能夠滿足90%的要求了。過濾可以把不需要的結果刪除，而排序則可以根據某個域的值來進行結果排序。基本的垂直搜索引擎，是必須這些功能的，因為這些功能能夠縮小查詢的結果集，提高用戶體驗。而網路等商業搜索引擎顯然是不需要（或者沒有提供）這些功能的。3）Lucene的分值計算效果不錯。拋開基本的IR的那些標準的分值計算演算法不說（誰都知道總體上Lucene使用了簡化的向量模型，但實際上Lucene在布爾模型查詢上面也使用了簡化的擴展布爾模型分值計算公式），Lucene支持了大部分額外的基於經驗的分值計算。舉例來說，查詢「中國北京」的時候，以下是幾個文檔的實際排序（直接解析這個查詢短語是得不到這個結果的，見第4點）：中國北京北京中國中國可愛北京 北京屬於中國4）Lucene不提供真正的查詢串解析。基於文法的查詢串解析，一個嚴重的結果就是容錯太差，所以，我們幾乎可以認為Lucene並不提供實際有用的查詢串解析。所以呢，上面我們說的「中國北京」需要您自己把它解析為： PhraseQuery query = new PhraseQuery(); query.add(new Term("name","中國")); query.add(new Term("name","北京")); query.setSlop(1000);然後才會有上面的那個結果。所以，使用Lucene的第一步是提供您自己的查詢串解析器。5）理解Lucene的演算法限制。Doug Cutting不是神仙，他也無法解決演算法的問題，所以呢，幾乎所有演算法的限制都會在Lucene裡面出現，比如，RangeQuery查詢速度極慢，Sort排序需要很大的內存來緩沖Field的值。這些並不是Doug Cutting的錯，而是演算法的限制，我想應該沒有人能夠解決這類問題吧？（雖然從IR中我們知道RangeQuery可以使用B+樹等結構來加快查詢，不過，我們似乎不能夠責怪Lucene，因為Lucene使用的是緊湊的文件結構，難以支持B+樹結構） 如果您真的需要考慮這些問題的話，您可以自己修改Lucene的代碼或者提供額外的擴展。6）理解Lucene的其他限制。在實際應用的過程中，您會發現Lucene有各種各樣的限制，在這里，我想提醒您2個問題：a)緩沖同步；b)寫/讀同步。Lucene的緩沖做的不好，您可以根據實際情況自己擴展，在擴展的時候，請時刻注意緩沖和實際數據同步的問題。寫/讀同步其實是Lucene自己的問題，在同時讀寫一個Directory的時候，寫的數據並不會馬上表現到讀上面，所以呢，要麼關閉寫，要麼自己緩沖寫結果。Lucene是一個開源的基於java的搜索引擎，它只包含IR(Information Retrieve)部分。它即不是唯一的也不是最好的一個開源搜索引擎，更好的比如egothor，但是它是文檔最全面和受到關注最多的一個。Nutch是基於Lucene並加入了分布式和Crawler部分的搜索引擎。在本文中，作者試圖從掌握的知識范圍談論一下它們使用的技術和一般商業文本搜索引擎使用的技術之間的距離。因為作者水平有限，僅僅擁有2年不到的搜索研究和實踐經驗，不足之處請大家多多指教。謝謝。1 網路搜索引擎的構架一個專業的網路搜索引擎至少包含3部分，即抓取、處理和搜索。下面是它們的一般功能：抓取：抓取（蜘蛛、爬蟲、crawler、spider等）程序負責爬行特定網路（也可能是整個網路），把網路上的頁面和其它需要的文件下載到本地來。目前的難點是web2.0的普及導致的js分析和身份認證等問題。處理：處理（分類、信息抽取、數據挖掘、classify、information extraction、data mining等）程序對抓回來的頁面進行分析，比如，對網站的內容進行分類、對新聞頁面的新聞信息進行提取、頁面模版生成、對各個網站之間的關系進行計算等等。搜索：搜索（information retrieve）程序負責把文檔填充到資料庫，然後根據查詢字元串到資料庫中尋找最相關的文檔展現給用戶。僅僅從搜索引擎的構架來看，Lucene(Nutch)缺失的一環是信息的處理。信息的處理恰恰是整個搜索引擎中最核心的技術。2 信息抓取網路信息抓取包含了網頁抓取、文本文件抓取和其它文件抓取。對於使用http(還有https)等協議的網站來說，信息抓取的主要過程是：根據指定uri地址，進入第一個頁面；分析頁面構成，得到超鏈接地址，把地址加入到待下載鏈接中去；當還有未下載的鏈接時，下載對應頁面，保存頁面，並返回到第2步；所有鏈接都下載完畢，退出。普通的信息抓取一般可以被稱為Spider，它利用基本的html頁面分析器（比如，HtmlParser、NeckoHtml、JTidy等）來解析html頁面，得到頁面中的超鏈接。一般的說，一個Spider由以下2部分組成：http下載器。給定一個uri地址，http下載器負責把這個地址的數據下載回來。或許大家會認為這個很容易，其實不然。網路中的頁面，除了http協議以外，https安全協議也是十分常用的一種協議。當你要下載的數據需要認證的時候，你還需要讓你的下載器支持認證。當你下載的數據需要登錄的時候，你還需要讓你的下載器支持Cookie。所以，你的下載器僅僅支持http還是遠遠不夠的。在這點上，Nutch還差得遠。html頁面解析器。html頁面解析器並不是支持html頁面就萬事大吉了的，現在的很多頁面其實使用的是xml的構建方法，雖然html和xml很像，但是，它們的tag名字顯然有很大差別。除此以外，wap手機類頁面也是你可能需要支持的頁面。Nutch使用的是NeckoHtml或者JTidy。實際應用表明JTidy比較一般，但是NeckoHtml具有不錯的效果。在開源的軟體中，它應該算是最好的一個html頁面解析器。然而，它和IE或者Mozilla這些瀏覽器的html parser比較起來，還是有一段距離的。除此以外，這類Spider僅僅只是把頁面分析成了DOM樹，它並不能夠對基於ajax技術的web2.0頁面進行有效處理。要想處理那些大量使用ajax技術或者大量運用js代碼的頁面數據，Spider需要的仍然是js處理能力。當然了，關於js的處理也可以被劃分到數據處理部分去。3 信息處理似乎在Lucene(Nutch)面前談論信息處理顯得有點不專業，因為它們壓根就不支持。但是，信息處理部分你還是可以自己編寫後嵌入到Lucene(Nutch)裡面去的。信息處理話題太大，作者沒有這個膽量和水平對此妄加談論，雖然這個是作者一直研究的主要方向。唯一可以肯定的就是，信息處理需要的知識至少有2點：1，機器學習(ML)；2，自然語言理解(NLP)。前者典型的包括SVM、HMM等，後者包括HNC、知網等。筆者自信對ML有一定的理解，但是，對NLP的理解不太深入，還沒有形成一個完整的解決方案。4 信息獲取對信息獲取的研究已經好多好多年了，多到那個時候作者都未出生。這部分主要分為2個步驟，第一個步驟是把文檔填入到資料庫（也就是所謂的構建索引）；第二個部分就是根據用戶輸入得到一系列最相關文檔（即所謂的搜索）。得到最相關文檔無外乎就是比較2個文檔的相似度。當用戶輸入一個字元串（即一個文檔）之後，搜索引擎根據這個文檔到資料庫中尋找和它最相關的文檔，然後返回給用戶。實際搜索引擎必須考慮速度的問題，不可能像理論上說的那樣去做。搜索的時候，一般有如下3步：查詢字串解析。查詢的組織方式有很多種，比如布爾查詢等。一般商業文本搜索引擎支持的查詢大約這樣：「北京黃河 AND tom cat(OR 美麗-祖國)jerry + mouse」。即支持AND(+)、OR(|)、-、括弧和引號的復合表達式。光解析還不行啊，你還得進行額外的優化，比如，對於「北京北京北京北京」這個串來說，它和「北京」的效果是一樣的吧？Lucene在這個方面做了不少工作，只是，你仍然需要自己寫一個更接近中文和商業搜索引擎的查詢字串解析器。你可以根據需要，決定是把表達式優化為適合並行計算還是最小計算量的形式。 我們AND AND AND 他們 作為一個追求完美的人，作者實在無法接受這樣無法忍受的「錯誤」。查詢。查詢的部分沒有什麼太多可以說的。有一點是，演算法該優化的都沒有優化。不過，對於一個處於初級開發中，並且開發人員缺乏的Project來說，這樣就足夠了。結果排序。Lucene使用的分值計算方法在比較接近於IR理論上使用的一些計算方法。可是，實際中的分值計算卻比這個要麻煩很多。一個例子就是Lucene使用的方法沒有考慮到查詢詞語之間的緊密位置。比如，對於「北京商店」和「北京 商店」來說，得到的前幾個結果顯然應該差別很大，這是因為前者更傾向於「北京」和「商店」這2個詞語在一起的情況。要Lucene做到這一點其實也容易，只是，它會嚴重的降低搜索速度（幾倍）。 實際應用中，還常常需要計算某些屬性的值的權重。比如，新聞搜索裡面，今天的新聞是不是應該比昨天的新聞權重大一點呢？Lucene未能支持這點。5 速度第一對於搜索引擎來說，速度絕對是第一個需要考慮的問題。信息抓取的速度顯然不在軟體能夠解決的范圍內，它只能通過增加帶寬和多級更新策略來提高了。信息處理的速度不在本文的討論之列。信息獲取的時候，有2個地方需要考慮到速度：索引速度。索引速度包含索引的構建速度、文檔的修改速度和文檔的刪除速度。在粗粒度上說，Nutch採用的基於MapRece策略的分布式索引構建方法是一個不錯的構架。在細粒度上說，Lucene使用的內存緩沖和磁碟小索引合並的方法也是一個很好的構架。它們在構建索引上的表現都是令人稱道的。在文檔的刪除上，Lucene使用的標記後再刪除的方法是無可厚非的。在文檔的修改和文檔的追加上面，Lucene做的還差強人意。文檔在修改的時候，唯一的辦法就只能是先刪除然後再追加。這點顯然是不能令人滿意的。查詢速度。Lucene(Nutch)認為分布式的查詢是不可取的，因為速度更慢。其實並不是速度慢，而是分布式查詢需要一個快速的構架，這個構架涉及到搜索引擎的所有方面。暫時不是Nutch能夠達到的。所以，Lucene(Nutch)的查詢都是在一台機器上運行的。另外，Lucene因為它採用的分值計算方法的緣故，它不需要載入詞語在文檔中的位置信息，所以，它表面上看起來比其它搜索引擎快速了。其實是犧牲精度獲得速度，另外，它自己使用的文件結構嚴重的制約了它的速度。沒有引入緩沖是Lucene(Nutch)的另外一個嚴重失誤。在這個構架裡面，你可以自己構建一個查詢結果緩沖（一級緩沖），但是，你很難構建一個基於詞語的索引緩沖（二級緩沖）。這對於一個大搜索量的系統來說，是不可想像的。更何況普通商業搜索引擎還會有第三級緩沖。6 精度第二如果僅僅從Lucene(Nutch)支持的查詢方式和分值計算來看，Lucene(Nutch)不存在精度的問題，因為它們都是計算了全部數據的。商業搜索引擎因為數據量過大的緣故，不得不使用一些估計的演算法來減少磁碟數據的讀取，這會導致精度的略微丟失。反過來說，Lucene無法支持大規模數據。7 效率第三這里說的效率主要是空間效率。比如，程序的內存佔用和磁碟佔用。Lucene使用了zlib壓縮技術來壓縮文檔內容，還有使用了簡單的壓縮整數的方法。但是，它使用的壓縮方法還是太少了，它少用壓縮的結果是：1）文件結構和代碼簡單；2）查詢速度變慢；3）索引segment合並快速；4）磁碟佔用增加。同時，它幾乎不用壓縮也和它放棄緩沖有很大聯系，因為壓縮過的索引很容易放到內存裡面，這點十分滿足緩沖的空間需求。後記：因為作者對演算法極其狂熱，本文更多的是比較了開源搜索引擎Lucene(Nutch)和基本的商業搜索引擎之間在演算法上的差別。為了讓大家看的更明白，這里幾乎沒有提到任何演算法。寫的太多了，有空再增加。07.5.9 後記：根據最近的一些感悟，修改了本文。增加了一些認為重要的語句。
Ⅵ lucene 怎麼實現去詞根詞綴
Lucene下引入ICTCLAS進行中文分詞的實現方法
http://www.cnblogs.com/cy163/archive/2008/06/07/1215499.html
如何DIY一個Analyzer
咱們寫一個Analyzer,要求有一下功能
(1) 可以處理中文和英文,對於中文實現的是單字切分,對於英文實現的是以空格切分.
(2) 對於英文部分要進行小寫化.
(3) 具有過濾功能,可以人工設定StopWords列表.如果不是人工設定,系統會給出默認的StopWords列表.
(4) 使用P-stemming演算法對於英文部分進行詞綴處理.
Ⅶ Lucene 如何建立索
package com.onewaveinc.core.components.search;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.FilterIndexReader;
import org.apache.lucene.index.IndexReader;
import org.apache.lucene.index.IndexWriter;
import org.apache.lucene.index.Term;
import org.apache.lucene.store.RAMDirectory;
import java.io.IOException;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Date;
import java.util.Random;
/**
* 建立索引文件的工具類，外部類根據記錄生成IndexObject後可採用本類建立索引
*/
public class Indexer {
private String indexDir;//index文件放的路徑
private IndexWriter writer = null;
private IndexReader reader = null;
public void setIndexDir(String indexDir) {
this.indexDir = indexDir;
}
public static void main(String[] args) {
Indexer index = new Indexer();
index.setIndexDir("D:/workspace/index");
if (index.isCreate()) {
index.start("create");
} else {
index.start("append");
}
long timestamp = System.currentTimeMillis();
Random ran = new Random(12345678);
for (int i = 0; i <= 500000; i++) {
IndexedObject obj = new IndexedObject();
obj.setKey("1234567890" + i);
Map map = new HashMap();
map.put("name", obj.getKey() + ran.nextInt());
map.put("englishname", obj.getKey() + ran.nextInt());
map.put("chinesename", obj.getKey() + ran.nextInt());
map.put("keyword", obj.getKey() + ran.nextInt());
obj.setTexts(map);
index.index(obj);
if (i % 1000 == 0 && i != 0) {
long ntimestamp = System.currentTimeMillis();
index.finish();
System.out.println("finish耗費時間" + (System.currentTimeMillis() - ntimestamp));
index.start("append");
System.out.println("到" + i + "條數據耗費時間" + (System.currentTimeMillis() - timestamp));
}
}
}
/**
* 開始覆蓋/追加/刪除索引
*
* @param action 要做的動作(delete/create/append)
*/
public void start(String action) {
try {
if (!"delete".equals(action.trim().toLowerCase())) {
Analyzer analyzer = new StandardAnalyzer(new String[0]);
writer = new IndexWriter(indexDir, analyzer, "create".equals(action.trim().toLowerCase()));
writer.setMergeFactor(1000);
writer.setMaxBufferedDocs(1000);
writer.setMaxMergeDocs(100000);
} else if ("delete".equals(action.trim().toLowerCase())) {//如果只是刪除索引，只需要打開已有索引
reader = FilterIndexReader.open(indexDir);
}
} catch (IOException e) {
throw new IndexException(e);
}
}
/**
* 進行索引
*
* @param obj 放有要索引信息的類
*/
public void index(IndexedObject obj) {
if (writer != null) {
Document doc = new Document();
doc.add(new Field("key",obj.getKey(),Field.Store.YES,Field.Index.NO_NORMS));
for (Iterator keys = obj.getDataCache().keySet().iterator(); keys.hasNext();) {
String key = (String) keys.next();
doc.add(new Field(key,obj.getDataCache().get(key).toString(),Field.Store.YES,Field.Index.NO));//記錄緩存數據，不用搜索，不做索引
}
Map keywords = obj.getKeywords();
Iterator keys = keywords.keySet().iterator();
while (keys.hasNext()) {
String key = (String) keys.next();
Object value = keywords.get(key);
Field field = null;
if (value instanceof Date && value != null)
field = new Field(key, value.toString() == null ? "" : value.toString(),Field.Store.YES,Field.Index.NO_NORMS);
else
field = new Field(key, value.toString() == null ? "" : value.toString(),Field.Store.YES,Field.Index.NO_NORMS);
doc.add(field);
}
Map texts = obj.getTexts();
keys = texts.keySet().iterator();
while (keys.hasNext()) {
String key = (String) keys.next();
doc.add(new Field(key, texts.get(key) == null ? "" : texts.get(key).toString(),Field.Store.YES,Field.Index.TOKENIZED));
}
try {
writer.addDocument(doc);
} catch (IOException e) {
throw new IndexException(e);
}
} else {
try {
reader.deleteDocuments(new Term("key", obj.getKey()));
} catch (IOException e) {
throw new IndexException(e);
}
}
}
/**
* 刪除符合條件的索引
*
* @param key
* @param value
*/
public void delete(String key, String value) {
try {
reader.deleteDocuments(new Term(key, value));
} catch (IOException e) {
throw new IndexException(e);
}
}
/**
* 索引建立完成，關閉句柄，釋放文件系統lock
*/
public void finish() {
try {
if (writer != null) {
writer.optimize();
writer.close();
writer = null;
} else {
reader.unlock(reader.directory());
reader.close();
reader = null;
}
} catch (IOException e) {
throw new IndexException(e);
}
}
/**
* 判斷是新建索引 還是批量增加索引
* @return
*/
public boolean isCreate() {
boolean result = false;
try {
RAMDirectory indexFolder = new RAMDirectory(indexDir);
if(indexFolder.list().length < 1) {
result = true;
}
} catch (Exception e) {
result = true;
}
return result;
}
}
Ⅷ 如何使用lucene中的擴展詞典
你可以使用一個開源的中文分詞包MMAnalyzer,網上可以下到。在程序中引入此包。這個分詞包的大概作用是：
1、支持英文、數字、中文（簡體）混合分詞
2、常用的數量和人名的匹配
3、超過22萬詞的詞庫整理
4、實現正向最大匹配演算法
5、詞典的動態擴展
6、分詞效率： 第一次分詞需要1－2秒（讀取詞典），之後速度基本與Lucene自帶分詞器持平。
具體方法：
Analyzer analyzer = new MMAnalyzer();
然後用這個analyzer的analyzer.tokenStream()來對某一個字元串進行分詞（比如「中華人民共和國」，最終可以得出分詞結果，有固定的類來表示結果，具體怎麼寫看其文檔。
從這個例子來看，結果是「中華」 「人民」 「共和國」，利用某些類來迭代得出每一個詞並存入Map中做key，每迭代出一個分詞結果就在map中查找一下，若已有此詞為key，則在value里加1。這樣就實現了你的需求。
Ⅸ lucene 功能強大嗎相比百度谷歌差多遠
一點都不難，我們畢業設計就用lucene做的，寫一個簡單的搜索引擎，幾百行代碼就成了。佔多大內存影響因素很多：1、你存儲lucene索引位置（硬碟還是內存），2、你程序寫的好不好，3你要索引站內文件還是這個互聯網的，至於第三個問題，你自己想想看，人家網路和google是專門有公司運營的，當然比你一個人寫的強大多了，在一個問題就是lucene只是一個工具包，不能和網路，google比的