全文檢索引擎 Solr 部署與基本原理

時間 2019-11-18

標籤全文檢索引擎 solr 部署基本原理简体版

原文原文鏈接

全文檢索引擎 Solr 部署與基本原理

搜索引擎Solr環境搭建實例

關於 solr ， schema.xml 的配置說明

全文檢索引擎Solr系列—–全文檢索基本原理

1、搜索引擎Solr環境搭建實例

Solr服務器採用java5開發的，是基於Lucene全文搜索的。要想搭建Solr，首先進行java環境的配置，安裝對應的jdk以及tomcat，在此就很少講。html

如下是在jdk1.7和tomcat1.7的環境下搭建最新版本的solr4.10.3。java

具體步驟以下：web

1.到官網http://lucene.apache.org/solr/mirrors-solr-latest-redir.html下載.算法

2.建目錄/webapps/mysolr/solr數據庫

3.解壓壓縮包solr-4.10.3，找到example下的webapps中的solr.war包，並將其解壓。apache

4.將解壓完的war包（solr文件夾）拷貝到第2步建的目錄：/webapps/mysolr下tomcat

5.拷貝兩個地方的jar包到/webapps/mysolr/solr/WEB-INF/lib下服務器

（1）example下lib包的全部jar包網絡

（2）example下lib包下的ext包中的全部jar包app

6.拷貝example/resource下的log4j.properties文件到/webapps/mysolr/solr/classpath 下

7.solrhome的配置：

先建立一個solrhome目錄：/webapps/mysolr/solrhome，而後將example/solr下的全部文件拷貝到/webapps/mysolr/solrhome下

而後修改配置文件/webapps/mysolr/solr/WEB-INF/web.xml，將solr/home的註解放開並配置以下：

<env-entry> 
  <env-entry-name>solr/home</env-entry-name> 
  <env-entry-value>/webapps/mysolr/solrhome</env-entry-value> 
  <env-entry-type>java.lang.String</env-entry-type> 
</env-entry>

8.把/webapps/mysolr/solr部署到tomcat下，並啓動tomcat。

以上就完成了solr環境的基本搭建，訪問http://loclhost:8080/solr 可看到以下界面：

Solr3.6.1 在Tomcat6下的環境搭建 http://www.cnblogs.com/chinway/p/6187260.html

基於Tomcat的Solr3.5集羣部署 http://www.cnblogs.com/chinway/p/6187271.html

在Linux上使用Nginx爲Solr集羣作負載均衡 http://www.cnblogs.com/chinway/p/6187292.html

Linux下安裝使用Solr http://www.cnblogs.com/chinway/p/6187322.html

Solr實現Low Level查詢解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html

Solr 4.0 部署實例教程 http://www.cnblogs.com/chinway/p/6187382.html

2、關於 solr ， schema.xml 的配置說明

schema.xml位於solr/conf/目錄下，相似於數據表配置文件，

定義了加入索引的數據的數據類型，主要包括type、fields和其餘的一些缺省設置。

一、先來看下type節點，這裏面定義FieldType子節點，包括name,class,positionIncrementGap等一些參數。

name：就是這個FieldType的名稱。
class：指向org.apache.solr.analysis包裏面對應的class名稱，用來定義這個類型的行爲。

 1 < schema name = "example" version = "1.2" >
 2 < types >
 3 < fieldType name = "string" class = "solr.StrField" sortMissingLast = "true" omitNorms = "true" />
 4 < fieldType name = "boolean" class = "solr.BoolField" sortMissingLast = "true" omitNorms = "true" />
 5 < fieldtype name = "binary" class = "solr.BinaryField" />
 6 < fieldType name = "int" class = "solr.TrieIntField" precisionStep = "0" omitNorms = "true"
 7 positionIncrementGap = "0" />
 8 < fieldType name = "float" class = "solr.TrieFloatField" precisionStep = "0" omitNorms = "true"
 9 positionIncrementGap = "0" />
