本文描述solr的cache類型之一：filter cache。接下來，我會解釋它是什麼、怎麼配置它以及如何更好的使用它。
What it is used for?
先從內部機制開始。FilterCache存儲了一些無序的文檔標識號(ID)。這些ID並不是我們在schema.xml裏配置的unique key，而是solr內部的一個文檔標識。請記住這個。
FilterCache的任務是保持與用戶過濾的結果關聯。另外，cache可以輔助facet機制(在使用TermEnum時)，在solrconfig.xml中的<useFilterForSortedQuery/>參數設爲true時，還可以進行排序。
FilterCache的標準定義如下：
- <filterCache
- class="solr.FastLRUCache"
- size="16384"
- initialSize="4096"
- autowarmCount="4096" />
有以下的配置可供選擇：
class：實現類。建議使用solr.FastLRUCache，它能在大量的GET、PUT操作下，提供更好的性能。
size：cache的最大值。
initialSize：cache的初始化值。
autowarmCount：從舊的cache到新的cache時，需要被複制的數量。
minSize:在full restoraton的情況下，將cache減小後的值
acceptableSize：如果minSize沒有設置，則該值會替代之
cleanupThread：默認false，如果設爲true則會使用一個分離的topic來清理cache。
大部分情況下，設置initialSize和autowarmCount就已經足夠了。
How to configure？
cache的大小，需要根據基本的查詢語句而定；maximum大小應該至少等於我們使用的過濾字段的大小。舉個例子說明：如果在某個時間內，你的應用程序使用了2000個查詢參數，則minimum的大小應該最小設爲2000。
Efficient use
然而，光有配置是不夠的，我們還需要讓查詢能夠使用它。請看下面的例子：
- q=name:solr+AND+category:ksiazka+AND+section:ksiazki
初看起來，查詢語句是正確的。但是有個問題：它並沒有用到filterCache。所有的請求將會綁定到queryResultCache中並創建一個單獨的條目。我們來作一下修改：
- q=name:solr&fq=category:ksiazka&fq=section:ksiazki
有什麼變化呢？在這個例子中，一個條目會寫入到queryResultCache中；另外，還會有兩個條目會寫入到filterCache中。現在看一下下面的語句：
- q=name:lucene&fq=category:ksiazka&fq=section:ksiazki
這個查詢會創建一個條目到queryResultCache中，但是會使用filterCache中兩個已經存在的條目。這樣查詢的執行時間會降低，IO的使用也會節省。
然而，對於下面的查詢：
- q=name:lucene+AND+category:ksiazka+AND+section:ksiazki
solr不能使用任何cache並且需要從lucene索引中收集所有的信息。
Last few words
就像你所看到的，配置cache 的正確方法不是如何保證solr能夠使用它，而是如何構建查詢語句來提升性能。當考慮查詢的時候，請考慮這一點。