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ì)被太快地安裝。