10 < fieldType name = "long" class = "solr.TrieLongField" precisionStep = "0" omitNorms = "true"
11 positionIncrementGap = "0" />
12 < fieldType name = "double" class = "solr.TrieDoubleField" precisionStep = "0" omitNorms = "true"
13 positionIncrementGap = "0" />
14 ...
15 </ types >
16 ...
17 </ schema >

必要的時候fieldType還須要本身定義這個類型的數據在創建索引和進行查詢的時候要使用的分析器analyzer，包括分詞和過濾，以下：

 1 < fieldType name = "text_ws" class = "solr.TextField" positionIncrementGap = "100" >
 2 < analyzer >
 3 < tokenizer class = "solr.WhitespaceTokenizerFactory" />
 4 </ analyzer >
 5 </ fieldType >
 6 < fieldType name = "text" class = "solr.TextField" positionIncrementGap = "100" >
 7 < analyzer type = "index" >
 8 <!--這個分詞包是空格分詞，在向索引庫添加text類型的索引時，Solr會首先用空格進行分詞
 9 而後把分詞結果依次使用指定的過濾器進行過濾，最後剩下的結果，纔會加入到索引庫中以備查詢。
10 注意:Solr的analysis包並無帶支持中文的包，須要本身添加中文分詞器，google下。
11 -->
12 < tokenizer class = "solr.WhitespaceTokenizerFactory" />
13 <!-- in this example, we will only use synonyms at query time
14 < filter class = "solr.SynonymFilterFactory" synonyms = "index_synonyms.txt"
15 ignoreCase = "true" expand = "false" />
16 -->
17 <!-- Case insensitive stop word removal.
18 add enablePositionIncrements = true in both the index and query
19 analyzers to leave a 'gap' for more accurate phrase queries.
20 -->
21 < filter class = "solr.StopFilterFactory"
22 ignoreCase = "true"
23 words = "stopwords.txt"
24 enablePositionIncrements = "true"
25 />
26 < filter class = "solr.WordDelimiterFilterFactory" generateWordParts = "1"
27 generateNumberParts = "1" catenateWords = "1" catenateNumbers = "1"
28 catenateAll = "0" splitOnCaseChange = "1" />
29 < filter class = "solr.LowerCaseFilterFactory" />
30 < filter class = "solr.SnowballPorterFilterFactory" language = "English"
31 protected = "protwords.txt" />
32 </ analyzer >
33 < analyzer type = "query" >
34 < tokenizer class = "solr.WhitespaceTokenizerFactory" />
35 < filter class = "solr.SynonymFilterFactory" synonyms = "synonyms.txt" ignoreCase = "true"
36 expand = "true" />
37 < filter class = "solr.StopFilterFactory"
38 ignoreCase = "true"
39 words = "stopwords.txt"
40 enablePositionIncrements = "true"
41 />
42 < filter class = "solr.WordDelimiterFilterFactory" generateWordParts = "1"
43 generateNumberParts = "1" catenateWords = "0" catenateNumbers = "0"
44 catenateAll = "0" splitOnCaseChange = "1" />
45 < filter class = "solr.LowerCaseFilterFactory" />
46 < filter class = "solr.SnowballPorterFilterFactory" language = "English"
47 protected = "protwords.txt" />
48 </ analyzer >
49 </ fieldType >

二、再來看下fields節點內定義具體的字段（相似數據庫的字段），含有如下屬性：

name：字段名
type：以前定義過的各類FieldType
indexed：是否被索引
stored：是否被存儲（若是不須要存儲相應字段值，儘可能設爲false）
multiValued：是否有多個值（對可能存在多值的字段儘可能設置爲true，避免建索引時拋出錯誤）

 1 < fields >
 2 < field name = "id" type = "integer" indexed = "true" stored = "true" required = "true" />
 3 < field name = "name" type = "text" indexed = "true" stored = "true" />
 4 < field name = "summary" type = "text" indexed = "true" stored = "true" />
 5 < field name = "author" type = "string" indexed = "true" stored = "true" />
 6 < field name = "date" type = "date" indexed = "false" stored = "true" />
 7 < field name = "content" type = "text" indexed = "true" stored = "false" />
 8 < field name = "keywords" type = "keyword_text" indexed = "true" stored = "false" multiValued = "true" />
 9 <!--拷貝字段-->
