Lucene

2017年2月10日, 星期五

---

Lucene

一．第一節： lucene簡介 和原理

 

1. 什麼是lucene 
Lucene是一個全文搜索框架，而不是應用產品。所以它並不像http://www.baidu.com/ 或者google Desktop那麼拿來就能用，它只是提供了一種工具讓你能實現這些產品。

 

2. lucene能作什麼

要回答這個問題，先要了解lucene的本質。實際上lucene的功能很單一，說到底，就是你給它若干個字符串，而後它爲你提供一個全文搜索服務，告訴你你要搜索的關鍵詞出如今哪裏。知道了這個本質，你就能夠發揮想象作任何符合這個條件的事情了。你能夠把站內新聞都索引了，作個資料庫；你能夠把一個數據庫表的若干個字段索引發來，那就不用再擔憂由於「%like%」而鎖表了；你也能夠寫個本身的搜索引擎……

 

3. 你該不應選擇lucene

下面給出一些測試數據，若是你以爲能夠接受，那麼能夠選擇。
測試一：250萬記錄，300M左右文本，生成索引380M左右，800線程下平均處理時間300ms。
測試二：37000記錄，索引數據庫中的兩個varchar字段，索引文件2.6M，800線程下平均處理時間1.5ms。

 

4.倒排索引

倒排索引源於實際應用中須要根據屬性的值來查找記錄。這種索引表中的每一項都包括一個屬性值和具備該屬性值的各記錄的地址。因爲不是由記錄來肯定屬性值，而是由屬性值來肯定記錄的位置，於是稱爲倒排索引(inverted index)。帶有倒排索引的文件咱們稱爲倒排索引文件，簡稱倒排文件(inverted file)。

倒排列表用來記錄有哪些文檔包含了某個單詞。通常在文檔集合裏會有不少文檔包含某個單詞，每一個文檔會記錄文檔編號（DocID），單詞在這個文檔中出現的次數（TF）及單詞在文檔中哪些位置出現過等信息，這樣與一個文檔相關的信息被稱作倒排索引項（Posting），包含這個單詞的一系列倒排索引項造成了列表結構，這就是某個單詞對應的倒排列表。

 

文檔(Document)：通常搜索引擎的處理對象是互聯網網頁，而文檔這個概念要更寬泛些，表明以文本形式存在的存儲對象，相比網頁來講，涵蓋更多種形式，好比Word，PDF，html，XML等不一樣格式的文件均可以稱之爲文檔。再好比一封郵件，一條短信，一條微博也能夠稱之爲文檔。在本書後續內容，不少狀況下會使用文檔來表徵文本信息。

       文檔集合(Document Collection)：由若干文檔構成的集合稱之爲文檔集合。好比海量的互聯網網頁或者說大量的電子郵件都是文檔集合的具體例子。

       文檔編號(Document ID)：在搜索引擎內部，會將文檔集合內每一個文檔賦予一個惟一的內部編號，以此編號來做爲這個文檔的惟一標識，這樣方便內部處理，每一個文檔的內部編號即稱之爲「文檔編號」，後文有時會用DocID來便捷地表明文檔編號。

       單詞編號(Word ID)：與文檔編號相似，搜索引擎內部以惟一的編號來表徵某個單詞，單詞編號能夠做爲某個單詞的惟一表徵。

       倒排索引(Inverted Index)：倒排索引是實現「單詞-文檔矩陣」的一種具體存儲形式，經過倒排索引，能夠根據單詞快速獲取包含這個單詞的文檔列表。倒排索引主要由兩個部分組成：「單詞詞典」和「倒排文件」。

       單詞詞典(Lexicon)：搜索引擎的一般索引單位是單詞，單詞詞典是由文檔集合中出現過的全部單詞構成的字符串集合，單詞詞典內每條索引項記載單詞自己的一些信息以及指向「倒排列表」的指針。

      倒排列表(PostingList)：倒排列表記載了出現過某個單詞的全部文檔的文檔列表及單詞在該文檔中出現的位置信息，每條記錄稱爲一個倒排項(Posting)。根據倒排列表，便可獲知哪些文檔包含某個單詞。

      倒排文件(Inverted File)：全部單詞的倒排列表每每順序地存儲在磁盤的某個文件裏，這個文件即被稱之爲倒排文件，倒排文件是存儲倒排索引的物理文件。

     關於這些概念之間的關係，經過圖3-2能夠比較清晰的看出來。

                                        

 

                                                                              圖3-2 倒排索引基本概念示意圖

 

 

5.使用lucene創建索引文件

導入以下jar包

 

API調用代碼以下

 

 

二．第二節：lucene使用

1.lucene的搜索

查看安裝文件下doc下的index.html，能夠查看相關API

利用上面創建的索引來

代碼展現以下：

 

2.Lucene的倒排索引

例如：

我是中國人—（1）

中國是全球人口最多的國家 ,中國人也最多（2）

 

1，我 （1:1）｛0｝

2，中國 (1:1) {2},(2:2){0，15}

人   

 

每一個域能夠設置三個類型：是否保存，是否索引，是否分詞

3．lucene的工做方式

