本文記錄筆者在閱讀《Solr實戰》的讀書筆記，將筆者認為重要的內容摘錄出來。

Solr擅長處理的數據類型

以文本為中心

讀主導 文檔被讀取的次數遠大于被創建和更新的次數

面向文檔

靈活的模式

大量的數據

底層使用Lucene

導入示例數據到已有core

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

排名檢索

根據score字段在內部相對排名
返回的搜索結果按照得分由高到低排序，文檔的分越高，說明與該查詢越相關。

分頁

默認的頁面調整頁面大小為10，調整start參數(start=0 第一頁)，因為底層的Lucene索引并未對一睇返回大量文檔做成優化設計，所以盡可能使用小頁面非常重要。相反，Lucene優化了查詢處理，底層的數據結構設計用于最大限度滿足文檔匹配和評分。

排序

搜索結果根據相關度得分將文檔按降序排列，還可以根據文檔的其他字段進行排序。文檔得分相同時，他們以索引的次序返回，該次序基于Lucene的內部文檔ID。這個文檔ID大致等于被索引文檔的次序，但是，由于索引變化時ID值會隨之變化，所以不依賴此ID進行排序。

文檔

提交給Solr處理的每一分數據都是一個文檔。

倒排索引

不是由記錄來確定屬性值，而是由屬性值來確定記錄的位置 1. 倒排索引仲的所有詞項對應一個或多個文檔 2. 倒排索引仲的詞項根據字典順序升序排序

邏輯運算符

AND、+ (與)

OR、空格(或)

-、NOT(排除)

詞項位置

搜索詞的順序將使Solr按照詞序搜索

| 詞項 | 文檔位置 | 詞項位置 | | ---- | -------- | -------- | | a | 1 | 1 | | | | 3 | | | | 4 |

好處：詞序位置允許在各自的文檔中重新構造索引詞項的初始位置，使其在查詢階段可以搜索特定的短語。

模糊匹配

通配符搜素
*

區間搜索
使用方括號。 [18 TO 21] 匹配18、19、20、21 3. 編輯距離搜索
使用~符號表示模糊編輯距離搜索。
administrator~N 匹配N個以內的距離編輯。 4. 鄰近搜索
要求全部特定詞項出現。 "chief office"~N 兩個單詞之間最多相隔N個詞

相關度

默認相關度

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

首先用布爾模型過濾出不符合用戶查詢的所有文檔。然后在使用向量空間模型計算和繪制將查詢和文檔轉換為向量，在此基礎上計算相似得分。每個文檔的相似得分基于查詢向量與文檔向量的夾角余弦值。余弦值為1表示完美匹配，余弦值為0表示無相似性。

1. 詞項頻次

特定詞項在待匹配文檔中出現的次數，表示了文檔與該詞項的匹配程度。出現次數越多，則被認為該文檔與特定主題(查詢詞項)更相關。

2. 反向文檔頻次

反向文檔頻次是查詢詞項罕見程度的度量，根據文檔頻次（含有該查詢詞項的總文檔數）計算它的逆。

詞頻頻次“獎勵”了在一個文檔中出現多次的詞項，二反向文檔頻次“懲罰”了再多個文檔中普遍出現的詞項。

詞項權重

可以在索引階段或查詢階段相應調整某些字段或詞項的權重。

規范化因子

1. 字段規范

字段規范（field norm）因子是以每個文檔為基礎的特定字段重要性的因子組合。字段規范的索引創建時計算，其表示Solr索引中每個字段的一個附加字節。
該字節包含：文檔被索引時的權重集、字段被索引時額權重集、懲罰長文檔的同時提升短文檔的長度歸一化因子（前提是給定關鍵詞在長文檔中出現的可能性更大，因此相關性較低）。
字段規范由匹配文檔的權重、匹配字段的權重及懲罰長文檔的長度歸一化因子組成。這三個完全獨立的數據以單個字節存儲在Solr索引中，這是組合為一個字段規范變量的唯一依據。

長度歸一