10 < field name = "all" type = "text" indexed = "true" stored = "false" multiValued = "true" />
11 </ fields >

三、建議創建一個拷貝字段，將全部的全文本字段複製到一個字段中，以便進行統一的檢索：

如下是拷貝設置：

1 < copyField source = "name" dest = "all" />
2 < copyField source = "summary" dest = "all" />

四、動態字段，沒有具體名稱的字段，用dynamicField字段

如：name爲*_i，定義它的type爲int，那麼在使用這個字段的時候，任務以_i結果的字段都被認爲符合這個定義。如name_i, school_i

1 < dynamicField name = "*_i" type = "int" indexed = "true" stored = "true" />
2 < dynamicField name = "*_s" type = "string" indexed = "true" stored = "true" />
3 < dynamicField name = "*_l" type = "long" indexed = "true" stored = "true" />
4 < dynamicField name = "*_t" type = "text" indexed = "true" stored = "true" />
5 < dynamicField name = "*_b" type = "boolean" indexed = "true" stored = "true" />
6 < dynamicField name = "*_f" type = "float" indexed = "true" stored = "true" />
7 < dynamicField name = "*_d" type = "double" indexed = "true" stored = "true" />
8 < dynamicField name = "*_dt" type = "date" indexed = "true" stored = "true" />

schema.xml文檔註釋中的信息：

一、爲了改進性能，能夠採起如下幾種措施：

將全部只用於搜索的，而不須要做爲結果的field（特別是一些比較大的field）的stored設置爲false
將不須要被用於搜索的，而只是做爲結果返回的field的indexed設置爲false
刪除全部沒必要要的copyField聲明
爲了索引字段的最小化和搜索的效率，將全部的 text fields的index都設置成field，而後使用copyField將他們都複製到一個總的 text field上，而後對他進行搜索。
爲了最大化搜索效率，使用java編寫的客戶端與solr交互（使用流通訊）
在服務器端運行JVM（省去網絡通訊），使用盡量高的Log輸出等級，減小日誌量。

二、< schema name =" example " version =" 1.2 " >

name：標識這個schema的名字
version：如今版本是1.2

三、filedType

1 < fieldType name =" string " class =" solr.StrField " sortMissingLast =" true " omitNorms =" true " />

name：標識而已。
class和其餘屬性決定了這個fieldType的實際行爲。（class以solr開始的，都是在org.appache.solr.analysis包下）

可選的屬性：

sortMissingLast和sortMissingFirst兩個屬性是用在能夠內在使用String排序的類型上（包括：string,boolean,sint,slong,sfloat,sdouble,pdate）。
sortMissingLast="true"，沒有該field的數據排在有該field的數據以後，而無論請求時的排序規則。
sortMissingFirst="true"，跟上面倒過來唄。
2個值默認是設置成false

StrField類型不被分析，而是被逐字地索引/存儲。

StrField和TextField都有一個可選的屬性「compressThreshold」，保證壓縮到不小於一個大小（單位：char）

1  < fieldType name =" text " class =" solr.TextField " positionIncrementGap =" 100 " >

solr.TextField 容許用戶經過分析器來定製索引和查詢，分析器包括一個分詞器（tokenizer）和多個過濾器（filter）

positionIncrementGap：可選屬性，定義在同一個文檔中此類型數據的空白間隔，避免短語匹配錯誤。

