什麼是filtercache？

    solr應用中為了提高查詢速度有可以利用幾種cache來優化查詢速度，分別是fieldValueCache，queryResultCache，documentCache，filtercache，在日常使用中最為立竿見影，最有效的應屬filtercache，何謂filtercache？這個需要從一段solr的查詢日誌開始說起，下面是我擷取的solr執行中列印的一段查詢日誌：

[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 2                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A411%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 2                  
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 2                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A8059%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 0                 
[search4alive-0] Request_is ==> debugQuery=on&group=true&group.field=group_id&group.ngroups=true&group.sort=gmt_create+desc&q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+ha
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=30&rows=30,queryTime_is ==> 4                                    
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A1+AND+class_id%3A1+AND+%28group_id%3A375%29&sort=gmt_create+desc&start=0&rows=20,queryTime_is ==> 3                  
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 4                                     
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=5,queryTime_is ==> 1                                      
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 4                                     
[search4alive-0] Request_is ==> q=status%3A0++AND+biz_type%3A2+AND+class_id%3A1&sort=index_sort_order+desc&start=0&rows=30,queryTime_is ==> 3                                     

   看到這段查詢日誌之後，我們開始考慮如何提升查詢的rt（查詢速度），因為在引數q中的查詢是要有磁碟IO開銷的，很自然的思路是將整個查詢的引數q作為key，對應的結果作為value，這樣做是可以的，但是查詢的命中率會很低，會佔用大量記憶體空間。

   查詢引數q上基本上每次都會出現status,biz_type,class_id 對於這樣的字查詢，所以可以把整個查詢條件分成兩部分一部分是以status,biz_type,class_id 這幾個條件組成的子查詢條件，另外一部分是除這三個條件之外的子查詢。在程序查詢的時候，先將status,biz_type,class_id 條件組成的條件作為key，對應的結果作為value進行快取，然後再和另外一部分查詢的結果進行求交運算。

       通過上面這幅圖明白了filtercache的意義是，將原先一個普通查詢分割成兩個組合查詢的與運算，兩個子查詢至少有一個使用快取，這樣既減少了查詢過程的IO操作，又控制了快取的容量不會消耗過多的記憶體。

如何使用？

首先要配置solrconfig.xml 要開啟fltercache：

1. <query>
2.         <filterCacheclass="solr.LRUCache"size="50000"initialSize="512"autowarmCount="0"/>
3. </query>

 這裡使用的是solr實現的基於LRU演算法的緩實現，以上配置是使用solr.LRUCache ，使用這個cache在插入多，查詢少的情況比較使用，如果是查詢多，插入少

客戶端API呼叫：

下面是原先的客戶端端查詢程式碼：

1. SolrQuery query = new SolrQuery();  
2. query.setQuery("status:0 AND biz_type:1 AND class_id:1 AND xxx:123");  
3. QueryResponse response = qyeryServer.query(query);  

使用filterQuery之後的查詢程式碼：

1. SolrQuery query = new SolrQuery();  
2. query.addFilterQuery("status:0 AND biz_type:1 AND class_id:1");  
3. query.setQuery("xxx:123");  
4. QueryResponse response = qyeryServer.query(query);  

經過測試這樣優化之後，查詢的RT（查詢速度）會明顯減小，QPS（每秒查詢率）會有明顯提升。

使用filterquery過程中需要注意點：

●不能在filterQuery 上重複出現query中的查詢引數，如果上面的filterquery呼叫方法如下所示：

1. query.addFilterQuery("status:0 AND biz_type:1 AND class_id:1 AND xxx:123");  
2. query.setQuery("xxx:123");  

 如上，條件xxx:123 在filterQuery和query上都出現了，這樣的寫法非但起不到查詢優化的目的，而且還會增加查詢的效能開銷。

●儘量減少呼叫addFilterQuery方法的次數

1. query.addFilterQuery("status:0 ");  
2. query.addFilterQuery("biz_type:1 ");  
3. query.addFilterQuery("class_id:1 ");  
4. query.setQuery("xxx:123");  

如上，將status:0 AND biz_type:1 AND class_id:1 這個組合查詢條件，分三次呼叫filterQuery方法來完成，這樣的呼叫方法雖然是正確的，並且能起到效能優化的效果，優化效能沒有呼叫一次addFilterQuery方法來得高，原因是多呼叫了兩次addFilterQuery，就意味著最後需要多進行兩次結果集的求交運算，雖然結果集求交運算速度很快，但畢竟是有效能損耗的。

不過從記憶體開銷的角度來說，呼叫三次addfilterQuery方法這樣可以有效降低記憶體的使用量，這個是肯定的。所以在是否呼叫多次addFilterQuery方法的原則是，在記憶體開銷允許的前提下，將量將所有filterQuery條件，通過呼叫有限次數的addFilterQuery方法來完成。

下文摘自solr中國

What it is used for?

先從內部機制開始。FilterCache儲存了一些無序的文件標識號(ID)。這些ID並不是我們在schema.xml裡配置的unique key，而是solr內部的一個文件標識。請記住這個。

FilterCache的任務是保持與使用者過濾的結果關聯。另外，cache可以輔助facet機制(在使用TermEnum時)，在solrconfig.xml中的<useFilterForSortedQuery/>引數設為true時，還可以進行排序。

Definition
FilterCache的標準定義如下：

1. <filterCache
2.     class=”solr.FastLRUCache”
3.     size=”16384″
4.     initialSize=”4096″
5.     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
然而，光有配置是不夠的，我們還需要讓查詢能夠使用它。請看下面的例子：

1. q=name:solr+AND+category:ksiazka+AND+section:ksiazki

初看起來，查詢語句是正確的。但是有個問題：它並沒有用到filterCache。所有的請求將會繫結到queryResultCache中並建立一個單獨的條目。我們來作一下修改：

1. q=name:solr&fq=category:ksiazka&fq=section:ksiazki
2. 對應java程式碼：

3.     SolrQuery query = new SolrQuery();  
       

       query.addFilterQuery("category:ksiazka");
       query.addFilterQuery("section:ksiazki");  
       query.setQuery("name:solr");  
         
       QueryResponse response = qyeryServer.query(query);  

   
   
   

有什麼變化呢？在這個例子中，一個條目會寫入到queryResultCache中；另外，還會有兩個條目會寫入到filterCache中。現在看一下下面的語句：

1. q=name:lucene&fq=category:ksiazka&fq=section:ksiazki

這個查詢會建立一個條目到queryResultCache中，但是會使用filterCache中兩個已經存在的條目。這樣查詢的執行時間會降低，IO的使用也會節省。

然而，對於下面的查詢：

1. q=name:lucene+AND+category:ksiazka+AND+section:ksiazki

solr不能使用任何cache並且需要從lucene索引中收集所有的資訊。

Last few words
就像你所看到的，配置cache 的正確方法不是如何保證solr能夠使用它，而是如何構建查詢語句來提升效能。當考慮查詢的時候，請考慮這一點。