lucene提供的服務實際包含兩部分：一入一出。所謂入是寫入，即將你提供的源（本質是字符串）寫入索引或者將其從索引中刪除；所謂出是讀出，即向用戶提供全文搜索服務，讓用戶能夠經過關鍵詞定位源。

 

3.1寫入流程

源字符串首先通過analyzer處理，包括：分詞，分紅一個個單詞；去除stopword（可選）。
將源中須要的信息加入Document的各個Field中，並把須要索引的Field索引發來，把須要存儲的Field存儲起來。 
將索引寫入存儲器，存儲器能夠是內存或磁盤。

 

2.2讀出流程 

用戶提供搜索關鍵詞，通過analyzer處理。
對處理後的關鍵詞搜索索引找出對應的Document。
用戶根據須要從找到的Document中提取須要的Field。

4.Lucene相關原理和相關類

4.1Lucene3.0之結果排序（原理篇）

 

傳統上，人們將信息檢索系統返回結果的排序稱爲"相關排序" （relevance ranking） ，隱含其中各條目的順序反映結果和查詢的相關程度。

1、 基本排序原理

①     向量空間模型

Gerald Salton 等在 30 多年前提出的"向量空間模型" （Vector Space Model，VSM）[Salton and Lesk,1968, Salton,1971]。該模型的基礎是以下假設：文檔d和查詢q的相關性能夠由它們包含的共有詞彙狀況來刻畫。

經典的TF*IDF詞項權重的計算公式：

 

         給定某種權重的定量設計，求文檔和查詢的相關性就變成了求 d 和 q 向量的

某種距離，最經常使用的是餘弦（cos）距離

 

 

②     連接分析PageRank原理

連接分析技術主要基於兩個假設：1）一個網頁被屢次引用，則它多是很重要的，若是被重要的網頁引用，說明自身也是重要的，網頁的重要性在網頁之間能夠傳遞。

2）隨機衝浪模型：認爲假定用戶一開始隨機地訪問網頁集合中的一個網頁，然和跟隨網頁的連接向前瀏覽網頁，不會退瀏覽，那麼瀏覽下一個網頁的機率是被瀏覽網頁的量化的重要程度值。

按照以上的用戶行爲模型，每一個網頁可能被訪問到的次數越多就越重要，這樣的"可能被訪問的次數"也就定義爲網頁的權值，PageRank值。如何計算這個權值呢？PageRank採用如下公式進行計算：

 

其中wj表明第j個網頁的權值；lij只取0、1值，表明從網頁i到網頁j是否存在連接；ni表明網頁i有多少個連向其它網頁的連接；d表明"隨機衝浪"中沿着連接訪問網頁的平均次數。選擇合適的初始數值，遞歸的使用上述公式，便可獲得理想的網頁權值。

2、 Lucene排序計算公式

Lucene的排序公式以下：

 

1)，協調因子，表示文檔（d）中Term(t)出現的百分比，也就是計算查詢條件（q）中不一樣Term(t)，以及在文檔中出現的數量之和，二者的數量之比。一般在文檔中出現查詢Term種類越多，分值越高。

2)，調節因子，不影響索引排序狀況，只在檢索時使用，主要是用來讓排序結果在不一樣的查詢條件之間能夠比較。這個條件是在搜索時候計算。數值是根據每個查詢項權重的平方和計算獲得。計算公式以下：

            

3) ，文檔頻率，表示查詢詞中，每一個Term在對應的結果文檔中(d)中出現的次數。查詢詞出現的次數越多，表示出現頻率越高，文檔的檢索得分就越高。爲了不得到更大的相關性函數，實際中，使用次數的平方跟做爲文檔頻率tf的值，避免數值過分放大。

4) ，逆文檔頻率，檢索匹配文檔數量的反向函數。按照信息理論，文檔出現的次數越少，每一篇文檔的信息量就會越大。因此匹配的文檔數越少，得分就越高。而索引庫中文檔總數越多，找到一篇目標文檔難度越大，相應的信息量也會比較大。

5) ，長度因子，每一個索引詞彙在域中的整體長度決定的，這個參數在索引創建時肯定。數值根據文檔中實際具備的索引項個數肯定。檢索詞長度在文檔總長度中佔的比例越大，長度因子的數值也越大。

 

 

 

4.2 Lucene3.0之結果排序（操做篇）

 

1、 Lucene相關排序流程

 

2、 Lucene相關類

①     Query類：一個抽象類，Lucene檢索結果最終評分的總控制中心。其它評分有關的類和對象都是由Query類來管理和生產。

②     Weight類接口：定義Query權重計算的一個實現接口，能夠被重用。Weight類能夠用來生成Scorer類，也能夠解析評分的詳細信息，另外還定義了獲取Query權值的方法。

③     Scorer類：Lucene評分機制的核心類。類的定義是抽象類，提供的一些抽象基本的計分功能方法提供全部的評分類實現，同時還定義了評分的詳細解析方法，Scorer類內部有一個Similarity對象，用來指明計算公式。

④     Scorer類：Lucene類似度計算的核心抽象類。Similarity類主要處理評分計算，系統缺省使用類DefaultSimilarity類對象