　　name: 字段類型名
　　class: java類名
　　indexed: 缺省true。說明這個數據應被搜索和排序，若是數據沒有indexed，則stored應是true。
　　stored: 缺省true。說明這個字段被包含在搜索結果中是合適的。若是數據沒有stored,則indexed應是true。
　　sortMissingLast: 指沒有該指定字段數據的document排在有該指定字段數據的document的後面
　　sortMissingFirst: 指沒有該指定字段數據的document排在有該指定字段數據的document的前面
　　omitNorms: 字段的長度不影響得分和在索引時不作boost時，設置它爲true。通常文本字段不設置爲true。
　　termVectors: 若是字段被用來作more like this 和highlight的特性時應設置爲true。
　　compressed: 字段是壓縮的。這可能致使索引和搜索變慢，但會減小存儲空間，只有StrField和TextField是能夠壓縮，這一般適合字段的長度超過200個字符。
　　multiValued: 字段多於一個值的時候，可設置爲true。
　　positionIncrementGap: 和multiValued
一塊兒使用，設置多個值之間的虛擬空白的數量

1  < tokenizer class =" solr.WhitespaceTokenizerFactory " />

空格分詞，精確匹配。

1  < filter class =" solr.WordDelimiterFilterFactory " generateWordParts =" 1 " generateNumberParts =" 1 " catenateWords =" 1 " catenateNumbers =" 1 " catenateAll =" 0 " splitOnCaseChange =" 1 " />

在分詞和匹配時，考慮 "-"連字符，字母數字的界限，非字母數字字符，這樣 "wifi"或"wi fi"都能匹配"Wi-Fi"。

1 < filter class =" solr.SynonymFilterFactory " synonyms =" synonyms.txt " ignoreCase =" true " expand =" true " />

同義詞

1  < filter class =" solr.StopFilterFactory " ignoreCase =" true " words =" stopwords.txt " enablePositionIncrements =" true " />

在禁用字（stopword）刪除後，在短語間增長間隔

stopword：即在創建索引過程當中（創建索引和搜索）被忽略的詞，好比is this等經常使用詞。在conf/stopwords.txt維護。

四、fields

1 < field name =" id " type =" string " indexed =" true " stored =" true " required =" true " />

name：標識而已。
type：先前定義的類型。
indexed：是否被用來創建索引（關係到搜索和排序）
stored：是否儲存
compressed：[false]，是否使用gzip壓縮（只有TextField和StrField能夠壓縮）
mutiValued：是否包含多個值
omitNorms：是否忽略掉Norm，能夠節省內存空間，只有全文本field和need an index-time boost的field須要norm。（具體沒看懂，註釋裏有矛盾）
termVectors：[false]，當設置true，會存儲 term vector。當使用MoreLikeThis，用來做爲類似詞的field應該存儲起來。
termPositions：存儲 term vector中的地址信息，會消耗存儲開銷。
termOffsets：存儲 term vector 的偏移量，會消耗存儲開銷。
default：若是沒有屬性須要修改，就能夠用這個標識下。

< field name =" text " type =" text " indexed =" true " stored =" false " multiValued =" true " />

一應俱全（有點誇張）的field，包含全部可搜索的text fields，經過copyField實現。

< copyField source =" cat " dest =" text " />

< copyField source =" name " dest =" text " />

< copyField source =" manu " dest =" text " />

< copyField source =" features " dest =" text " />

< copyField source =" includes " dest =" text " />

在添加索引時，將全部被拷貝field（如cat）中的數據拷貝到text field中

做用：

將多個field的數據放在一塊兒同時搜索，提供速度
將一個field的數據拷貝到另外一個，能夠用2種不一樣的方式來創建索引。

< dynamicField name =" *_i " type =" int " indexed =" true " stored =" true " />

若是一個field的名字沒有匹配到，那麼就會用動態field試圖匹配定義的各類模式。

"*"只能出如今模式的最前和最後
較長的模式會被先去作匹配
若是2個模式同時匹配上，最早定義的優先

1  < dynamicField name =" * " type =" ignored " multiValued=" true " />

若是經過上面的匹配都沒找到，能夠定義這個，而後定義個type，當String處理。（通常不會發生）

但若不定義，找不到匹配會報錯。

