本文記錄筆者在閱讀《Solr實(shí)戰(zhàn)》的讀書(shū)筆記，將筆者認(rèn)為重要的內(nèi)容摘錄出來(lái)。

Solr擅長(zhǎng)處理的數(shù)據(jù)類(lèi)型

以文本為中心

讀主導(dǎo) 文檔被讀取的次數(shù)遠(yuǎn)大于被創(chuàng)建和更新的次數(shù)

面向文檔

靈活的模式

大量的數(shù)據(jù)

底層使用Lucene

導(dǎo)入示例數(shù)據(jù)到已有core

cd C:Program FilesApache Software Foundationsolr-6.6.5exampleexampledocs java -Durl=http://localhost:8983/solr/test1/update -jar post.jar *.xml

排名檢索

根據(jù)score字段在內(nèi)部相對(duì)排名
返回的搜索結(jié)果按照得分由高到低排序，文檔的分越高，說(shuō)明與該查詢(xún)?cè)较嚓P(guān)。

分頁(yè)

默認(rèn)的頁(yè)面調(diào)整頁(yè)面大小為10，調(diào)整start參數(shù)(start=0 第一頁(yè))，因?yàn)榈讓拥腖ucene索引并未對(duì)一睇返回大量文檔做成優(yōu)化設(shè)計(jì)，所以盡可能使用小頁(yè)面非常重要。相反，Lucene優(yōu)化了查詢(xún)處理，底層的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)用于最大限度滿(mǎn)足文檔匹配和評(píng)分。

排序

搜索結(jié)果根據(jù)相關(guān)度得分將文檔按降序排列，還可以根據(jù)文檔的其他字段進(jìn)行排序。文檔得分相同時(shí)，他們以索引的次序返回，該次序基于Lucene的內(nèi)部文檔ID。這個(gè)文檔ID大致等于被索引文檔的次序，但是，由于索引變化時(shí)ID值會(huì)隨之變化，所以不依賴(lài)此ID進(jìn)行排序。

文檔

提交給Solr處理的每一分?jǐn)?shù)據(jù)都是一個(gè)文檔。

倒排索引

不是由記錄來(lái)確定屬性值，而是由屬性值來(lái)確定記錄的位置 1. 倒排索引仲的所有詞項(xiàng)對(duì)應(yīng)一個(gè)或多個(gè)文檔 2. 倒排索引仲的詞項(xiàng)根據(jù)字典順序升序排序

邏輯運(yùn)算符

AND、+ (與)

OR、空格(或)

-、NOT(排除)

詞項(xiàng)位置

搜索詞的順序?qū)⑹筍olr按照詞序搜索

| 詞項(xiàng) | 文檔位置 | 詞項(xiàng)位置 | | ---- | -------- | -------- | | a | 1 | 1 | | | | 3 | | | | 4 |

好處：詞序位置允許在各自的文檔中重新構(gòu)造索引詞項(xiàng)的初始位置，使其在查詢(xún)階段可以搜索特定的短語(yǔ)。

模糊匹配

通配符搜素
*

區(qū)間搜索
使用方括號(hào)。 [18 TO 21] 匹配18、19、20、21 3. 編輯距離搜索
使用~符號(hào)表示模糊編輯距離搜索。
administrator~N 匹配N(xiāo)個(gè)以?xún)?nèi)的距離編輯。 4. 鄰近搜索
要求全部特定詞項(xiàng)出現(xiàn)。 "chief office"~N 兩個(gè)單詞之間最多相隔N個(gè)詞

相關(guān)度

默認(rèn)相關(guān)度

基于Similarity類(lèi)
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-UuqJnT8p-1577758320444)(https://s2.ax1x.com/2019/12/30/lKbtOK.png)]
默認(rèn)下使用Lucene相應(yīng)的DefaultSimilarity類(lèi)。這個(gè)類(lèi)使用兩段式檢索模型來(lái)計(jì)算相似度。

首先用布爾模型過(guò)濾出不符合用戶(hù)查詢(xún)的所有文檔。然后在使用向量空間模型計(jì)算和繪制將查詢(xún)和文檔轉(zhuǎn)換為向量，在此基礎(chǔ)上計(jì)算相似得分。每個(gè)文檔的相似得分基于查詢(xún)向量與文檔向量的夾角余弦值。余弦值為1表示完美匹配，余弦值為0表示無(wú)相似性。

1. 詞項(xiàng)頻次

特定詞項(xiàng)在待匹配文檔中出現(xiàn)的次數(shù)，表示了文檔與該詞項(xiàng)的匹配程度。出現(xiàn)次數(shù)越多，則被認(rèn)為該文檔與特定主題(查詢(xún)?cè)~項(xiàng))更相關(guān)。

