我們正在討論一個規範化的數據集，它有幾個不同的實體，必須經常與相關記錄一起訪問。我們希望能夠搜索所有這些數據。我們還想使用緩存層來存儲視圖就緒的非規範化數據。將搜索引擎用作緩存層是否合適？
由於像Elasticsearch和Solr這樣的搜索引擎速度很快，並且由於在很多情況下將相同的數據放到搜索引擎和緩存層中似乎是適當的，所以我至少讀過了將兩者結合起來的軼事記錄角色。至少在表面層次上這是有道理的，但我沒有發現太多關於這種架構的優缺點的文章。因此：使用搜索引擎作爲緩存，還是使用一層兩個角色是合適的，一個是一分錢一分錢，一個是笨蛋？
這些人已經這樣做了......
我看到的問題是不是在讀取速度，但在寫入速度。將某些東西添加到緩存中會導致相當大的成本（強制後臺處理到磁盤和索引合併）。
像memcached或elastic cache之類的東西，如果您使用的是AWS，在插入和讀取時效率會更高。
「Elasticsearch和Solr速度很快」是相對的，高速緩存基礎結構通常以單位毫秒爲單位進行測量，對於插入也是如此。這些搜索引擎的讀取時間至少爲10毫秒，而寫入則高得多。
我聽說過使用ES的設置，它的優點是：完全上下文搜索，並與輔助存儲並行使用。在這些設置中，數據沒有被存儲（但可以是） - "store": "no" - 在用ES在其索引中進行搜索之後，實際記錄是從第二個存儲級別（通常是RDBMS）中檢索的，因爲ES持有對實際在RDBMS中記錄（某種ID）。如果你對速度和「搜索」方面給予的任何二級存儲不滿意，我不明白你爲什麼不能設置一個ES簇來爲你提供缺失的部分。
這裏的缺點是花費架構ES數據結構的時間，因爲ES在表示關係時不如RDBMS好。它並不需要，其主要工作和目的是不同的。實際上，用非常規的數據集進行搜索會更快樂。
另一個缺點是保持同步兩個存儲系統的複雜性，這需要一些思考。但是，一旦最初的設置和架構就位後，應該很容易。
使用搜索引擎的唯一推薦方式是創建與最常訪問的非規範化數據訪問模式匹配的索引。如果你願意，你可以稱它爲緩存。爲了搜索它是完美的，因爲它足夠快。 推薦爲這裏添加緩存 - 統計「聚合」查詢 - 「歐洲100強酒店」，作爲一個很好的例子。
也許你可以考慮內存中的lucene索引，而不是SOLR或elasticsearch。 Here is an example
哪個答案有幫助？ – sidgate
我真的很感謝大家的回答！羅布的博客帖子是一個我沒有發現的好帖子，他關於寫入速度和相對「牢度」的警告很好。但最終，我認爲這不是一個好問題。我想象的是，這種雙重用法必須有一些最佳實踐，技巧或經驗教訓作爲一般模式。但是我能找到的唯一「答案」就是它看起來很好，你只需要特別小心，能夠很好地爲你的數據定製搜索索引，從而獲得良好的性能。 –