五、其餘一些標籤

1 < uniqueKey > id </ uniqueKey >

文檔的惟一標識，必須填寫這個field（除非該field被標記required="false"），不然solr創建索引報錯。

< defaultSearchField > text </ defaultSearchField >

若是搜索參數中沒有指定具體的field，那麼這是默認的域。

1 < solrQueryParser defaultOperator =" OR " />

配置搜索參數短語間的邏輯，能夠是"AND|OR"。

Solr3.6.1 在Tomcat6下的環境搭建 http://www.cnblogs.com/chinway/p/6187260.html

基於Tomcat的Solr3.5集羣部署 http://www.cnblogs.com/chinway/p/6187271.html

在Linux上使用Nginx爲Solr集羣作負載均衡 http://www.cnblogs.com/chinway/p/6187292.html

Linux下安裝使用Solr http://www.cnblogs.com/chinway/p/6187322.html

Solr實現Low Level查詢解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html

Solr 4.0 部署實例教程 http://www.cnblogs.com/chinway/p/6187382.html

3、全文檢索引擎Solr系列—–全文檢索基本原理

新華字典,咱們都使用過，如叫你翻開第38頁，找到「坑爹」所在的位置，此時你會怎麼查呢？毫無疑問，你的眼睛會從38頁的第一個字開始從頭到尾地掃描，直到找到「坑爹」二字爲止。這種搜索方法叫作順序掃描法。對於少許的數據，使用順序掃描是夠用的。可是媽媽叫你查出坑爹的「坑」字在哪一頁時，你要是從第一頁的第一個字逐個的掃描下去，那你真的是被坑了。此時你就須要用到索引。索引記錄了「坑」字在哪一頁，你只需在索引中找到「坑」字，而後找到對應的頁碼，答案就出來了。由於在索引中查找「坑」字是很是快的，由於你知道它的偏旁，所以也就可迅速定位到這個字。

那麼新華字典的目錄（索引表）是怎麼編寫而成的呢？首先對於新華字典這本書來講，除去目錄後，這本書就是一堆沒有結構的數據集。可是聰明的人類善於思考總結，發現每一個字都會對應到一個頁碼，好比「坑」字就在第38頁，「爹」字在第90頁。因而他們就從中提取這些信息，構形成一個有結構的數據。相似數據庫中的表結構：

word    page_no
---------------
坑        38
爹        90
...       ...

這樣就造成了一個完整的目錄（索引庫），查找的時候就很是方便了。對於全文檢索也是相似的原理，它能夠歸結爲兩個過程：1.索引建立（Indexing）2. 搜索索引（Search）。那麼索引究竟是如何建立的呢？索引裏面存放的又是什麼東西呢？搜索的的時候又是如何去查找索引的呢？帶着這一系列問題繼續往下看。

索引

Solr/Lucene採用的是一種反向索引，所謂反向索引：就是從關鍵字到文檔的映射過程，保存這種映射這種信息的索引稱爲反向索引

左邊保存的是字符串序列
右邊是字符串的文檔（Document）編號鏈表，稱爲倒排表（Posting List）

字段串列表和文檔編號鏈表二者構成了一個字典。如今想搜索」lucene」，那麼索引直接告訴咱們，包含有」lucene」的文檔有：2，3，10，35，92，而無需在整個文檔庫中逐個查找。若是是想搜既包含」lucene」又包含」solr」的文檔，那麼與之對應的兩個倒排表去交集便可得到：三、十、3五、92。

索引建立

假設有以下兩個原始文檔：
文檔一：Students should be allowed to go out with their friends, but not allowed to drink beer.
文檔二：My friend Jerry went to school to see his students but found them drunk which is not allowed.
建立過程大概分爲以下步驟：

一：把原始文檔交給分詞組件(Tokenizer)
分詞組件(Tokenizer)會作如下幾件事情(這個過程稱爲：Tokenize)，處理獲得的結果是詞彙單元（Token）

