文檔管理：Solr提交不等于RDBMS提交

　　你很有可能已經知道，在Solr中沒有所謂的“更新”、“數據完整性外鍵”或者“多表”，實質上，Solr/Lucene只是通過索引形式管理日益增長的文檔集合。每次添加、更新或刪除一個文檔集合，Solr就會向其數據目錄中添加一個新“段”(一堆文件)，最后段的數量會越來越大。有一種機制可以應對這種情況，這里就不再贅述。

　　在Solr中，通過一個Searcher對象可以處理所有的搜索查詢。Searcher建立在索引組成的段的集合上。提交在這里的作用很簡單：“讓Solr生成新的Searcher，包括新段，并以原子方式用它替換當前Searcher。”

　　不要過分追求速度

　　避免不惜代價的并發提交，因為你不停地構建新的Searcher，之后又把它扔了。事實上，同時構建Searcher會導致在Solr的配置中產生一個顯式設置對數目施加嚴格上限，默認值是2。所以如果你同時提交的話，很有可能會獲得異常堆棧，抱怨打開的Searcher太多。

　　監視建立新Searcher的時間。優化在Solr中新建/更新文檔的響應時間(流行的說法是“實時”)，總的來說就是盡量減少Solr生成一個新Searcher對象的時間。監視Solr日志，查找“事件=newSearcher”，然后查找那些行QTime(查詢時間)，為的是使時間盡可能合理的短(我們稍后將看到為什么“合理”在這里很重要)，因為構建新Seacher的速度越快，你可以構建的Seacher就越多，插入、更新和刪除的響應就越快。

　　在Solr中有兩個主要的提交策略。第一個策略就是讓Solr在固定的時間間隔完成提交，該方法被稱為自動提交，應作為首選策略考慮，它可以幫助你擺脫對應用程序的手工管理。事實上，如果你使用了自動提交，那讓應用自己提交就成為一個非常糟糕的辦法，記住重疊Searcher的上限也適用于自動提交的Searcher，所以要讓自動提交比構建Searcher的時間更長。自動按固定時間間隔提交存在問題——在索引沒有更新時，定期構建新的Searcher只是在浪費CPU，這也為我們指出提交的第二個策略：

　　讓應用程序根據需要執行提交。并發是一個糟糕的辦法，應該實施全局的鎖機制。

　　給Searcher熱身

　　你可能會想“構建只增加了一個段的新Searcher能有多慢?Solr很好地支持這一點而且肯定會非?？?rdquo;。你說對了，它的速度確實非?？臁?/p>

　　唯一的問題是新Searcher最初的幾個查詢將會非常慢，這并不好。在高容量搜索環境中，幾個緩慢的查詢可能成為產品的短板，最終影響到應用程序層。這些最初查詢緩慢背后的原因是新Searcher緩存中填充的東西是無用的。在Solr術語中，這被稱為“Cold Searcher”。Solr允許使用“Cold Searcher”，但幸運的是這僅存在于其他Searcher也沒有被注冊的情況下。也就是說，它只發生Solr的實例剛開始時。在所有其他情況下，Solr會提供了一些給“Searcher”熱身的機制，確保在它們被用到服務請求時，查詢的速度不會太慢。

　　有兩組設置影響到新Searcher的熱身，應該將兩者結合起來使用。

　　一組是設置Solr對熱身中的Searcher進行查詢。針對這些查詢，可以建立幾個實時應用程序的典型查詢樣本，使其在移除過濾器后能更通用一些，關鍵是要盡量包括將在應用程序中使用的各個方面，還可以發出幾個關鍵字查詢，因為如果有足夠的空間，這種方法會在內存中加載全文索引。

　　另一種給新Searcher熱身的方法是在緩存中建立autowarming。高速緩存autowarming是將舊緩存中的值預先填充到熱身中的Searcher緩存中。

　　對于熱身中的Searcher關鍵是要找到建立新Searcher與注冊Searcher在時間上的平衡(建立新Search可以很快——但很危險)，找到這個平衡點需要進行實驗，而這一切都取決于應用程序層的需要。