3、 排序控制

使用Sort對象定製排序，經過改變文檔Boost值來改變排序結果以及使用自定義的Similarity方法更改排序

4、 文檔Boost加權排序

①     Boost是指索引創建過程當中，給整篇文檔或者文檔的某一特定域設定的權值因子，在檢索時，優先返回分數高的。

Document和Field兩重Boosting參數。經過Document對象的setBoost()方法和Field對象的setBoost()方法。不一樣在於前者對文檔中每個域都修改了參數，然後者只針對指定域進行修改。

文檔加權=Document-boosting*Field-boosting，默認狀況下爲1，通常不作修改。

②     Sort對象檢索排序

Sort使用時經過實例化對象做爲參數，經過Searcher類的search接口來實現。Sort支持的排序功能以文檔當中的域爲單位，經過這種方法，能夠實現一個或者多個不一樣域的多形式的值排序。

實際使用排序對象Sort進行排序。主要有兩種模式，一種是以字符串表示文檔域的名稱做爲參數指定域排序，一種是直接以排序域的包裝域的包裝類做爲參數進行排序。

Sort對象使用比較簡單，只須要在對文檔索引進行檢索時，在檢索器的Search方法中帶Sort對象做爲參數便可。

1)       Sort對象相關性排序

按照相關性排序時最基本的結果排序方法，使用Sort對象無參數構造函數完成的排序效果至關於Lucene默認的按相關性降序排序。

2)       Sort對象文檔編號排序

某些應用場合須要對全部符合匹配度的結果，按照文檔內部編號排序輸出。使用Sort對象的靜態實例Sort.INDEXORDER來實現

3)       Sort對象獨立域排序

在檢索過程當中，把檢索結果按照某一個特定域排序，很是重要。在使用搜索引擎過程當中，有時會選擇使用時間排序，而在搜索引擎庫中，檢索詞徹底是另一個域的內容，與時間沒有任何關係。這種應用中，檢索關鍵詞的匹配仍然是首要因素，匹配過低或者不匹配的文檔直接沒必要處理，而匹配的文檔則需進一步排序輸出。

    指定的排序域並無進行特別限制，能夠是檢索詞的關聯域，也能夠是文檔中的任意其它域。

4)       Sort對象聯合域排序

多個文檔域聯合排序時，須要注意文檔域的添加次序。排序的結果先按照第一個域排序，而後第二個域做爲次要關鍵字排序。開發時，須要根據本身的須要選擇合適的次序。

5)       Sort對象逆向排序

Sort(field,true)或者Sort(field,false)實現升降序排序。

 

5.作一個相似百度的搜索網站

經過wget爬蟲爬去網站www.bjsxt.com

 

 

三．第三節：利用lucene作一個搜索網站

1.搜索網站製做步驟

1.前面的內容須要提取文本內容，利用jericho來提取html中文本內容，或者用正則表達式匹配提取文本內容

2.利用lucene API建立索引

 

2.Lucene API熟悉

1. analyzer

Analyzer 是分析器，它的做用是把一個字符串按某種規則劃分紅一個個詞語，並去除其中的無效詞語，這裏說的無效詞語是指英文中的「of」、 「the」，中文中的 「的」、「地」等詞語，這些詞語在文章中大量出現，可是自己不包含什麼關鍵信息，去掉有利於縮小索引文件、提升效率、提升命中率。
分詞的規則變幻無窮，但目的只有一個：按語義劃分。這點在英文中比較容易實現，由於英文自己就是以單詞爲單位的，已經用空格分開；而中文則必須以某種方法將連成一片的句子劃分紅一個個詞語。具體劃分方法下面再詳細介紹，這裏只需瞭解分析器的概念便可。

2. document

用戶提供的源是一條條記錄，它們能夠是文本文件、字符串或者數據庫表的一條記錄等等。一條記錄通過索引以後，就是以一個Document的形式存儲在索引文件中的。用戶進行搜索，也是以Document列表的形式返回。

3. field

一個Document能夠包含多個信息域，例如一篇文章能夠包含「標題」、「正文」、「最後修改時間」等信息域，這些信息域就是經過Field在Document中存儲的。
Field有兩個屬性可選：存儲和索引。經過存儲屬性你能夠控制是否對這個Field進行存儲；經過索引屬性你能夠控制是否對該Field進行索引。這看起來彷佛有些廢話，事實上對這兩個屬性的正確組合很重要，下面舉例說明：
仍是以剛纔的文章爲例子，咱們須要對標題和正文進行全文搜索，因此咱們要把索引屬性設置爲真，同時咱們但願能直接從搜索結果中提取文章標題，因此咱們把標題域的存儲屬性設置爲真，可是因爲正文域太大了，咱們爲了縮小索引文件大小，將正文域的存儲屬性設置爲假，當須要時再直接讀取文件；咱們只是但願能從搜索解果中提取最後修改時間，不須要對它進行搜索，因此咱們把最後修改時間域的存儲屬性設置爲真，索引屬性設置爲假。上面的三個域涵蓋了兩個屬性的三種組合，還有一種全爲假的沒有用到，事實上Field不容許你那麼設置，由於既不存儲又不索引的域是沒有意義的。