將文檔分紅一個一個單獨的單詞
去除標點符號
去除停詞(stop word)
- 所謂停詞(Stop word)就是一種語言中沒有具體含義，於是大多數狀況下不會做爲搜索的關鍵詞，這樣一來建立索引時能減小索引的大小。英語中停詞(Stop word)如：」the」、」a」、」this」，中文有：」的，得」等。不一樣語種的分詞組件(Tokenizer)，都有本身的停詞(stop word)集合。通過分詞(Tokenizer)後獲得的結果稱爲詞彙單元(Token)。上例子中，便獲得如下詞彙單元(Token)：
```
"Students"，"allowed"，"go"，"their"，"friends"，"allowed"，"drink"，"beer"，"My"，"friend"，"Jerry"，"went"，"school"，"see"，"his"，"students"，"found"，"them"，"drunk"，"allowed"
```

二：詞彙單元(Token)傳給語言處理組件(Linguistic Processor)
語言處理組件(linguistic processor)主要是對獲得的詞元(Token)作一些語言相關的處理。對於英語，語言處理組件(Linguistic Processor)通常作如下幾點：

變爲小寫(Lowercase)。
將單詞縮減爲詞根形式，如」cars」到」car」等。這種操做稱爲：stemming。
將單詞轉變爲詞根形式，如」drove」到」drive」等。這種操做稱爲：lemmatization。

語言處理組件(linguistic processor)處理獲得的結果稱爲詞(Term)，例子中通過語言處理後獲得的詞(Term)以下：

"student"，"allow"，"go"，"their"，"friend"，"allow"，"drink"，"beer"，"my"，"friend"，"jerry"，"go"，"school"，"see"，"his"，"student"，"find"，"them"，"drink"，"allow"。

通過語言處理後，搜索drive時drove也能被搜索出來。Stemming 和 lemmatization的異同：

相同之處：
1. Stemming和lemmatization都要使詞彙成爲詞根形式。
二者的方式不一樣：
1. Stemming採用的是」縮減」的方式：」cars」到」car」，」driving」到」drive」。
2. Lemmatization採用的是」轉變」的方式：」drove」到」drove」，」driving」到」drive」。
二者的算法不一樣：
1. Stemming主要是採起某種固定的算法來作這種縮減，如去除」s」，去除」ing」加」e」，將」ational」變爲」ate」，將」tional」變爲」tion」。
2. Lemmatization主要是採用事先約定的格式保存某種字典中。好比字典中有」driving」到」drive」，」drove」到」drive」，」am, is, are」到」be」的映射，作轉變時，按照字典中約定的方式轉換就能夠了。
3. Stemming和lemmatization不是互斥關係，是有交集的，有的詞利用這兩種方式都能達到相同的轉換。

三：獲得的詞(Term)傳遞給索引組件(Indexer)

利用獲得的詞(Term)建立一個字典

Term    Document ID
student     1
allow       1
go          1
their       1
friend      1
allow       1
drink       1
beer        1
my          2
friend      2
jerry       2
go          2
school      2
see         2
his         2
student     2
find        2
them        2
drink       2
allow       2

對字典按字母順序排序：

Term    Document ID
allow       1
allow       1
allow       2
beer        1
drink       1
drink       2
find        2
friend      1
friend      2
go          1
go          2
his         2
jerry       2
my          2
school      2
see         2
student     1
student     2
their       1
them        2

合併相同的詞(Term)成爲文檔倒排(Posting List)鏈表
- Document Frequency：文檔頻次，表示多少文檔出現過此詞(Term)
- Frequency：詞頻，表示某個文檔中該詞(Term)出現過幾回

對詞(Term) 「allow」來說，總共有兩篇文檔包含此詞(Term)，詞（Term)後面的文檔鏈表總共有兩個，第一個表示包含」allow」的第一篇文檔，即1號文檔，此文檔中，」allow」出現了2次，第二個表示包含」allow」的第二個文檔，是2號文檔，此文檔中，」allow」出現了1次

