『壹』 luncene特點及優勢
Lucene，作為一款開源項目，自誕生以來在開發者社區中引起了廣泛關注。它不僅被用於構建各類全文檢索應用，還被廣泛集成到系統軟體、Web應用甚至商業軟體中，如Apache軟體基金會官網的全文檢索引擎和IBM的Eclipse、Web Sphere。Lucene憑借其特性和優勢贏得了廣泛採用：
1. 獨立的索引格式：Lucene採用8位位元組為基礎的索引文件格式，使得跨平台和兼容系統的應用能夠共享同一索引文件，提升了兼容性和靈活性。
2. 分塊索引與優化：它改進了傳統的倒排索引，實現分塊索引，新文件可快速建立小文件索引，通過與現有索引合並優化性能。
3. 面向對象架構：其優秀的系統設計降低了學習和擴展的難度，使得添加新功能更加便捷。
4. 通用的文本分析介面：Lucene提供了一個獨立於語言和文件格式的介面，用戶可以通過實現文本分析介面輕松擴展支持新的語言和文件格式。
5. 強大的查詢引擎：Lucene內置了豐富的查詢功能，如布爾運算、模糊查詢和分組查詢，無需用戶編寫大量代碼即可實現強大查詢能力。
對於商業全文檢索引擎，Lucene有獨特優勢。首先，其Apache Software License的開源模式，不僅允許用戶利用其功能，還提供了深入學習和創新的平台。其次，其面向對象架構為擴展提供了無限可能，如中文處理、HTML和PDF等格式的處理。最後，Lucene的開源特性使得程序員能夠藉助Apache社區的資源進行交流和協作，共享已完成的功能，且支持多種編程語言的實現，適應不同平台的需求。
Apache Lucene是一個開放源程序的搜尋器引擎，利用它可以輕易地為java軟體加入全文搜尋功能。Lucene的最主要工作是替文件的每一個字作索引，索引讓搜尋的效率比傳統的逐字比較大大提高，Lucen提供一組解讀，過濾，分析文件，編排和使用索引的API，它的強大之處除了高效和簡單外，是最重要的是使使用者可以隨時應自己需要自訂其功能。
『貳』 Lucene源碼索引文件結構反向
Lucene的索引結構復雜且詳盡，不僅保存了從Term到Document的正向映射，還包括了從Document到Term的反向信息。這種反向信息的核心是反向索引，它由詞典(Term Dictionary)和倒排表(Posting List)兩部分組成。詞典存儲在tii和tis文件中，包含Term的頻率、位置信息以及元數據；而倒排表分為文檔號和詞頻的frq文件，以及位置信息的prx文件。
詞典(.tim)存儲Term的統計信息，如包含文檔數量和詞頻，以及Term的元數據，包括其在文檔中的位置。詞典索引(.tip)則是對tim文件的索引，便於快速訪問。在tim中，NodeBlock以25個entries為一組，包含Term的相關數據和FieldSummary。OuterNode和InnerNode是NodeBlock的兩種類型，OuterNode按Term大小順序存儲，用RAMOutputStream記錄相關信息。
倒排表的存儲則更復雜，如PackedBlock壓縮和SKIPLIST結構。LIV文件通過FixBitSet記錄文檔狀態，而TermVector保存的信息與Field Data相似，Norms用於存儲Boost加權信息，可能在Lucene7後減少。Doc Values和Point Values分別處理數字類型數據和多維數據索引，這些內容在後續的文章中會有更詳細的解釋。
總的來說，理解Lucene的索引結構對於優化搜索引擎性能、診斷生產環境問題至關重要，因為它構成了分布式搜索引擎如Solr和ElasticSearch的基礎。深入剖析這些文件結構有助於我們從更高層次上進行問題分析。
『叄』 如何提高lucene的效率
如何提高Lucene的搜索速度 譯自http://wiki.apache.org/lucene-java/ImproveSearchingSpeed 這里討論了提高基於Lucene的應用程序搜索速度的幾種方法。如果你想提高索引的速度請閱讀「如何提高Lucene構建索引的速度」。 首先確定你需要加快搜索速度。這里的很多方法很容易嘗試但是有些會增加你程序的復雜性。所以請首先確定搜索速度確實太慢而且速度問題確實是Lucene導致的。 確保你使用的是最新版本的Lucene。 使用本地文件系統。 遠程文件系統搜索的速度總是會慢一些。如果你的索引必須放在遠程文件系統之上那麼可以考慮把遠程文件系統用「只讀方式」載入mount。某些時候這會改善性能。 使用更快的硬體尤其是更快的IO系統。 固態硬碟solid-state diskSSD非常適合Lucene的搜索。SSD的尋道時間大概是傳統磁碟式硬碟的100倍也就是說常見的尋道時間造成的開銷幾乎可以忽略掉了。也就是說裝有SSD的機器無需太多的內存作為文件緩存搜索器在允許反應之前需要的預熱warm-up時間更短。 調節操作系統。 linux可以調節的一個典型的參數是swappiness參看http://kerneltrap.org/node/3000譯注可理解為交換系統調節物理內存和交換分區使用傾向的這個參數控制了操作系統把內存交換出到IO緩存的傾向性。這個參數在大多數Linux發行版中的默認設置都是一個很大的數也就是說傾向於交換分區這容易造成嚴重的搜索延遲特別是在查詢頻率不高的情況下搜索一個大的索引時。請嘗試把swappiness調低甚至關閉把它設置為0。Windows也有一個選框在我的電腦-屬性-高級-性能設置-內存使用允許你選擇傾向於應用程序還是系統緩存好像也是起這個作用的。 使用readOnlytrue選項打開IndexReader。 在多線程共享同一個reader的時候這將起巨大的作用因為這樣會去掉處理線程沖突的代碼。 在非Windows平台使用NIOFSDirectory取代FSDirectory。 這樣訪問這些文件的時候也會去掉處理線程沖突的代碼。不幸的是由於Sun JRE Windows版本長期存在的bughttp://bugs.sun.com/bugdatabase/view_bug.dobug_id6265734NIOFSDirectory在Windows下表現很差。 使用IndexSearcher的同一個實例。 在程序的查詢和線程之間使用單一的一個IndexSearcher的實例。 測量性能的時候忽視第一條查詢。 對搜索器的第一次查詢要付出初始化緩存的代價特別是按照欄位排序的時候會干擾你的結論假設你重用搜索器進行多次查存。另外一方面如果你一遍遍的重復同樣的查詢結論也會被扭曲因為操作系統會使用它的緩存加速IO操作。Linux核心2.6.16或者更新版本下你可以用命令 sync echo 3 /proc/sys/vm/drop_caches 來清空緩存。參見http://linux-mm.org/Drop_Caches。 僅在需要的時候重新打開IndexSearcher。 只有在需要讓最新提交的更新出現在搜索中的時候才應該重新打開IndexSearcher。注意重新打開搜索器有它的開銷在大的索引和排序打開的情況下可以被察覺到的必須將這一開銷最小化。可以考慮在面對第一個查詢之前使用預熱技術對緩存進行預熱。 搜索前對你的索引進行優化optimize。 優化optimize過的索引只有一個段這樣通常比多個段速度快得多尤其是對於大的索引。如果你的程序不經常更新索引那麼最好是先構建索引然後優化使用優化過的索引進行搜索。如果你的索引更新頻率很高而且更新後就要刷新搜索器的話那麼優化對你的開銷就太大了你可以採用降低合並因子的方法。 降低合並因子mergeFactor。 小的合並因子意味著更少的段和更快的搜索。然而這將降低索引的速度所以你應該測試這個值直到找到對於你的程序滿足平衡的值。 限制保存欄位和詞向量的使用。 從索引中獲取這些信息開銷太大。一般來說你應該只獲取用戶看前可見的「頁」內的條目的這些信息而不是整個結果集的。針對每個獲取的文檔Lucene必須尋道到不同文件的不同位置。嘗試首先用docID排序你要獲取的文檔譯注有可能提高尋道效率。 在你獲取一個文檔時使用FieldSelector仔細的選擇要載入哪些欄位以及如何載入他們。 不要枚舉比所需命中結果更多的結果。 枚舉所有的命中很慢有兩個原因。首先返回Hits對象的search方法在你需要超過100個命中的時候需要內部重新執行搜索。解決方法用帶有HitCollector的search方法代替。其次命中通常遍布磁碟的每個角落訪問全部需要大量的I/O活動。這很難避免除非索引小到可以直接放到內存里。如果你不需要完整的文檔而只需要一個小的欄位那麼你可以用FieldCache類來緩存它這樣就可以告訴訪問它了。 使用模糊查詢fuzzy query的時候設置最小的前綴長度。 模糊查詢執行耗費CPU的字元串比較——要避免將用戶輸入的詞和所有的索引的詞項進行比較應該只比較前「N」個字元相同的詞項。前綴長度是QueryParser和FuzzyQuery都有的參數默認為0所有的詞項都要比較。 考慮使用過濾器filter。 把結果限定在索引的一部分時使用緩存的位域過濾器比使用查詢條件高效得多。尤其是在限制條件包含了一個大索引的大量文檔時。過濾器通常用於限定一個分類下的結果但是可以在很多中情況下替代任何查詢條件。查詢和過濾之間的一個區別在於查詢影響結果評分過濾不影響。 找到瓶頸。 復雜的查詢分析或者對結果過度處理是隱藏的搜索瓶頸的例子。使用VisualVM這樣的工具profile程序可以幫助定位這些問題。
『肆』 Lucene.Net建立索引 數據大概有百萬條 可是需要好久好久 請問有沒有辦法讓它變快呢
minMergeFactor還有一個這樣的參數，控制在內存緩沖的文檔數量我是建了500條數據後關閉IndexWriter.70萬的數據都可以建就是創建索引速度的問題70萬花了12小時
『伍』 Lucene 需要索引的文本文件太大,怎麼解決
就報錯來看，還沒有用到Lucene就出錯了，意思是只到第一行就虛擬機內存溢出了，可以考慮把源文件進行切割，如把10M的文本切成5個1M的，建議你試一下
給一個可以切分文件的程序，可把它作為預處理的一部分
public static void splitToSmallFiles(File file, String outputpath) throws IOException {
int filePointer = 0;
int MAX_SIZE = 10240000;
BufferedWriter writer = null;
BufferedReader reader = new BufferedReader(new FileReader(file));
StringBuffer buffer = new StringBuffer();
String line = reader.readLine();
while (line != null) {
buffer.append(line).append("\r\n");
if (buffer.toString().getBytes().length >= MAX_SIZE)
{
writer = new BufferedWriter(new FileWriter(outputpath + "output" + filePointer + ".txt"));
writer.write(buffer.toString());
writer.close();
filePointer++;
buffer = new StringBuffer();
}
line = reader.readLine();
}
writer = new BufferedWriter(new FileWriter(outputpath + "output" + filePointer + ".txt"));
writer.write(buffer.toString());
writer.close();
}