4. term

term是搜索的最小單位，它表示文檔的一個詞語，term由兩部分組成：它表示的詞語和這個詞語所出現的field。

5. tocken

tocken是term的一次出現，它包含trem文本和相應的起止偏移，以及一個類型字符串。一句話中能夠出現屢次相同的詞語，它們都用同一個term表示，可是用不一樣的tocken，每一個tocken標記該詞語出現的地方。

6. segment

添加索引時並非每一個document都立刻添加到同一個索引文件，它們首先被寫入到不一樣的小文件，而後再合併成一個大索引文件，這裏每一個小文件都是一個segment。

 

四．第四節：lucene的結構

項目進度：前面爬取網站內容並創建了lucene索引，這裏項目添加查詢搜索api調用，作到可以搜索到內容

1.lucene的結構

lucene包括core和sandbox兩部分，其中core是lucene穩定的核心部分，sandbox包含了一些附加功能，例如highlighter、各類分析器。

Lucene core

Lucene core有七個包：analysis，document，index，queryParser，search，store，util。
1. analysis
Analysis包含一些內建的分析器，例如按空白字符分詞的WhitespaceAnalyzer，添加了stopwrod過濾的StopAnalyzer，最經常使用的StandardAnalyzer。
2. document
Document包含文檔的數據結構，例如Document類定義了存儲文檔的數據結構，Field類定義了Document的一個域。
3. index
Index 包含了索引的讀寫類，例如對索引文件的segment進行寫、合併、優化的IndexWriter類和對索引進行讀取和刪除操做的 IndexReader類，這裏要注意的是不要被IndexReader這個名字誤導，覺得它是索引文件的讀取類，實際上刪除索引也是由它完成， IndexWriter只關心如何將索引寫入一個個segment，並將它們合併優化；IndexReader則關注索引文件中各個文檔的組織形式。

 

一、我是中國人

二、我愛個人祖國和人民,國家強大

三、祖國是個人家

 

中 1[1,{4} ]

國 1[ 1,{3}],2[2,{5，10}]

人
4. queryParser
QueryParser 包含了解析查詢語句的類，lucene的查詢語句和sql語句有點相似，有各類保留字，按照必定的語法能夠組成各類查詢。 Lucene有不少種 Query類，它們都繼承自Query，執行各類特殊的查詢，QueryParser的做用就是解析查詢語句，按順序調用各類 Query類查找出結果。
5. search
Search包含了從索引中搜索結果的各類類，例如剛纔說的各類Query類，包括TermQuery、BooleanQuery等就在這個包裏。
6. store
Store包含了索引的存儲類，例如Directory定義了索引文件的存儲結構，FSDirectory爲存儲在文件中的索引，RAMDirectory爲存儲在內存中的索引，MmapDirectory爲使用內存映射的索引。
7. util
Util包含一些公共工具類，例如時間和字符串之間的轉換工具。

 

2. 如何建索引

1. 最簡單的能完成索引的代碼片段

IndexWriter writer = new IndexWriter(「/data/index/」, new StandardAnalyzer(), true);
Document doc = new Document();
doc.add(new Field("title", "lucene introduction", Field.Store.YES, Field.Index.TOKENIZED));
doc.add(new Field("content", "lucene works well", Field.Store.YES, Field.Index.TOKENIZED));
writer.addDocument(doc);
writer.optimize();     //使用代價較高，被放棄，用writer.forceMerge(1),來優化索引
writer.close();

下面咱們分析一下這段代碼。
首先咱們建立了一個writer，並指定存放索引的目錄爲「/data/index」，使用的分析器爲StandardAnalyzer，第三個參數說明若是已經有索引文件在索引目錄下，咱們將覆蓋它們。
而後咱們新建一個document。
咱們向document添加一個field，名字是「title」，內容是「lucene introduction」，對它進行存儲並索引。
再添加一個名字是「content」的field，內容是「lucene works well」，也是存儲並索引。
而後咱們將這個文檔添加到索引中，若是有多個文檔，能夠重複上面的操做，建立document並添加。
添加完全部document，咱們對索引進行優化，優化主要是將多個segment合併到一個，有利於提升索引速度。
隨後將writer關閉，這點很重要。

對，建立索引就這麼簡單！
固然你可能修改上面的代碼得到更具個性化的服務。

2. 將索引直接寫在內存
你須要首先建立一個RAMDirectory，並將其傳給writer，代碼以下：

Directory dir = new RAMDirectory();
IndexWriter writer = new IndexWriter(dir, new StandardAnalyzer(), true);
Document doc = new Document();
doc.add(new Field("title", "lucene introduction", Field.Store.YES, Field.Index.TOKENIZED));
doc.add(new Field("content", "lucene works well", Field.Store.YES, Field.Index.TOKENIZED));
writer.addDocument(doc);
writer.optimize();
writer.close();

3. 索引文本文件
若是你想把純文本文件索引發來，而不想本身將它們讀入字符串建立field，你能夠用下面的代碼建立field：

