SOLR性能調優

Question

我已經閱讀以下內容：

http://wiki.apache.org/solr/SolrPerformanceFactors

http://wiki.apache.org/solr/SolrCaching

http://www.lucidimagination.com/content/scaling-lucene-and-solr

而且我有幾件事情的問題：

1. 如果我使用JVM選項-XX:+UseCompressedStrings是什麼樣的可以節省內存嗎？舉個簡單的例子，如果我有1個索引字段（字符串）和1個存儲字段（字符串），其中omitNorms = true和omitTf = true，我可以期望索引和文檔緩存有哪些節省？我猜測大概有50％，但也許這太樂觀了。
2. 什麼時候Solr過濾器緩存在做什麼？如果我只是用AND和一些OR來做一個簡單的查詢，然後按分數排序，我是否還需要它？
3. 如果我想緩存文檔緩存中的所有文檔，我將如何計算所需的空間？使用上面的例子，如果我有20M文檔，使用壓縮字符串，並且存儲字段的平均長度爲25個字符，基本上是需要的空間（25字節+ small_admin_overhead）* 20M？
4. 如果所有文檔都在文檔緩存中，查詢緩存的重要性如何？
5. 如果我想將每個文檔自動控制到doc緩存中，會自動使用*:*查詢嗎？
6. 縮放-lucene-and-solr文章說FuzzyQuery速度很慢。如果我使用solr的拼寫檢查功能，那麼我基本上使用模糊查詢權限（因爲拼寫檢查執行相同的編輯距離計算）？所以大概拼寫檢查和模糊查詢都同樣「慢」？
7. 描述字符串的lucene字段緩存的部分有點令人困惑。我是否正確閱讀它，所需的空間基本上是索引字符串字段的大小+整數arry等於該字段中唯一項的數量？
8. 最後，在最大化吞吐量的情況下，有一條關於爲操作系統磁盤高速緩存留出足夠空間的聲明。它說：「總而言之，對於大規模的索引，最好確保至少有幾GB的RAM超出了你給JVM的範圍。」所以如果我有一個12GB的內存機器（例如），我應該給操作系統至少2-3GB？我可以通過查看磁盤索引大小來估計操作系統所需的磁盤緩存空間嗎？

Answer 1

1. 只有這樣才能嘗試一下。但是，我期望在索引中節省很少，因爲索引每次只包含一次實際字符串，其餘的是該文件中字符串位置的數據。它們不是指數的很大一部分。
2. 過濾器緩存只緩存過濾器查詢。它可能對您的確切用例沒有用處，但許多確實有用。例如，根據國家，語言，產品類型等縮小結果。如果經常使用它們，Solr可以避免重新計算這類事情的查詢結果。
3. 實際上，你只需要嘗試一下並用探查器來測量它。如果沒有深入瞭解所使用的數據結構，其他任何內容都是純粹的SWAG。你的計算和沒有分析的人一樣好。
4. 文檔緩存僅在計算查詢之後節省了構成結果的時間。如果你花大部分時間來計算查詢，那麼文檔緩存對你來說就沒有多大用處。查詢緩存僅對重用查詢有用。如果您的查詢都沒有重複，那麼查詢緩存沒用
5. 是的，假設您的文檔緩存足夠大以容納它們全部。

6-8不積極。

根據我自己的Solr性能優化經驗，您應該讓Solr處理查詢，而不是文檔存儲。大部分問題都集中在文件如何佔用空間。 Solr是一個搜索引擎，而不是文檔存儲庫。如果你想讓Solr快速並佔用最少的內存，那麼它唯一應該保留的就是用於搜索目的的索引信息。文檔本身應該被存儲，檢索和渲染到別處。優選在專門針對該作業優化的系統中。您應該存儲在Solr文檔中的唯一字段是用於從文檔存儲系統中檢索的ID。

Answer 2

緩存

一般來說，緩存看起來像一個好主意，以提高性能，但是這也有一個很大的問題：

• 緩存的對象很可能會進入老一代垃圾收集器，收集成本更高，管理插入和驅逐會增加一些開銷。

此外，除非查詢中有模式，否則緩存不太可能會提高搜索延遲。相反，如果20％的流量是由於少數查詢造成的，那麼查詢結果緩存可能會很有趣。配置緩存需要你很好地瞭解你的查詢和你的文檔。如果你不這樣做，你可能應該禁用緩存。

即使您禁用了所有緩存，由於操作系統I/O緩存的原因，性能仍然可能相當不錯。實際上，這意味着如果您一次又一次讀取文件的相同部分，則很可能只會在第一次從磁盤讀取數據，然後從I/O高速緩存中讀取數據。並且禁用所有緩存可讓您爲JVM減少內存，從而爲I/O緩存提供更多內存。如果你的系統有12GB內存，並且你給JVM 2GB，這意味着I/O緩存最多可以緩存10G的索引（取決於其他需要內存的應用程序）。

我推薦你讀這得到應用級緩存的詳細信息和I/O緩存：

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

場緩存

的大小字符串的字段高速緩存是（一個長度爲maxDoc的整數數組）+（一個用於所有唯一字符串實例的數組）。因此，如果您有一個索引，其中一個字符串字段平均具有N個大小爲S的實例，並且索引具有M個文檔，則該字段的字段緩存大小將近似爲M * 4 + N * S。

字段緩存主要用於構面和排序。即使是非常短的字符串（少於10個字符）are more than 40 bytes，這意味着如果您排序或面向具有大量唯一值的字符串字段，您應該期望Solr需要大量內存。

模糊查詢

FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.

這取決於您選擇的拼寫檢查器實現，但我認爲，Solr的3.x的拼寫檢查使用N元來尋找候選人（這就是爲什麼它需要一個專用索引），然後只計算候選人的這一組距離，所以表現仍然相當不錯。