目的是調整不同長度的文檔。通常，特定詞項在長文檔中出現次數可能比較多，通過歸一化可以消除較長文檔的這一優勢。

2. 查詢規范

queryNorm在Solr默認相關度計算中較少被關注，因為同一個查詢規范應用于所有文檔，因此它不影響總體的相關度排序，它僅用于查詢之間進行比較時得分計算的規范化因子。該因子是每個查詢詞項的權重平方之和，再將它與相關度得分的其余部分進行相乘，從而實現規范化。

3. 協調因子

衡量每個文檔匹配的查詢數量。所有事物都是平等的，包含很多查詢詞項的文檔應該比只包含幾個查詢詞項的其他文檔得分高。

查準率與查全率

查準率

衡量返回結果的整體精準性。
正確匹配的文檔數量/返回的文檔數量

查全率

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

平衡查準率和查全率

常見方式：

在整個結果集上計算查全率，僅在搜索結果第一頁（或少數頁）上計算查準率。根據這一模型，調節Solr的相關度評分的計算方法，讓更好的匹配結果被提升到搜索結果的頂部，而許多不良的匹配出現在搜索結果的底部。

搜索的規模化

非規范化文檔

Solr的核心概念是所有文檔去規范化。
非規范化文檔指文檔中的所有字段是自包含的，允許這些字段的值在多個文檔中重復出現。

分布式搜索

集群總查詢速度理論公式
(N+1個索引的查詢速度)=結果聚合的開銷+(N個索引的查詢速度)/(N+1)

Solr局限性

Solr在文檔處理上不以任何方式構成關系。它不適用于在不同文檔的不同字段上連接大量數據，也無法在多臺服務器上執行join操作。

數據是冗余的，每個文檔中相同的數據會重復出現。

它主要用作文檔存儲方案。不能對字段進行輕松操作。當前Solr對單個字段僅能做一些簡單的處理，而且前提是字段的原始值存儲在索引中。Solr基于內部存儲字段，通過重做索引來更新這個文檔，這就意味著，每當新的字段添加到Solr或者已有字段的內容發聲變化時，Solr索引的每個文檔必須在所有文檔的新數據填充數據之前重新處理。

SOlr不適用于處理非常長的查詢（包含上千個搜索詞的查詢）或給用戶返回大量搜索結果集。

配置Solr

三個常用xml文件

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

solrconfig.xml————定義solr內核的主要配置

schema.xml————定義索引結構，包括字段及其數據類型

定位配置文件方式

Solr通過掃描core.properties定位內核，并利用solrconfig.xml來初始化內核。

solrconfig.xml中常見的數據類型元素

|元素|說明|舉例| |-|-|-| ||命名的對象有序數組|
spellcheck
||命名的鍵值對有序列表|
true
json
||布爾值 true 或 false| ||字符串值| ||整數| ||長整數| ||單精度浮點值| ||雙精度浮點值|

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

重啟核心

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

查詢請求處理

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

搜索處理器

Solr 中有兩類主要的請求處理器
1. 處理查詢請求的搜索處理器 2. 處理索引請求的更新處理器

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

利用搜索組件擴展查詢處理

1. 查詢組件

查詢組件在索引中找出所有符合條件的文檔，形成結果文檔集。

2. 分頁組件

分頁組件將根據字段分面進行結果統計與過濾。

3. 更多類似結果組件

當給定一組由查詢組件生成的結果文檔集時，如果更多類似結果組件被啟用了，它將識別出與搜索結果集中的文檔相似的其他文檔。

4. 高亮組件

如果高亮組件被啟用了，它將對結果文檔中與查詢語句高度相關的文檔內容進行高亮表示。

5. 統計組件

統計組件可 以為結果文檔中的數值字段計算最小值、最大值、總和、平均值和標準差等簡單的統計指標。

6. 調試組件

調試組件會返回執行過的查詢語句解析后的結果，以及結果文檔集中每個文檔相關度分數計算的詳細信息。

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

拼寫檢查

<last-component>

管理搜索器

在Solr中，任何時候只能存在一個“處于活躍狀態的”搜索器。

