MongoDB或Solr用於文檔攝取，存儲和分面搜索？

我需要爲我正在處理的項目制定一個架構決策。這裏是要求：MongoDB或Solr用於文檔攝取，存儲和分面搜索？

攝入文件（.DOC，.PDF，.CSV，也許視頻）
實際文檔存儲（我假設服務器上的磁盤與一些參考上來自數據庫的文件） - 以及某些在數據庫中可搜索和可顯示的字段？
全文文檔搜索
磨製（基於選擇領域聚集從文檔攝入可能對每個文檔不同的 - 換句話說可能有200個刻面，但只有一些適用於各文檔）

我使用rails作爲服務器和當前的mySQL。我相信我在這裏至少有兩個明顯的選擇：

Solr;在mySQL中存儲來自文檔的字段，並使用Sunspot gem進行Solr索引和構面定義。這裏的好處似乎是快速搜索，刻面和文檔吸收工具。我不確定我的問題與200（也許更多 - 真正動態定義）方面。另外，考慮到這些文檔有各種形狀和大小，我想知道文檔存儲機制是否會更好。
MongoDB;使用mongoid gem將文檔內容存儲在MongoDB中。我對這裏的文檔提取實用程序並不熟悉，雖然文檔存儲有明顯的勝利，但我相信mongodb在全文搜索方面做得很好，但對於我來說，我需要使用多個查詢進行聚合，而且可能會很慢。

（我也知道我可以在MongoDB中使用Solr，但是......不確定）。

老實說，我對Solr和MongoDB都比較陌生，可以使用一些建議，因爲我確信我缺少一些優點和缺點。

來源

2013-03-13 Arthur Frankel

我認爲像S3和solr這樣的存儲網絡可能是最好的 – Sammaye 2013-03-13 12:47:12

當前的MongoDB生產2.2沒有全文搜索，也不容易在其上建立一些高效的（不推薦）。它來了......但還沒有準備好生產。根據數據的性質，即使面向搜索也可能是一個問題。 – WiredPrairie 2013-03-13 12:47:36

Sammaye - 謝謝...對於這個應用程序，客戶端過於關心安全性，因此雲存儲不是一種選擇（對他們而言）。 WiredPrairie，嗯，我想我一直在讀錯的東西。顯然這肯定會讓mongodb在棺材上留下一個釘子。 – 2013-03-13 12:51:56

我對MongoDB和Solr都有很好的經驗（儘管沒有任何關聯）。

根據您的需求，我建議Solr。

我曾在兩個不同的Web應用程序中搜索問題，第一個從嵌入事務數據庫的Oracle Text切換到Solr。從未回頭。儘管MongoDB可以做你所要求的東西，但我懷疑你會花費大量的時間讓MongoDB按照你想要的方式行事，特別是在面向方面。 Mongo的聚合框架相對較新。

你說你需要爲facet運行多個查詢。我希望這不是每個獨特價值的一個查詢，就像所有類別一樣，請計算每個類別中的產品數量。這在開發數據的第一天可能會正常工作，但要等到您獲得10,000個產品和500個類別以及50個用戶同時進行搜索時。然後，您有50個用戶同時針對相同的數據運行500個查詢。你將需要緩存它。

Solr已經爲你做了這一切。它在設計時考慮到了這些用例，並且在不必運行N + 1查詢的情況下就能很好地處理分面。 Solr還提供必要的緩存以避免頻繁的磁盤I/O。 Solr是高度可配置的。您可以在不重構代碼的情況下調整緩存大小，架構，分析器等。

例如，我會推薦使用MongoDB進行搜索，例如，當您的需求非常小並且不大可能發生重大變化時。例如，如果您想要提前輸入前綴，您可以簡單地爲每個文檔添加一個searchTokens字段並自行進行分析。

如果搜索組用戶，每個用戶可能看起來像：

{ 
    userId: 'x', 
    firstName: 'Brandon', 
    lastName: 'Ramirez', 
    searchTokens: [ 
    'b', 
    'br', 
    'bra', 
    'bran', 
    'brand', 
    'brando', 
    'brandon', 
    'r', 
    'ra', 
    'ram', 
    'rami', 
    'ramir', 
    'ramire', 
    'ramirez' 
    ] 
}

我使用MongoDB的具有該技術避免了Solr的複雜性。但這就是我所需要的。這是爲了提前輸入，所以我不需要刻面，也不需要一組動態可過濾字段，也不需要相關得分。

來源

2013-03-13 12:53:17 Brandon

謝謝你的迴應。似乎Solr（w/mysql）是一條路，因爲我將擁有大量的文檔以及大量的搜索/面對各種複雜程度的問題。 – 2013-03-13 15:36:24

聽起來像你可以使用elasticsearch。

這是一個搜索引擎，它使用與solr相同的底層lucene庫，但您存儲的所有內容都是JSON文檔。

全文搜索，分面搜索和過濾很多不同的屬性都很好。它確實有一些內置的聚合（直方圖等），雖然你應該檢查這些匹配你的需求。

根據您的彈性和吞吐量需求，構建跨多個機器的elasticsearch集羣也非常容易。

它有幾個ruby綁定，包括tire，由KarelMinařík爲彈性搜索工作。

來源

2013-03-13 13:33:29

非常有趣。在閱讀solr和elasticsearch的所有文章時，我不確定除了solr（目前）有更多的關注之外，我看到了很大的差異。思考？ – 2013-03-13 15:34:22

上次我查看了兩個solr 4還沒有準備好，所以這可能會過時，但是在那個時候ES有更好/更簡單的分佈式支持，更好的孩子/父母並且有更靈活的存儲（因爲您可以存儲任何你想要的json文件，嵌套等）。它也在積聚勢頭，例如github和[stackoverflow]（http://meta.stackexchange.com/questions/160100/a-new-search-engine-for-stack-exchange）最近已經移動了 – 2013-03-13 15:52:53

MongoDB或Solr用於文檔攝取，存儲和分面搜索？

回答

相關問題