Field field = new Field("content", new FileReader(file));

這裏的file就是該文本文件。該構造函數其實是讀去文件內容，並對其進行索引，但不存儲。

3. 如何維護索引

索引的維護操做都是由IndexReader類提供。

1. 如何刪除索引
lucene提供了兩種從索引中刪除document的方法，一種是

void deleteDocument(int docNum)

這種方法是根據document在索引中的編號來刪除，每一個document加進索引後都會有個惟一編號，因此根據編號刪除是一種精確刪除，可是這個編號是索引的內部結構，通常咱們不會知道某個文件的編號究竟是幾，因此用處不大。另外一種是

void deleteDocuments(Term term)

這種方法其實是首先根據參數term執行一個搜索操做，而後把搜索到的結果批量刪除了。咱們能夠經過這個方法提供一個嚴格的查詢條件，達到刪除指定document的目的。
下面給出一個例子：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexReader reader = IndexReader.open(dir);
Term term = new Term(field, key);
reader.deleteDocuments(term);
reader.close();

2. 如何更新索引
lucene並無提供專門的索引更新方法，咱們須要先將相應的document刪除，而後再將新的document加入索引。例如：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexReader reader = IndexReader.open(dir);
Term term = new Term(「title」, 「lucene introduction」);
reader.deleteDocuments(term);
reader.close();

IndexWriter writer = new IndexWriter(dir, new StandardAnalyzer(), true);
Document doc = new Document();
doc.add(new Field("title", "lucene introduction", Field.Store.YES, Field.Index.TOKENIZED));
doc.add(new Field("content", "lucene is funny", Field.Store.YES, Field.Index.TOKENIZED));
writer.addDocument(doc);
writer.optimize();
writer.close();

4. 如何搜索

 
lucene 的搜索至關強大，它提供了不少輔助查詢類，每一個類都繼承自Query類，各自完成一種特殊的查詢，你能夠像搭積木同樣將它們任意組合使用，完成一些複雜操做；另外lucene還提供了Sort類對結果進行排序，提供了Filter類對查詢條件進行限制。你或許會不自覺地拿它跟SQL語句進行比較： 「lucene能執行and、or、order by、where、like ‘%xx%’操做嗎？」回答是：「固然沒問題！」

 

1.各類各樣的Query

下面咱們看看lucene到底容許咱們進行哪些查詢操做：

1.1 TermQuery
首先介紹最基本的查詢，若是你想執行一個這樣的查詢：「在content域中包含‘lucene’的document」，那麼你能夠用TermQuery：

