Solr 建索引的速度一直不太令人滿意,自己根據(jù)網(wǎng)上的一些資料的翻譯和自己的體會(huì)總結(jié)這篇文章。
1.關(guān)于內(nèi)存
1.1 堆外內(nèi)存重要性
內(nèi)存對(duì)Solr來說非常重要,主要是利用Java堆外內(nèi)存保存索引文件。
Solr默認(rèn)利用MMapDirectory來加載索引文件到磁盤緩存,然后把它映射到Solr的進(jìn)程虛擬內(nèi)存。所以再次強(qiáng)調(diào)下,Java的堆外內(nèi)存對(duì)Solr很重要。
Solr需要內(nèi)存保存不同的東西:
1、Java堆內(nèi)存。
2、那些“空閑”的為磁盤做緩存的內(nèi)存。
索引的更新,Solr依賴快速的批量的隨機(jī)讀寫,對(duì)查詢來說,快速的隨機(jī)讀寫是不可缺少的,所以保存大容量的磁盤緩存是重要的。當(dāng)然Solr的索引如果可以保存在SSD盤上,對(duì)性能提高有很大幫助。
1.2 多大堆內(nèi)存更合適
多大的堆內(nèi)存對(duì)Solr來說合適那,其實(shí)沒有統(tǒng)一的標(biāo)準(zhǔn),可以通過查看Solr的GC日志來進(jìn)行合適設(shè)置,比如可以首次設(shè)置為2G,如果設(shè)置的內(nèi)存過大,將增大GC的時(shí)間,所以這個(gè)必須實(shí)踐來調(diào)整。
2.關(guān)于Schema
Schema設(shè)計(jì)對(duì)Solr來說非常重要,主要涉及幾個(gè)方面。
2.1 Indexed字段
Indexed的字段會(huì)在幾個(gè)方面產(chǎn)生影響
1、索引時(shí)候內(nèi)存的使用。
2、段合并時(shí)間。
3、優(yōu)化索引時(shí)間。
4、索引的大小。
可以通過 omitNorms="true" 減少點(diǎn)這些影響。
2.2 Stored字段
搜索查詢結(jié)果中的存儲(chǔ)字段會(huì)是個(gè)重大的費(fèi)用, 這個(gè)成本主要受到每個(gè)文檔存儲(chǔ)的字節(jié)數(shù)的影響 - 更高的字節(jié)計(jì)數(shù),文檔將分散在磁盤上的稀疏,更多的I / O檢索字段(通常這是在存儲(chǔ)大字段 ,像文檔的整個(gè)內(nèi)容)。
考慮在solr之外存儲(chǔ)大 字段,如果你傾向于這么做,可以考慮壓縮字段,這增加了存儲(chǔ)和檢索字段的CPU成本,但降低了I / O負(fù)擔(dān)和CPU使用率。
如果你不總是使用所有存儲(chǔ)的字段,那么啟用延遲字段加載可能是一個(gè)巨大的福音,特別是如果使用壓縮字段。
3.配置注意事項(xiàng)
mergeFactor
mergeFactor粗略地確定段的數(shù)量。mergeFactor值告訴Lucene在將它們合并到單個(gè)段之前要構(gòu)建多少相等大小的段。 它可以被認(rèn)為是數(shù)字系統(tǒng)的基礎(chǔ)。
例如,如果將mergeFactor設(shè)置為10,則將為添加到索引的每1000(或maxBufferedDocs)個(gè)文檔在磁盤上創(chuàng)建一個(gè)新段。 當(dāng)添加大小為1000的第10個(gè)分段時(shí),所有10個(gè)分段將合并為大小為10,000的單個(gè)分段。 當(dāng)添加了10個(gè)大小為10,000的這樣的段時(shí),它們將被合并成包含100,000個(gè)文檔的單個(gè)段,等等。 因此,在任何時(shí)候,在每個(gè)索引大小中將不超過9個(gè)段。
這些值在solrConfig.xml中的主索引部分設(shè)置。
mergeFactor 設(shè)置取舍
高的mergeFactor值(比如25):
Pro:通常提高索引速度。
Con:較不頻繁的合并,導(dǎo)致收集更多的索引文件,可能會(huì)減慢搜索。
低的mergeFactor值(比如2):
Pro:索引文件數(shù)量較少,加快了搜索速度。
Can:更多的段合并減慢索引。
HashDocSet設(shè)置建議
hashDocSet是在solrconfig.xml中指定的優(yōu)化,它在集合中的項(xiàng)數(shù)小于maxSize時(shí)啟用過濾器(docSets)的int哈希表示。 對(duì)于較小的集合,此表示更高的內(nèi)存效率,更高效的迭代,以及更快的交叉。(不懂??)
hashDocSet最大大小應(yīng)基于集合中文檔數(shù)量的主要原因 - 文檔數(shù)量越大,hashDocSet最大大小越大。 您將必須做一些嘗試和錯(cuò)誤,以達(dá)到最佳的數(shù)字:
1.計(jì)算要存儲(chǔ)總量的*0.005
2.嘗試在該值的任一“側(cè)”的值以達(dá)到最佳查詢時(shí)間。
3.當(dāng)查詢時(shí)間似乎處于高位時(shí),性能在較高的數(shù)字和較低的數(shù)之間沒有顯示出很大的差別,使用較高的數(shù)字。
autoWarm緩存數(shù)量設(shè)置
當(dāng)新的搜索器被打開時(shí),其高速緩存可以利用來自舊搜索器中的高速緩存的高速緩存的對(duì)象來預(yù)填充或“自動(dòng)加熱”。 autowarmCount是將被復(fù)制到新搜索器的緩存項(xiàng)目的數(shù)量。 您可能希望將autowarmCount設(shè)置為自動(dòng)喚醒所需的時(shí)間。 你必須考慮權(quán)衡 - 時(shí)間自動(dòng)喚醒與你想要緩存的熱度(即autowarmCount)。 solrconfig.xml中的緩存設(shè)置了autowarm參數(shù)。
緩存命中率
監(jiān)視Solr的管理員的緩存統(tǒng)計(jì)信息! 提高Solr的緩存大小通常是提高性能的最佳方法,尤其是如果您注意到特定緩存類型的許多逐出。 要特別注意filterCache,這也是Solr內(nèi)部使用的facetting。 另請參閱SolrCaching和此常見問題條目。
排序字段的顯式加溫
如果您進(jìn)行大量基于字段的排序,則有利的是向solrconfig中的“newSearcher”和“firstSearcher”事件偵聽器添加顯式加溫查詢,對(duì)這些字段排序,因此在執(zhí)行任何查詢之前填充FieldCache 您的用戶。
4.優(yōu)化注意事項(xiàng)
您可能想在某些情況下優(yōu)化索引 - 即:如果您構(gòu)建索引一次,然后從不修改它。
如果你有一個(gè)快速變化的索引,而不是優(yōu)化,你可能只是想使用一個(gè)較低的合并因子。 優(yōu)化是非常昂貴的,如果指數(shù)不斷變化,輕微的性能提升不會(huì)持續(xù)很長時(shí)間。 這種折衷通常不值得為非靜態(tài)索引。
在主從設(shè)置中,有時(shí)您可能還想在主設(shè)備上進(jìn)行優(yōu)化,以便從單個(gè)段索引服務(wù)。 這將大大增加復(fù)制索引的時(shí)間,所以這通常是不可取的。
更新和提交頻率折衷
如果從服務(wù)器太頻繁地收到新集合,他們的表現(xiàn)將受到影響。 為了避免這種類型的退化,你必須了解從屬如何收到集合更新,以便你可以知道如何最好地調(diào)整相關(guān)的參數(shù)(提交,snappullers和自動(dòng)溫度/自動(dòng)計(jì)數(shù)的數(shù)量/頻率),使新的集合不 從服務(wù)器上安裝太頻繁。
1.每次客戶端運(yùn)行提交時(shí)都會(huì)收集集合的快照,或者根據(jù)在主服務(wù)器上是否使用postCommit或post Optimize掛鉤來運(yùn)行優(yōu)化。
2.在克隆的基礎(chǔ)上運(yùn)行的從服務(wù)器上的快照提取器檢查主服務(wù)器的新快照。 如果snappullers找到一個(gè)新的集合版本,奴隸把它下拉并snapinstall它。
3.每次打開一個(gè)新的索引搜索器時(shí),緩存的一些自動(dòng)加熱發(fā)生在Solr對(duì)這個(gè)集合的版本進(jìn)行查詢之前。 查詢具有加熱的緩存的單獨(dú)查詢延遲是至關(guān)重要的。
三個(gè)相關(guān)參數(shù):
1.快照的數(shù)量/頻率完全取決于索引客戶端。 因此,集合的版本數(shù)由客戶端的活動(dòng)確定。
2.snappullers是cron'd。 他們可以每秒運(yùn)行一次,每天一次,或者之間的任何事情。 當(dāng)它們運(yùn)行時(shí),它們將僅檢索他們沒有的最近的集合。
3.在solrconfig.xml中為每個(gè)緩存配置緩存自動(dòng)升級(jí)。
如果您希望頻繁添加新集合,以使最近的更改顯示為“在線”,則必須同時(shí)具有頻繁提交/快照和頻繁snappull。 最常見的情況是,您可以分配索引更改并保持良好的性能,大概在1到5分鐘的范圍內(nèi),這取決于您對(duì)緩存的依賴性,查詢時(shí)間是否良好,以及自動(dòng)重新啟動(dòng)這些緩存所需的時(shí)間。
緩存自動(dòng)溫度對(duì)性能至關(guān)重要。 一方面,新的緩存版本必須填充足夠的條目,以便在系統(tǒng)切換到集合的新版本之后,從緩存提供后續(xù)查詢。 另一方面,自動(dòng)加熱(填充)新集合可能需要很多時(shí)間,特別是因?yàn)樗皇褂靡粋€(gè)線程和一個(gè)CPU。 如果您的設(shè)置太頻繁地關(guān)閉了快照安裝程序,則Solr從設(shè)備可能處于將查詢切換到一個(gè)(舊的)集合的不期望的狀態(tài),并且在加熱新集合時(shí),可以捕獲第二個(gè)“新” 變暖!
如果我們試圖解決這種情況,我們必須使第一個(gè)“新”集合無效,以便使用第二個(gè)集合,然后當(dāng)“第三個(gè)”新集合被捕獲和加熱時(shí),我們必須使“第二個(gè)” “新的收藏,等等廣告無限。 一個(gè)完全溫暖的集合永遠(yuǎn)不會(huì)完全中斷之前,它被中止。 這可以通過適當(dāng)調(diào)整的配置來防止,因此新集合不會(huì)被太快地安裝。