新添加的文檔如何才能出現在搜索結果中？

關閉當前的搜索器，打開一個新的搜索器，這個搜索器添加了索引更新以后的只讀視圖。

新搜索器預熱

利用舊緩存自動預熱新緩存

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

<useColdSearcher>

適用于一個搜索請求己經被提交，而目前 Solr 中沒有定義搜索器的情形。如果 的值為 false, 那么 Solr 將會一直處于阻塞狀態，直到正在預熱 的搜索器執行完所有的預熱查詢。

<maxWarmingSearchers>

<maxWarmingSearchers>元素允許開發者控制后臺并發預熱的搜索器的最大數目。一旦達到閾值，新的提交請求將會失敗。該元素的默認值為2。

緩存管理

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

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

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

緩存命中率 是指應用程序的緩存命中的用戶請求數量占所有用戶請求數量的比例。
緩存回收數 表明有多少緩存對象根據上文介紹的緩存置換法被回收了。

緩存回收數和緩存命中率是緊密相關的，高的緩存回收數往往導致一個較好的緩存命中率。

3. 緩存對象失效

搜索器只是Lucene索引快照的一個只讀視圖,所有緩存中的對象都會鏈接到對應的搜索器實例，并且在搜索器關閉后立即失效。

4. 自動預熱新的緩存

自動預熱 Solr利用即將被關閉的舊搜索器中的部分緩存內容構建新搜索器的緩存。
<autowarmCount>表示自動預熱的舊緩存對象的最大數目或百分比。

緩存類型

1. 過濾器緩存

假設有一個過濾條件相同(fq=manu:Belkin)但查詢內容不同的查詢請求，例如q=USB，如果應用程序在處理該查詢請求時可以相同過濾條件的查詢結果，那么查詢效率會得到大幅提高。

2. 自動預熱過濾器緩存

預熱新的緩存時，一部分鍵從舊的緩存中抽取出來，向新搜索器提交查詢，形成新的過濾器。要利用新搜索器自動預熱過濾器緩存，就需要Solr重新執行過濾査詢。因此，自動預熱過濾器緩存可能導致Solr在性能和資源利用方面出現問題。

建議開發者為過濾器緩存啟用自動預熱功能，但是給<autowarmCount>設一個較小值作為初始值。除此之外，LFU置換法更適合過濾器緩存，因為它能保證被請求頻率高的過濾器被賦予較高優先級，同時降低過濾器緩存的大小。
下面是推薦的過濾器緩存配置：

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

查詢結果緩存

原理是將査詢語句作為鍵，內部Lucene文檔ID作為值，存儲在查詢結果緩存中。內部Lucene文檔ID會隨著搜索器的改變而改變，所以在預熱查詢結果緩存時，緩存的內部Lucene文檔ID需要重新計算。

建議將<autowarmCount>的值設為一個較小值。

查詢結果窗口大小

<queryResultWindowSize>允許在執行查詢請求時定義單次返回查詢結果的頁數。
一般情況下，我們會將這個元素的值設 為每頁查詢結果數量的兩到三倍。

查詢結果緩存的最大文檔數

<queryResultMaxDocsCached>元素允許對查詢結果緩存中每個緩存對象包含的文檔數目做出限制。在大多數搜索應用 中，用戶一般僅査看前幾頁的搜索結果，所以可以將這個值設為每頁結果文檔數目的兩倍或三倍大小。

啟用字段延遲加載

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

文檔緩存

文檔緩存 以文檔的內部 ID為鍵，將硬盤中的文檔內容加載到緩存中。這樣，查詢結果緩存可以從文檔緩存中調用需要的文檔內容。
如果更新索引的頻率很高，每個査詢返回的結果文檔也在經常變化，則配置文檔緩存就可能把資源耗費在了對應用程序性能無益的地方。但另一方面，如果索引更新頻率很低，那么文檔緩存可能有助于提高應用程序的性能。

字段值緩存

字段值緩存提供了通過內部文檔 ID 快速訪問存儲的字段值的途徑，主要在排序和從匹配文檔中生成響應內容時使用。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。