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