2. 反向文檔頻次

反向文檔頻次是查詢(xún)?cè)~項(xiàng)罕見(jiàn)程度的度量，根據(jù)文檔頻次（含有該查詢(xún)?cè)~項(xiàng)的總文檔數(shù)）計(jì)算它的逆。

詞頻頻次“獎(jiǎng)勵(lì)”了在一個(gè)文檔中出現(xiàn)多次的詞項(xiàng)，二反向文檔頻次“懲罰”了再多個(gè)文檔中普遍出現(xiàn)的詞項(xiàng)。

詞項(xiàng)權(quán)重

可以在索引階段或查詢(xún)階段相應(yīng)調(diào)整某些字段或詞項(xiàng)的權(quán)重。

規(guī)范化因子

1. 字段規(guī)范

字段規(guī)范（field norm）因子是以每個(gè)文檔為基礎(chǔ)的特定字段重要性的因子組合。字段規(guī)范的索引創(chuàng)建時(shí)計(jì)算，其表示Solr索引中每個(gè)字段的一個(gè)附加字節(jié)。
該字節(jié)包含：文檔被索引時(shí)的權(quán)重集、字段被索引時(shí)額權(quán)重集、懲罰長(zhǎng)文檔的同時(shí)提升短文檔的長(zhǎng)度歸一化因子（前提是給定關(guān)鍵詞在長(zhǎng)文檔中出現(xiàn)的可能性更大，因此相關(guān)性較低）。
字段規(guī)范由匹配文檔的權(quán)重、匹配字段的權(quán)重及懲罰長(zhǎng)文檔的長(zhǎng)度歸一化因子組成。這三個(gè)完全獨(dú)立的數(shù)據(jù)以單個(gè)字節(jié)存儲(chǔ)在Solr索引中，這是組合為一個(gè)字段規(guī)范變量的唯一依據(jù)。

長(zhǎng)度歸一

目的是調(diào)整不同長(zhǎng)度的文檔。通常，特定詞項(xiàng)在長(zhǎng)文檔中出現(xiàn)次數(shù)可能比較多，通過(guò)歸一化可以消除較長(zhǎng)文檔的這一優(yōu)勢(shì)。

2. 查詢(xún)規(guī)范

queryNorm在Solr默認(rèn)相關(guān)度計(jì)算中較少被關(guān)注，因?yàn)橥粋€(gè)查詢(xún)規(guī)范應(yīng)用于所有文檔，因此它不影響總體的相關(guān)度排序，它僅用于查詢(xún)之間進(jìn)行比較時(shí)得分計(jì)算的規(guī)范化因子。該因子是每個(gè)查詢(xún)?cè)~項(xiàng)的權(quán)重平方之和，再將它與相關(guān)度得分的其余部分進(jìn)行相乘，從而實(shí)現(xiàn)規(guī)范化。

3. 協(xié)調(diào)因子

衡量每個(gè)文檔匹配的查詢(xún)數(shù)量。所有事物都是平等的，包含很多查詢(xún)?cè)~項(xiàng)的文檔應(yīng)該比只包含幾個(gè)查詢(xún)?cè)~項(xiàng)的其他文檔得分高。

查準(zhǔn)率與查全率

查準(zhǔn)率

衡量返回結(jié)果的整體精準(zhǔn)性。
正確匹配的文檔數(shù)量/返回的文檔數(shù)量

查全率

衡量搜索結(jié)果的全面性。
正確匹配的文檔數(shù)量/(正確匹配的文檔數(shù)+錯(cuò)誤匹配的文檔數(shù))

平衡查準(zhǔn)率和查全率

常見(jiàn)方式：

在整個(gè)結(jié)果集上計(jì)算查全率，僅在搜索結(jié)果第一頁(yè)（或少數(shù)頁(yè)）上計(jì)算查準(zhǔn)率。根據(jù)這一模型，調(diào)節(jié)Solr的相關(guān)度評(píng)分的計(jì)算方法，讓更好的匹配結(jié)果被提升到搜索結(jié)果的頂部，而許多不良的匹配出現(xiàn)在搜索結(jié)果的底部。

搜索的規(guī)?；?/h3>

非規(guī)范化文檔

Solr的核心概念是所有文檔去規(guī)范化。
非規(guī)范化文檔指文檔中的所有字段是自包含的，允許這些字段的值在多個(gè)文檔中重復(fù)出現(xiàn)。