Term t = new Term("content", " lucene";
Query query = new TermQuery(t);

1.2 BooleanQuery
若是你想這麼查詢：「在content域中包含java或perl的document」，那麼你能夠創建兩個TermQuery並把它們用BooleanQuery鏈接起來：

TermQuery termQuery1 = new TermQuery(new Term("content", "java");
TermQuery termQuery 2 = new TermQuery(new Term("content", "perl");
BooleanQuery booleanQuery = new BooleanQuery();
booleanQuery.add(termQuery 1, BooleanClause.Occur.SHOULD);
booleanQuery.add(termQuery 2, BooleanClause.Occur.SHOULD);

1.3 WildcardQuery
若是你想對某單詞進行通配符查詢，你能夠用WildcardQuery，通配符包括’?’匹配一個任意字符和’*’匹配零個或多個任意字符，例如你搜索’use*’，你可能找到’useful’或者’useless’：

Query query = new WildcardQuery(new Term("content", "use*");

1.4 PhraseQuery
你可能對中日關係比較感興趣，想查找‘中’和‘日’捱得比較近（5個字的距離內）的文章，超過這個距離的不予考慮，你能夠：

PhraseQuery query = new PhraseQuery();
query.setSlop(5);
query.add(new Term("content ", 「中」));
query.add(new Term(「content」, 「日」));

那麼它可能搜到「中日合做……」、「中方和日方……」，可是搜不到「中國某高層領導說日本欠扁」。

1.5 PrefixQuery
若是你想搜以‘中’開頭的詞語，你能夠用PrefixQuery：

PrefixQuery query = new PrefixQuery(new Term("content ", "中");

1.6 FuzzyQuery
FuzzyQuery用來搜索類似的term，使用Levenshtein算法。假設你想搜索跟‘wuzza’類似的詞語，你能夠：

Query query = new FuzzyQuery(new Term("content", "wuzza");

你可能獲得‘fuzzy’和‘wuzzy’。

1.7 RangeQuery
另外一個經常使用的Query是RangeQuery，你也許想搜索時間域從20060101到20060130之間的document，你能夠用RangeQuery：

RangeQuery query = new RangeQuery(new Term(「time」, 「20060101」), new Term(「time」, 「20060130」), true);

最後的true表示用閉合區間。

2. QueryParser

看了這麼多Query，你可能會問：「不會讓我本身組合各類Query吧，太麻煩了！」固然不會，lucene提供了一種相似於SQL語句的查詢語句，咱們姑且叫它lucene語句，經過它，你能夠把各類查詢一句話搞定，lucene會自動把它們查分紅小塊交給相應Query執行。下面咱們對應每種 Query演示一下：
TermQuery能夠用「field:key」方式，例如「content:lucene」。
BooleanQuery中‘與’用‘+’，‘或’用‘ ’，例如「content:java contenterl」。
WildcardQuery仍然用‘?’和‘*’，例如「content:use*」。
PhraseQuery用‘~’，例如「content:"中日"~5」。
PrefixQuery用‘*’，例如「中*」。
FuzzyQuery用‘~’，例如「content: wuzza ~」。
RangeQuery用‘[]’或‘{}’，前者表示閉區間，後者表示開區間，例如「time:[20060101 TO 20060130]」，注意TO區分大小寫。
你能夠任意組合query string，完成複雜操做，例如「標題或正文包括lucene，而且時間在20060101到20060130之間的文章」能夠表示爲：「+ (title:lucene content:lucene) +time:[20060101 TO 20060130]」。代碼以下：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexSearcher is = new IndexSearcher(dir);
QueryParser parser = new QueryParser("content", new StandardAnalyzer());
Query query = parser.parse("+(title:lucene content:lucene) +time:[20060101 TO 20060130]";
Hits hits = is.search(query);
for (int i = 0; i < hits.length(); i++)
{
Document doc = hits.doc(i);
System.out.println(doc.get("title");
}
is.close();

首先咱們建立一個在指定文件目錄上的IndexSearcher。
而後建立一個使用StandardAnalyzer做爲分析器的QueryParser，它默認搜索的域是content。
接着咱們用QueryParser來parse查詢字串，生成一個Query。
而後利用這個Query去查找結果，結果以Hits的形式返回。
這個Hits對象包含一個列表，咱們挨個把它的內容顯示出來。

3. Filter

filter 的做用就是限制只查詢索引的某個子集，它的做用有點像SQL語句裏的where，但又有區別，它不是正規查詢的一部分，只是對數據源進行預處理，而後交給查詢語句。注意它執行的是預處理，而不是對查詢結果進行過濾，因此使用filter的代價是很大的，它可能會使一次查詢耗時提升一百倍。
最經常使用的filter是RangeFilter和QueryFilter。RangeFilter是設定只搜索指定範圍內的索引；QueryFilter是在上次查詢的結果中搜索。
Filter的使用很是簡單，你只需建立一個filter實例，而後把它傳給searcher。繼續上面的例子，查詢「時間在20060101到20060130之間的文章」除了將限制寫在query string中，你還能夠寫在RangeFilter中：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexSearcher is = new IndexSearcher(dir);
QueryParser parser = new QueryParser("content", new StandardAnalyzer());
Query query = parser.parse("title:lucene content:lucene";
RangeFilter filter = new RangeFilter("time", "20060101", "20060230", true, true);
Hits hits = is.search(query, filter);
for (int i = 0; i < hits.length(); i++)
{
Document doc = hits.doc(i);
System.out.println(doc.get("title");
}
is.close();

4. Sort

有時你想要一個排好序的結果集，就像SQL語句的「order by」，lucene能作到：經過Sort。
Sort sort = new Sort(「time」); //至關於SQL的「order by time」
Sort sort = new Sort(「time」, true); // 至關於SQL的「order by time desc」
下面是一個完整的例子：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexSearcher is = new IndexSearcher(dir);
QueryParser parser = new QueryParser("content", new StandardAnalyzer());
Query query = parser.parse("title:lucene content:lucene";
RangeFilter filter = new RangeFilter("time", "20060101", "20060230", true, true);
Sort sort = new Sort(「time」);
Hits hits = is.search(query, filter, sort);
for (int i = 0; i < hits.length(); i++)
{
Document doc = hits.doc(i);
System.out.println(doc.get("title");
}
is.close();

 

 

 

五．第五節：lucene搜索的優化

 

1.分析器

在前面的概念介紹中咱們已經知道了分析器的做用，就是把句子按照語義切分紅一個個詞語。英文切分已經有了很成熟的分析器： StandardAnalyzer，不少狀況下StandardAnalyzer是個不錯的選擇。甚至你會發現StandardAnalyzer也能對中文進行分詞。
可是咱們的焦點是中文分詞，StandardAnalyzer能支持中文分詞嗎？實踐證實是能夠的，可是效果並很差，搜索「若是」 會把「牛奶不若是汁好喝」也搜索出來，並且索引文件很大。那麼咱們手頭上還有什麼分析器可使用呢？core裏面沒有，咱們能夠在sandbox裏面找到兩個： ChineseAnalyzer和CJKAnalyzer。可是它們一樣都有分詞不許的問題。相比之下用StandardAnalyzer和 ChineseAnalyzer創建索引時間差很少，索引文件大小也差很少，CJKAnalyzer表現會差些，索引文件大且耗時比較長。
要解決問題，首先分析一下這三個分析器的分詞方式。StandardAnalyzer和ChineseAnalyzer都是把句子按單個字切分，也就是說 「牛奶不若是汁好喝」會被它們切分紅「牛 奶 不 如 果 汁 好 喝」；而CJKAnalyzer則會切分紅「牛奶 奶不 不如 若是 果汁 汁好好喝」。這也就解釋了爲何搜索「果汁」都能匹配這個句子。
以上分詞的缺點至少有兩個：匹配不許確和索引文件大。咱們的目標是將上面的句子分解成 「牛奶 不如 果汁好喝」。這裏的關鍵就是語義識別，咱們如何識別「牛奶」是一個詞而「奶不」不是詞語？咱們很天然會想到基於詞庫的分詞法，也就是咱們先獲得一個詞庫，裏面列舉了大部分詞語，咱們把句子按某種方式切分，當獲得的詞語與詞庫中的項匹配時，咱們就認爲這種切分是正確的。這樣切詞的過程就轉變成匹配的過程，而匹配的方式最簡單的有正向最大匹配和逆向最大匹配兩種，說白了就是一個從句子開頭向後進行匹配，一個從句子末尾向前進行匹配。基於詞庫的分詞詞庫很是重要，詞庫的容量直接影響搜索結果，在相同詞庫的前提下，聽說逆向最大匹配優於正向最大匹配。
固然還有別的分詞方法，這自己就是一個學科，我這裏也沒有深刻研究。回到具體應用，咱們的目標是能找到成熟的、現成的分詞工具，避免從新發明車輪。通過網上搜索，用的比較多的是中科院的 ICTCLAS和一個不開放源碼可是免費的JE-Analysis。ICTCLAS有個問題是它是一個動態連接庫， java調用須要本地方法調用，不方便也有安全隱患，並且口碑也確實不大好。JE-Analysis效果還不錯，固然也會有分詞不許的地方，相比比較方便放心。

2. 性能優化

一直到這裏，咱們仍是在討論怎麼樣使lucene跑起來，完成指定任務。利用前面說的也確實能完成大部分功能。可是測試代表lucene的性能並非很好，在大數據量大併發的條件下甚至會有半分鐘返回的狀況。另外大數據量的數據初始化創建索引也是一個十分耗時的過程。那麼如何提升lucene的性能呢？下面從優化建立索引性能和優化搜索性能兩方面介紹。

 

1.優化建立索引性能

這方面的優化途徑比較有限，IndexWriter提供了一些接口能夠控制創建索引的操做，另外咱們能夠先將索引寫入RAMDirectory，再批量寫入FSDirectory，無論怎樣，目的都是儘可能少的文件IO，由於建立索引的最大瓶頸在於磁盤IO。另外選擇一個較好的分析器也能提升一些性能。

1.1 經過設置IndexWriter的參數優化索引創建
setMaxBufferedDocs(int maxBufferedDocs)
控制寫入一個新的segment前內存中保存的document的數目，設置較大的數目能夠加快建索引速度，默認爲10。
setMaxMergeDocs(int maxMergeDocs)
控制一個segment中能夠保存的最大document數目，值較小有利於追加索引的速度，默認Integer.MAX_VALUE，無需修改。
setMergeFactor(int mergeFactor)
控制多個segment合併的頻率，值較大時創建索引速度較快，默認是10，能夠在創建索引時設置爲100。

1.2 經過RAMDirectory緩寫提升性能
咱們能夠先把索引寫入RAMDirectory，達到必定數量時再批量寫進FSDirectory，減小磁盤IO次數。

FSDirectory fsDir = FSDirectory.getDirectory("/data/index", true);
RAMDirectory ramDir = new RAMDirectory();
IndexWriter fsWriter = new IndexWriter(fsDir, new StandardAnalyzer(), true);
IndexWriter ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
while (there are documents to index)
{
... create Document ...
ramWriter.addDocument(doc);
if (condition for flushing memory to disk has been met)
{
fsWriter.addIndexes(new Directory[] { ramDir });
ramWriter.close();
ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
}
}

1.3 選擇較好的分析器
這個優化主要是對磁盤空間的優化，能夠將索引文件減少將近一半，相同測試數據下由600M減小到380M。可是對時間並無什麼幫助，甚至會須要更長時間，由於較好的分析器須要匹配詞庫，會消耗更多cpu，測試數據用StandardAnalyzer耗時133分鐘；用MMAnalyzer耗時150分鐘。

 

2. 優化搜索性能

 
雖然創建索引的操做很是耗時，可是那畢竟只在最初建立時才須要，平時只是少許的維護操做，更況且這些能夠放到一個後臺進程處理，並不影響用戶搜索。咱們建立索引的目的就是給用戶搜索，因此搜索的性能纔是咱們最關心的。下面就來探討一下如何提升搜索性能。

2.1 將索引放入內存
這是一個最直觀的想法，由於內存比磁盤快不少。Lucene提供了RAMDirectory能夠在內存中容納索引：

Directory fsDir = FSDirectory.getDirectory(「/data/index/」, false);
Directory ramDir = new RAMDirectory(fsDir);
Searcher searcher = new IndexSearcher(ramDir);

可是實踐證實RAMDirectory和FSDirectory速度差很少，當數據量很小時二者都很是快，當數據量較大時（索引文件400M）RAMDirectory甚至比FSDirectory還要慢一點，這確實讓人出乎意料。
並且lucene的搜索很是耗內存，即便將400M的索引文件載入內存，在運行一段時間後都會out of memory，因此我的認爲載入內存的做用並不大。

2.2 優化時間範圍限制
既然載入內存並不能提升效率，必定有其它瓶頸，通過測試發現最大的瓶頸竟然是時間範圍限制，那麼咱們能夠怎樣使時間範圍限制的代價最小呢？
當須要搜索指定時間範圍內的結果時，能夠：
一、用RangeQuery，設置範圍，可是RangeQuery的實現其實是將時間範圍內的時間點展開，組成一個個BooleanClause加入到 BooleanQuery中查詢，所以時間範圍不可能設置太大，經測試，範圍超過一個月就會拋 BooleanQuery.TooManyClauses，能夠經過設置 BooleanQuery.setMaxClauseCount (int maxClauseCount)擴大，可是擴大也是有限的，而且隨着maxClauseCount擴大，佔用內存也擴大
二、用 RangeFilter代替RangeQuery，經測試速度不會比RangeQuery慢，可是仍然有性能瓶頸，查詢的90%以上時間耗費在 RangeFilter，研究其源碼發現RangeFilter其實是首先遍歷全部索引，生成一個BitSet，標記每一個document，在時間範圍內的標記爲true，不在的標記爲false，而後將結果傳遞給Searcher查找，這是十分耗時的。
三、進一步提升性能，這個又有兩個思路：
a、緩存Filter結果。既然RangeFilter的執行是在搜索以前，那麼它的輸入都是必定的，就是IndexReader，而 IndexReader是由Directory決定的，因此能夠認爲RangeFilter的結果是由範圍的上下限決定的，也就是由具體的 RangeFilter對象決定，因此咱們只要以RangeFilter對象爲鍵，將filter結果BitSet緩存起來便可。lucene API 已經提供了一個CachingWrapperFilter類封裝了Filter及其結果，因此具體實施起來咱們能夠 cache CachingWrapperFilter對象，須要注意的是，不要被CachingWrapperFilter的名字及其說明誤導， CachingWrapperFilter看起來是有緩存功能，但的緩存是針對同一個filter的，也就是在你用同一個filter過濾不一樣 IndexReader時，它能夠幫你緩存不一樣IndexReader的結果，而咱們的需求偏偏相反，咱們是用不一樣filter過濾同一個 IndexReader，因此只能把它做爲一個封裝類。
b、下降時間精度。研究Filter的工做原理能夠看出，它每次工做都是遍歷整個索引的，因此時間粒度越大，對比越快，搜索時間越短，在不影響功能的狀況下，時間精度越低越好，有時甚至犧牲一點精度也值得，固然最好的狀況是根本不做時間限制。
下面針對上面的兩個思路演示一下優化結果（都採用800線程隨機關鍵詞隨即時間範圍）：
第一組，時間精度爲秒：
方式 直接用RangeFilter 使用cache 不用filter
平均每一個線程耗時 10s 1s 300ms

第二組，時間精度爲天
方式 直接用RangeFilter 使用cache 不用filter
平均每一個線程耗時 900ms 360ms 300ms

由以上數據能夠得出結論：
一、 儘可能下降時間精度，將精度由秒換整天帶來的性能提升甚至比使用cache還好，最好不使用filter。
二、 在不能下降時間精度的狀況下，使用cache能帶了10倍左右的性能提升。

2.3 使用更好的分析器
這個跟建立索引優化道理差很少，索引文件小了搜索天然會加快。固然這個提升也是有限的。較好的分析器相對於最差的分析器對性能的提高在20%如下。

3. 一些優化經驗

 

1.關鍵詞區分大小寫
or AND TO等關鍵詞是區分大小寫的，lucene只認大寫的，小寫的當作普通單詞。

2. 讀寫互斥性
同一時刻只能有一個對索引的寫操做，在寫的同時能夠進行搜索

3. 文件鎖
在寫索引的過程當中強行退出將在tmp目錄留下一個lock文件，使之後的寫操做沒法進行，能夠將其手工刪除

4. 時間格式
lucene只支持一種時間格式yyMMddHHmmss，因此你傳一個yy-MM-dd HH:mm:ss的時間給lucene它是不會看成時間來處理的

5. 設置boost
有些時候在搜索時某個字段的權重須要大一些，例如你可能認爲標題中出現關鍵詞的文章比正文中出現關鍵詞的文章更有價值，你能夠把標題的boost設置的更大，那麼搜索結果會優先顯示標題中出現關鍵詞的文章（沒有使用排序的前題下）。使用方法：
Field. setBoost(float boost);默認值是1.0，也就是說要增長權重的須要設置得比1大。

 

 

 

wget -o /tmp/wget.log -P /root/data  --non-parent --non-verbose -m -D www.bjsxt.com   -N --convert-links --random-wait -A html,HTML http://www.bjsxt.com

 

-R :除某些後綴以外的文件不抓去

-R js,jpg,jpeg,png,gif,css,flv,exe,txt,mp4,mp3

 

 

 

null