至此索引建立完成，搜索」drive」時，」driving」，」drove」，」driven」也可以被搜到。由於在索引中，」driving」，」drove」，」driven」都會通過語言處理而變成」drive」，在搜索時，若是您輸入」driving」，輸入的查詢語句一樣通過分詞組件和語言處理組件處理的步驟，變爲查詢」drive」，從而能夠搜索到想要的文檔。

搜索步驟

搜索」microsoft job」，用戶的目的是但願在微軟找一份工做，若是搜出來的結果是:」Microsoft does a good job at software industry…」，這就與用戶的指望偏離太遠了。如何進行合理有效的搜索，搜索出用戶最想要得結果呢？搜索主要有以下步驟：

一：對查詢內容進行詞法分析、語法分析、語言處理

詞法分析：區分查詢內容中單詞和關鍵字，好比：english and janpan，」and」就是關鍵字，」english」和」janpan」是普通單詞。
根據查詢語法的語法規則造成一棵樹
語言處理，和建立索引時處理方式是同樣的。好比：leaned–>lean，driven–>drive

二：搜索索引，獲得符合語法樹的文檔集合
三：根據查詢語句與文檔的相關性，對結果進行排序

咱們把查詢語句也看做是一個文檔，對文檔與文檔之間的相關性（relevance）進行打分（scoring），分數高比較越相關，排名就越靠前。固然還能夠人工影響打分，好比百度搜索，就不必定徹底按照相關性來排名的。

如何評判文檔之間的相關性？一個文檔由多個（或者一個）詞（Term）組成，好比：」solr」，「toturial」，不一樣的詞可能重要性不同，好比solr就比toturial重要，若是一個文檔出現了10次toturial，但只出現了一次solr，而另外一文檔solr出現了4次，toturial出現一次，那麼後者頗有可能就是咱們想要的搜的結果。這就引伸出權重（Term weight）的概念。

權重表示該詞在文檔中的重要程度，越重要的詞固然權重越高，所以在計算文檔相關性時影響力就更大。經過詞之間的權重獲得文檔相關性的過程叫作空間向量模型算法(Vector Space Model)

影響一個詞在文檔中的重要性主要有兩個方面：

Term Frequencey（tf），Term在此文檔中出現的頻率，ft越大表示越重要
Document Frequency（df），表示有多少文檔中出現過這個Trem，df越大表示越不重要
物以希爲貴，你們都有的東西，天然就不那麼貴重了，只有你專有的東西表示這個東西很珍貴，權重的公式：

空間向量模型

文檔中詞的權重看做一個向量

Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, …… ,weight N}

把欲要查詢的語句看做一個簡單的文檔，也用向量表示：

Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… , weight N}

把搜索出的文檔向量及查詢向量放入N維度的空間中，每一個詞表示一維：

夾角越小，表示越類似，相關性越大

Solr3.6.1 在Tomcat6下的環境搭建 http://www.cnblogs.com/chinway/p/6187260.html

基於Tomcat的Solr3.5集羣部署 http://www.cnblogs.com/chinway/p/6187271.html

在Linux上使用Nginx爲Solr集羣作負載均衡 http://www.cnblogs.com/chinway/p/6187292.html

Linux下安裝使用Solr http://www.cnblogs.com/chinway/p/6187322.html

Solr實現Low Level查詢解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html

Solr 4.0 部署實例教程 http://www.cnblogs.com/chinway/p/6187382.html

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

全文檢索引擎 Solr 部署與基本原理

全文檢索引擎 Solr 部署與基本原理

搜索引擎Solr環境搭建實例

關於 solr ， schema.xml 的配置說明

全文檢索引擎Solr系列—–全文檢索基本原理

1、搜索引擎Solr環境搭建實例

2、 關於 solr ， schema.xml 的配置說明

3、全文檢索引擎Solr系列—–全文檢索基本原理

索引

索引建立

搜索步驟

空間向量模型

2、關於 solr ， schema.xml 的配置說明