分布式搜索

集群總查詢(xún)速度理論公式
(N+1個(gè)索引的查詢(xún)速度)=結(jié)果聚合的開(kāi)銷(xiāo)+(N個(gè)索引的查詢(xún)速度)/(N+1)

Solr局限性

Solr在文檔處理上不以任何方式構(gòu)成關(guān)系。它不適用于在不同文檔的不同字段上連接大量數(shù)據(jù)，也無(wú)法在多臺(tái)服務(wù)器上執(zhí)行join操作。

數(shù)據(jù)是冗余的，每個(gè)文檔中相同的數(shù)據(jù)會(huì)重復(fù)出現(xiàn)。

它主要用作文檔存儲(chǔ)方案。不能對(duì)字段進(jìn)行輕松操作。當(dāng)前Solr對(duì)單個(gè)字段僅能做一些簡(jiǎn)單的處理，而且前提是字段的原始值存儲(chǔ)在索引中。Solr基于內(nèi)部存儲(chǔ)字段，通過(guò)重做索引來(lái)更新這個(gè)文檔，這就意味著，每當(dāng)新的字段添加到Solr或者已有字段的內(nèi)容發(fā)聲變化時(shí)，Solr索引的每個(gè)文檔必須在所有文檔的新數(shù)據(jù)填充數(shù)據(jù)之前重新處理。

SOlr不適用于處理非常長(zhǎng)的查詢(xún)（包含上千個(gè)搜索詞的查詢(xún)）或給用戶(hù)返回大量搜索結(jié)果集。

配置Solr

三個(gè)常用xml文件

solr.xml————定義管理、日志、分片和SolrCloud的有關(guān)屬性

solrconfig.xml————定義solr內(nèi)核的主要配置

schema.xml————定義索引結(jié)構(gòu)，包括字段及其數(shù)據(jù)類(lèi)型

定位配置文件方式

Solr通過(guò)掃描core.properties定位內(nèi)核，并利用solrconfig.xml來(lái)初始化內(nèi)核。

solrconfig.xml中常見(jiàn)的數(shù)據(jù)類(lèi)型元素

|元素|說(shuō)明|舉例| |-|-|-| ||命名的對(duì)象有序數(shù)組|
spellcheck
||命名的鍵值對(duì)有序列表|
true
json
||布爾值 true 或 false| ||字符串值| ||整數(shù)| ||長(zhǎng)整數(shù)| ||單精度浮點(diǎn)值| ||雙精度浮點(diǎn)值|

<arr> 和 <lst>之間的最大不同是<lst>中的每個(gè)子元素都有一個(gè) name 屬性，而 的子元素則沒(méi)有。

重啟核心

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-ailI3u3T-1577758320446)(https://s2.ax1x.com/2019/12/30/lMxPLn.png)]

查詢(xún)請(qǐng)求處理

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-vPBJmTjP-1577758320447)(https://s2.ax1x.com/2019/12/30/lMz0c4.png)]

搜索處理器

Solr 中有兩類(lèi)主要的請(qǐng)求處理器
1. 處理查詢(xún)請(qǐng)求的搜索處理器 2. 處理索引請(qǐng)求的更新處理器

通常情況下，一個(gè)搜索處理器由以下組件組成，其中每個(gè)組件都定義在 solrconfig.xml 文件中。 [外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-qWjWIiAE-1577758320448)(https://s2.ax1x.com/2019/12/30/lQ90gS.png)] 1. 請(qǐng)求參數(shù)修飾組件，包括：
a. 默認(rèn)值修飾 (defaults) —— 為客戶(hù)端未指定值的參數(shù)添加默認(rèn)值。
b. 常量修飾 (invariants) —— 將客戶(hù)端的參數(shù)值覆寫(xiě)為固定值。
c. 后綴修飾 (appends) —— 在客戶(hù)端請(qǐng)求的末尾添加額外參數(shù)。
2. 預(yù)處理組件 (first-components) —— 一組優(yōu)先執(zhí)行的可選搜索組件， 執(zhí)行預(yù)處理任務(wù)。 3. 主搜索組件(components) —— 一組鏈?zhǔn)浇M合的搜索組件,至少包含查詢(xún)組件。 4. 后處理組件 (lastcomponents) —— 一組可選的鏈?zhǔn)浇M合的搜索組件，執(zhí)行后處理任務(wù)。

利用搜索組件擴(kuò)展查詢(xún)處理

1. 查詢(xún)組件

查詢(xún)組件在索引中找出所有符合條件的文檔，形成結(jié)果文檔集。

