2012-04-17 23 views
0

我有一個應用程序需要存儲大量的數據(每天約20萬txns),每個記錄大小約爲100 kb到200 kb。數據的格式將是JSON/XML。搜索使用Solr與地圖減少文件 - 這是可靠的?

應用程序應該高度可用,因此我們計劃將數據存儲在S3或AWS DynamoDB上。

我們有用例可能需要根據幾個屬性(日期範圍,狀態等)搜索數據。大多數搜索將使用少數常見屬性,但對於某些操作用例可能會有一些任意查詢。

我研究搜索非關係型數據和方法迄今發現正在使用的大多數技術 1兩種方式)建立索引(Solr的/ CloudSearch等) 2)運行一個Map Reduce作業(蜂巢/ Hbase等)

我們的要求是讓搜索結果可靠(與S3/DB中的數據一致 - 類似於oracle查詢,可以慢一點,但是當我們獲取數據時,我們應該有與返回的查詢相匹配的所有內容或者至少讓我們知道某些結果被跳過)

從一開始,它看起來像基於索引的方法會比MR更快。但我不確定它是否可靠 - 索引可能是陳舊的? (有沒有一種方法可以在我們進行搜索時知道索引已過時,以便我們可以糾正它?是否有辦法讓索引始終與DB/S3中的值一致?與Oracle DB上的索引類似)。 MR作業似乎總是可靠的(因爲它從S3獲取每個查詢的數據),這個假設是否正確?無論如何加快這個查詢 - 可能是S3中的分區數據,並根據每個分區運行多個MR作業?

+0

好像s3吞吐量對於map-reduce方法來說是個問題,對嗎?每次查詢都必須從s3中轉出千兆字節? – 2012-04-17 23:11:57

+0

你嘗試過Mongo DB嗎?如果我理解你的要求,Mongo提供同樣的事情。這是存儲在文檔中的一種Json,您可以按字段查詢數據。 – 2012-04-18 12:34:58

+0

謝謝我將進一步評估MongoDB。 – Arvind 2012-04-18 17:36:30

回答

0

你可以<提交/ >和<優化/ > Solr索引後添加文件,所以我不確定陳舊的索引是一個問題。我設置了一個Solr實例,每天處理大約100,000個額外的文檔。在我離職時,我們在索引中有140萬份文件。它被用於內部報告,並且性能很高(最複雜的查詢不到一分鐘)。我剛問過一位前同事,一年之後它仍然很好。

雖然我不能說地圖減少軟件。

+0

我不是很關心查詢花費時間,但如果它確保所有文檔在運行搜索時都被編入索引,我應該沒問題。有沒有辦法檢查索引狀態 - 索引了多少文檔等? – Arvind 2012-04-18 17:37:44

+1

我相信有一個管理頁面顯示索引文檔的數量。您還可以在所有字段和所有返回零行的內容上運行查詢並檢查行數。我認爲(http)查詢參數是這樣的:?q = *:*&rows = 0然後返回XML或JSON。 – mqsoh 2012-04-18 20:25:24

0

例如,您應該考慮每週/月有一個Solr核心,這種方式更舊的核心將是隻讀的,並且更容易管理,並且很容易分散到多個Solr實例上。如果每天需要添加200k文檔,那麼您需要使用Solr分片或者Solr分片,但單個內核永遠都不夠用。