快取，帶來急速效能體驗！
solr提供了一系列的內建快取來優化查詢效能。solr的快取原理主要涉及以下4個方面：
1.快取大小及快取置換法
從快取大小的角度來看，不能將快取設定的太大，否則它會消耗jvm大量的記憶體。solr能將所有的快取物件都儲存到記憶體中，不會溢寫到磁碟中。為了控制快取大小，solr要求為每乙個快取都設定乙個快取物件的數量上限。當達到上限時，solr將會採用最久未使用【least recently used, lru】置換法或最近最少使用【least frequently used, lfu】置換法**一部分快取空間。
最久未使用置換法在快取大小達到閾值上限時，根據快取物件最後一次被請求的時間來決定快取物件被**的次序。當快取區達到上限，需要新增新的物件時，lru置換法將置換快取中最久未被使用的物件。lru置換法是solr的預設快取置換演算法。同時，solr還提供了最近最少使用置換法lfu，該方法根據快取物件被請求頻率的高低決定快取物件被**的次序。這種置換法給與快取中使用頻率高的物件更高的優先順序，而不是最近被請求的物件。solr的過濾器快取使用的是lfu置換法。因為過濾查詢的建立和儲存都是很耗費資源的，所以需要盡量降低過濾器快取的儲存大小，並且給予應用中頻繁使用的過濾器更高的優先順序。
在快取大小這有乙個常見的誤區，就是記憶體空間越大，快取就設定的越大。這樣做存在的問題是，一旦某個快取在一次提交操作之後失效了，jvm就需要做大量的垃圾**工作。且關閉乙個搜尋器會使得該搜尋器快取的所有物件都失效。如果沒有根據垃圾**的實際情況對快取大小進行合適的調整，就可能導致伺服器因垃圾**時間過長而導致長時間停止服務。因此，現階段最重要的是避免定義過大的緩衝區，並且要對快取物件進行週期性**。
2.快取命中率與快取**
快取命中率是指應用程式的快取命中的使用者請求數量佔所有使用者請求數量的比例。快取命中率表明了快取對應用程式的效能優化所起到的作用。理想情況下，希望快取命中率盡量接近1【100%】，低快取命中率表明快取對solr的效能優化沒有起到多大作用。
快取**數表明有多少快取物件被快取置換法**了。如果**量很大，則表明應用程式的快取物件的最大值可能設定的太小。快取**數和快取命中率是緊密相關的，低的快取**數往往代表乙個較好的快取命中率。
3.快取物件失效
在大多數的快取管理場景中，開發者需要考慮如何使乙個快取物件失效，這樣應用程式才不會返回過時的資料。在solr中完全不需要考慮這一點，因為所有的快取中的物件都會鏈結到對應的搜尋器例項，並且在搜尋器關閉後立即失效。搜尋器只是lucene索引快照的乙個唯讀檢視，因此，所有的快取物件在搜尋器關閉之前都是有效的。
4.自動預熱新快取
solr在每次提交請求之後都會建立乙個新的搜尋器，並且直到新搜尋器完成預熱，才會關閉舊搜尋器。solr利用即將被關閉的舊搜尋器中的部分快取構成新搜尋器的快取，這個過程稱為自動預熱。每乙個solr的快取都支援autowarmcount屬性，這個屬性表示自動預熱的舊快取物件的最大數目或百分比。快取物件自動預熱策略取決於快取的具體型別。
自動預熱過濾器快取
過濾器查詢是優化查詢語句的強大工具，但是如果開發者對過濾器快取管理不當，則會陷入麻煩中。如果索引中索引了大量的文件或者過濾條件非常複雜，那麼建立和儲存過濾器將會耗費大量的系統資源。如果乙個簡單的過濾查詢能夠被復用多次，那麼這個過濾查詢的快取便是有意義的。
快取中的每乙個物件都有乙個鍵，對於過濾快取來說，這個鍵就是過濾查詢語句。預熱新的快取時，一部分鍵將從舊的快取中抽取出來，向新搜尋器提交查詢，形成新的過濾器。要利用新搜尋器自動預熱過濾器快取，就需要solr重新執行過濾查詢。因此，自動預熱過濾器快取可能導致solr在效能和資源利用方面出現問題。特別是solr提交更改頻繁的應用程式，因為後台併發預熱的搜尋器太多了。
建議開發者為過濾器快取啟用自動預熱功能，但是給autowarmcount設乙個較小值作為初始值。除此之外，lfu置換法更適合過濾器快取，因為它能保證被請求頻率高的過濾器賦予較高優先順序，同時降低過濾器快取的大小。推薦的過濾器快取配置：
開發者需要在此配置的基礎上，根據應用程式實際使用的過濾器數量和對索引提交更新的頻率進行試驗，以得到最佳配置。
從每個過濾器快取的記憶體使用情況來看，根據匹配文件集合的大小，solr有不同的過濾表示方法。至於最大閾值，可以設定為每個過濾匹配文件集合中的maxdoc值。例如，如果索引檔案索引了1000萬份文件，那麼乙個過濾器快取可能占用一千萬位元的記憶體，及1.2m左右。
查詢結果快取會將查詢結果集儲存在快取中。當重複執行相同查詢時，後面的查詢結果都是第一次查詢結果的快取，而不是重新對lucene索引執行查詢。對於需要消耗大量計算資源的查詢來說，這是一種非常高效的解決方案。查詢結果快取的定義如下：
該方案背後的原理是將查詢語句作為鍵，內部lucene文件id作為值，儲存在查詢結果快取中。內部lucene文件id會隨著搜尋器的改變而改變，所以在預熱查詢結果快取時，快取的內部lucene文件id需要重新計算。同過濾器快取一樣，預熱查詢結果快取solr需要重新執行查詢語句，這可能需要消耗大量的資源。因此建議將autowarmcount設為乙個較小值。這樣可以通過自動預熱最近的查詢語句快取來提高應用程式的效能。
分頁對提高solr的查詢效能有重要意義。允許在執行查詢請求時定義單次返回查詢結果的資料條數。假設應用程式每頁顯示10份文件，使用者都只瀏覽第一頁和第二頁。那麼可以把此引數設定為20，這樣可以避免使用者在檢視第二頁時再次執行查詢請求。一般情況下會將這個引數值設定為每頁查詢結果數量的二到三倍。如果使用者很少檢視除第一頁之外的內容，最好將該引數設定為頁資料大小，避免返回過多資料。
引數對查詢結果快取中的每乙個快取物件包含的文件數目做出了限制。在大多數搜尋應用中，使用者一般僅檢視前幾頁的搜尋結果，所以可以將這個值設為每頁結果文件數目的二到三倍。
solr中一種常見的設計模式是只返回使用者查詢請求中要求的字段，而不是返回所以的字段。如果採用這種設計模式，需要將引數設定為true，這樣就可以避免載入使用者不需要的字段。在實際應用中，只返回使用者需要的字段是一種高效的設計模式。
查詢結果快取只快取了一組符合查詢條件的文件的內部id，所以即使查詢結果被快取了，solr還是需要從磁碟上載入這些文件內容。文件快取以文件的內部id為鍵，將磁碟中的文件內容載入到快取中。這樣查詢結果快取可以直接從文件快取中呼叫需要的文件內容。但文件快取只在索引更新頻率很低的情況下才適用，因為快取文件需要耗費大量的記憶體，頻繁的更新索引會導致頻繁快取文件，得不償失。
主要受lucene控制，不是由solr來管理。字段值快取提供了通過內部文件id快速訪問儲存的字段值的途徑，主要在排序和從匹配文件中生成響應內容時使用。
配置單機solr及執行
建立乙個solr home目錄，solrhome是solr執行的主目錄，目錄中包括了執行solr例項所有的配置檔案和資料檔案，solr例項就是solrcore，乙個solrhome可以包括多個solrcore solr例項 每個solrcore提供單獨的搜尋和索引服務。example solr是乙個...
windows下安裝及配置solr及ik分詞器
4 啟動 tomcat bin目錄下執行.catalina.bat start 解壓縮 war 包,後將其刪除，如圖 5 把solr安裝包下example lib ext 目錄下的所有的 jar 包，新增到 tomcat下solr 的工程中 web inf lib目錄下 有這幾個jar檔案 6 建立...
索引優化及原理
oracle 之sql優化 索引的基本原理 一 1 索引的基本概念 1 建立索引的目的 以索引小的io換取表的大io。何時建立索引 當訪問的資料塊少於表中20 的資料時，建議使用索引。2 索引的 會使insert delete速度變慢 索引個數多的話速度就會慢 對於update語句，需要先判斷是否要...