2. 分頁(yè)組件

分頁(yè)組件將根據(jù)字段分面進(jìn)行結(jié)果統(tǒng)計(jì)與過(guò)濾。

3. 更多類(lèi)似結(jié)果組件

當(dāng)給定一組由查詢(xún)組件生成的結(jié)果文檔集時(shí)，如果更多類(lèi)似結(jié)果組件被啟用了，它將識(shí)別出與搜索結(jié)果集中的文檔相似的其他文檔。

4. 高亮組件

如果高亮組件被啟用了，它將對(duì)結(jié)果文檔中與查詢(xún)語(yǔ)句高度相關(guān)的文檔內(nèi)容進(jìn)行高亮表示。

5. 統(tǒng)計(jì)組件

統(tǒng)計(jì)組件可 以為結(jié)果文檔中的數(shù)值字段計(jì)算最小值、最大值、總和、平均值和標(biāo)準(zhǔn)差等簡(jiǎn)單的統(tǒng)計(jì)指標(biāo)。

6. 調(diào)試組件

調(diào)試組件會(huì)返回執(zhí)行過(guò)的查詢(xún)語(yǔ)句解析后的結(jié)果，以及結(jié)果文檔集中每個(gè)文檔相關(guān)度分?jǐn)?shù)計(jì)算的詳細(xì)信息。

http://localhost:8983/solr/ collection1/browse?q=iPod&wt=xml&debugQuery=true

拼寫(xiě)檢查

<last-component>

管理搜索器

在Solr中，任何時(shí)候只能存在一個(gè)“處于活躍狀態(tài)的”搜索器。

新添加的文檔如何才能出現(xiàn)在搜索結(jié)果中？

關(guān)閉當(dāng)前的搜索器，打開(kāi)一個(gè)新的搜索器，這個(gè)搜索器添加了索引更新以后的只讀視圖。

新搜索器預(yù)熱

利用舊緩存自動(dòng)預(yù)熱新緩存

緩存預(yù)熱查詢(xún)就是向搜索器提交一段預(yù)先在solrconfig.xml文件中配置好的查詢(xún)語(yǔ)句，目的是讓新搜索器將需要緩存的査詢(xún)結(jié)果載入它的緩存中。預(yù)熱查詢(xún)語(yǔ)句應(yīng)當(dāng)包含應(yīng)用程序中使用最頻繁的查詢(xún)請(qǐng)求參數(shù)（q、fq、sort等）。

<useColdSearcher>

適用于一個(gè)搜索請(qǐng)求己經(jīng)被提交，而目前 Solr 中沒(méi)有定義搜索器的情形。如果 的值為 false, 那么 Solr 將會(huì)一直處于阻塞狀態(tài)，直到正在預(yù)熱 的搜索器執(zhí)行完所有的預(yù)熱查詢(xún)。

<maxWarmingSearchers>

<maxWarmingSearchers>元素允許開(kāi)發(fā)者控制后臺(tái)并發(fā)預(yù)熱的搜索器的最大數(shù)目。一旦達(dá)到閾值，新的提交請(qǐng)求將會(huì)失敗。該元素的默認(rèn)值為2。

緩存管理

1. 緩存大小及緩存置換法

為了控制緩存大小，Solr 要求為每一個(gè)緩存都設(shè)置一個(gè)緩存對(duì)象的數(shù)量上限。當(dāng)達(dá)到上限時(shí),Solr將采用最久未使用(Least Recently Used, LRU) 置換法或最近最少使用(Least Frequently Used, LFU) 置換法回收一部分緩存空間。

2. 緩存命中率與緩存回收

緩存命中率 是指應(yīng)用程序的緩存命中的用戶(hù)請(qǐng)求數(shù)量占所有用戶(hù)請(qǐng)求數(shù)量的比例。
緩存回收數(shù) 表明有多少緩存對(duì)象根據(jù)上文介紹的緩存置換法被回收了。

緩存回收數(shù)和緩存命中率是緊密相關(guān)的，高的緩存回收數(shù)往往導(dǎo)致一個(gè)較好的緩存命中率。

3. 緩存對(duì)象失效

搜索器只是Lucene索引快照的一個(gè)只讀視圖,所有緩存中的對(duì)象都會(huì)鏈接到對(duì)應(yīng)的搜索器實(shí)例，并且在搜索器關(guān)閉后立即失效。

4. 自動(dòng)預(yù)熱新的緩存

