搜索查詢的緩存策略

我們正在開發一個搜索引擎Web應用程序，使用戶能夠搜索約200個門戶的內容。搜索查詢的緩存策略

我們的業務合作伙伴負責維護和提供solr/lucene實例，該實例正在爲數據建立索引數據。

我們的應用程序查詢以人性化的方式解決並呈現結果。但是，我們想知道如何限制查詢的數量，可能使用某種形式的緩存。結果可以緩存幾個小時。

我們想知道的是：什麼可能是好策略用於緩存查詢結果？很明顯，我們期望方法調用的變化很大......做緩存有意義嗎？

在這個用例中是否有一些特別適合的緩存系統？我們正在使用Spring 3進行開發。

2012-10-25 Giordano

好吧，這不是我的主要領域，但是在緩存之後，我們的性能顯着提高。我們每6到12小時緩存一次，實際上我們使用memcached來處理它。您的緩存索引可能會隨着時間的推移而變得非常大，但是有一點保留策略（即緩存中的某個頁面沒有一週點擊 - >刪除），您應該能夠控制所有內容 –

我會記住，Solr已經有很多內置的緩存，以加快常見的查詢。我建議您在關閉之前查看Solr/Lucene中的固有功能，並使用您自己的查詢緩存查找reinvent the wheel。

Here是一個很好的開始。

2012-10-25 12:48:02 pap

最簡單的解決方案是在命中Solr之前重新進行查詢。

我創建了我自己的QueryBuilder方法，它在點擊Solr之前通過我的查詢字符串。

所有這些都會爆炸所有參數，然後將它們排序到預定義的組集中。

例如，爲了使您的查詢標準化以便它們可以緩存，您可以按字母順序對每個鍵進行排序，然後重新構造查詢字符串，然後使用它查詢Solr。（實際查詢結果將保持不變）。

在您真正運行查詢之前，您可以創建一個Solr查詢字符串的哈希值並檢查所有已保存的密鑰的內存哈希值。如果發現自己接近數百萬個可能很有可能的查詢關鍵字，則可能需要開始考慮使用BloomFilter來減少關鍵字空間，並仍然保持緩存命中的某種程度的準確性。

或者，您可能需要考慮在您和Solr之間放置反向代理緩存。例如，如果要查詢Solr，可使用Spring -> Varnish -> Solr,Varnish進行緩存，並將查詢字符串用作散列。然後，您可以設置2小時過期，以便自動刷新/清除/失效結果。

希望這會有所幫助。

2012-10-25 09:42:46 Layke

我發現使用自定義的QueryBuilder確實可以幫助規範化並緩存查詢。但你確定這些單詞的順序無關緊要嗎？例如，在鄰近搜索中它確實很重要。 – Giordano

是的，對不起，我打算包括那個，但是假設它很清楚。說的順序，fq的論點並不重要。所以你必須將你所有的fq參數排在一起。您必須確保其他類型的分組順序保持一致。 – Layke

我發現在Lucene之外緩存結果或呈現的內容效果最好。擁有一個API搜索服務，該服務通過Lucene索引的結果指向緩存層。

如果將緩存層分開，則可以插入所需的緩存......分佈式緩存（Redis，Azure AppFabric，其他雲緩存等）。此外，您還可以緩存網頁的部分渲染（即在ASP.NET中進行輸出緩存）或使用RESTful慣例緩存API調用。像緩存加溫或主動緩存（基於使用）等事情很容易處理服務。

然後，您的應用程序/索引緩存可以在應用程序的更多層「重用」，而不僅僅是在索引級進行緩存。這一切都取決於如果您的索引更新是實時的，如果查詢是針對每個客戶端/用戶ID的日期級別安全等。如上所述，Solr已經爲您做了「一些」這些東西。

2012-10-25 14:14:45

我會爭辯說，如果您將其配置爲這樣做，Solr會「完成」所有這些功能，並在索引更改時使緩存無效 - 這是您自己構建時難以實現的功能查詢緩存層。 – pap

回答