自動(dòng)預(yù)熱 Solr利用即將被關(guān)閉的舊搜索器中的部分緩存內(nèi)容構(gòu)建新搜索器的緩存。
<autowarmCount>表示自動(dòng)預(yù)熱的舊緩存對(duì)象的最大數(shù)目或百分比。

緩存類(lèi)型

1. 過(guò)濾器緩存

假設(shè)有一個(gè)過(guò)濾條件相同(fq=manu:Belkin)但查詢(xún)內(nèi)容不同的查詢(xún)請(qǐng)求，例如q=USB，如果應(yīng)用程序在處理該查詢(xún)請(qǐng)求時(shí)可以相同過(guò)濾條件的查詢(xún)結(jié)果，那么查詢(xún)效率會(huì)得到大幅提高。

2. 自動(dòng)預(yù)熱過(guò)濾器緩存

預(yù)熱新的緩存時(shí)，一部分鍵從舊的緩存中抽取出來(lái)，向新搜索器提交查詢(xún)，形成新的過(guò)濾器。要利用新搜索器自動(dòng)預(yù)熱過(guò)濾器緩存，就需要Solr重新執(zhí)行過(guò)濾査詢(xún)。因此，自動(dòng)預(yù)熱過(guò)濾器緩存可能導(dǎo)致Solr在性能和資源利用方面出現(xiàn)問(wèn)題。

建議開(kāi)發(fā)者為過(guò)濾器緩存啟用自動(dòng)預(yù)熱功能，但是給<autowarmCount>設(shè)一個(gè)較小值作為初始值。除此之外，LFU置換法更適合過(guò)濾器緩存，因?yàn)樗鼙ＷC被請(qǐng)求頻率高的過(guò)濾器被賦予較高優(yōu)先級(jí)，同時(shí)降低過(guò)濾器緩存的大小。
下面是推薦的過(guò)濾器緩存配置：

<filterCache class="solr.LFUCache" size="100" initialSize="20" autowarmCount="10"/>

查詢(xún)結(jié)果緩存

原理是將査詢(xún)語(yǔ)句作為鍵，內(nèi)部Lucene文檔ID作為值，存儲(chǔ)在查詢(xún)結(jié)果緩存中。內(nèi)部Lucene文檔ID會(huì)隨著搜索器的改變而改變，所以在預(yù)熱查詢(xún)結(jié)果緩存時(shí)，緩存的內(nèi)部Lucene文檔ID需要重新計(jì)算。

建議將<autowarmCount>的值設(shè)為一個(gè)較小值。

查詢(xún)結(jié)果窗口大小

<queryResultWindowSize>允許在執(zhí)行查詢(xún)請(qǐng)求時(shí)定義單次返回查詢(xún)結(jié)果的頁(yè)數(shù)。
一般情況下，我們會(huì)將這個(gè)元素的值設(shè) 為每頁(yè)查詢(xún)結(jié)果數(shù)量的兩到三倍。

查詢(xún)結(jié)果緩存的最大文檔數(shù)

<queryResultMaxDocsCached>元素允許對(duì)查詢(xún)結(jié)果緩存中每個(gè)緩存對(duì)象包含的文檔數(shù)目做出限制。在大多數(shù)搜索應(yīng)用 中，用戶(hù)一般僅査看前幾頁(yè)的搜索結(jié)果，所以可以將這個(gè)值設(shè)為每頁(yè)結(jié)果文檔數(shù)目的兩倍或三倍大小。

啟用字段延遲加載

將<enableLazyFieldLoading>元素的值設(shè)為 true, 這樣可以避免加載用戶(hù)不需要的字段。

文檔緩存

文檔緩存 以文檔的內(nèi)部 ID為鍵，將硬盤(pán)中的文檔內(nèi)容加載到緩存中。這樣，查詢(xún)結(jié)果緩存可以從文檔緩存中調(diào)用需要的文檔內(nèi)容。
如果更新索引的頻率很高，每個(gè)査詢(xún)返回的結(jié)果文檔也在經(jīng)常變化，則配置文檔緩存就可能把資源耗費(fèi)在了對(duì)應(yīng)用程序性能無(wú)益的地方。但另一方面，如果索引更新頻率很低，那么文檔緩存可能有助于提高應(yīng)用程序的性能。

字段值緩存

字段值緩存提供了通過(guò)內(nèi)部文檔 ID 快速訪(fǎng)問(wèn)存儲(chǔ)的字段值的途徑，主要在排序和從匹配文檔中生成響應(yīng)內(nèi)容時(shí)使用。

總結(jié)

以上是生活随笔為你收集整理的solr 查询字段唯一值_《Solr实战》之一的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。