MongoDB作爲文件存儲

Question

我試圖找到最好的解決方案來爲大文件創建可伸縮存儲。文件大小可以從1-2兆字節到500-600千兆字節不等。

我發現了一些關於Hadoop和它的HDFS的信息，但它看起來有點複雜，因爲我不需要任何Map/Reduce作業和許多其他功能。現在我正在考慮使用MongoDB，它是GridFS作爲文件存儲解決方案。

而現在的問題：

1. 將GridFS的發生什麼，當我嘗試寫一些文件 兼任。讀/寫操作是否會有鎖定？ （我將只用它作爲文件存儲）
2. 將gridfs中的文件緩存在ram中，以及它如何影響讀寫性能？
3. 也許還有一些解決方案可以更有效地解決我的問題？

謝謝。

Answer 1

我只能在這裏回答MongoDB，我不會假裝我對HDFS和其他類似技術有很多瞭解。

GridFs的實現完全是驅動程序本身的客戶端。這意味着MongoDB本身並沒有特殊的加載或理解文件服務的上下文，有效的MongoDB本身甚至不理解它們是文件（http://docs.mongodb.org/manual/applications/gridfs/）。

這意味着查詢的files或chunks收集的任何部分將導致相同的過程，因爲它會爲代表的一組中的任何其他查詢，因此它加載它需要爲您的工作集（http://en.wikipedia.org/wiki/Working_set）數據MongoDB在給定時間範圍內所需的數據（或當時所有加載的數據），以保持最佳性能。它通過將它分頁到RAM中（技術上在操作系統中）。

到另一個需要考慮的一點是，這是驅動程序實現的。這意味着規範可能會有所不同，但是，我不認爲它確實如此。所有驅動程序將允許您查詢files集合中的一組文檔，該集合僅包含文件元數據，允許您稍後通過單個查詢從chunks集合中提供文件本身。

但是這不是最重要的事情，你要提供服務的文件本身，包括它的數據;這意味着您將會將files收藏集及其隨後的chunks收藏集加載到您的工作集中。

考慮到這一點，我們已經碰到的第一個障礙：

將從GridFS的文件在內存中緩存以及它如何影響讀寫性能比較？

小文件的讀取性能可能很棒，直接來自RAM;寫入會一樣好。

對於大文件，並非如此。大多數計算機不會有600 GB的RAM，實際上很可能在單個mongod實例中容納一個600 GB的單個文件分區。這會產生一個問題，因爲該文件爲了得到服務需要適合你的工作集，但它不可能比你的RAM大;在這一點上，您可能會導致頁面抖動（http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29），從而導致服務器24/7全天候嘗試加載文件。這裏寫的也不好。

解決這個問題的唯一方法是開始把一個文件在許多碎片:\。

注意：還有一件要考慮的事情是chunks「塊」的默認平均大小是256KB，因此這是600GB文件的大量文檔。這個設置在大多數司機中是可操作的。

當我嘗試同時寫入幾個文件時，gridfs會發生什麼情況。讀/寫操作是否會有鎖定？ （我會用它只能作爲文件存儲）

GridFS的，暫時只有一個規範使用相同的鎖上沒有任何區別，讀取和寫在數據庫級（2.2+）鎖或在全球範圍內（預2.2）。這兩者確實也會相互干擾，即如何確保一致地讀取正在寫入的文檔？

，對於爭的可能性是存在的根據您的具體情況而說，交通，併發寫入/讀取數和許多其他的事情我們不知道的想法。

也許還有一些解決方案可以更有效地解決我的問題？

我個人發現，S3（如@mluggy說）以簡化冗餘格式最存儲元數據的一部分僅僅約內MongoDB的文件，就像使用GridFS的，但沒有大塊的收集，讓S3手柄所有的分配，備份和其他東西給你。

希望我已經明確，希望它幫助。

編輯：不像我意外地說，MongoDB沒有集合級別鎖定，它是一個數據庫級別鎖定。

Answer 2

我會回答前兩個開始：

1. 到GridFS的寫入時，有一個寫鎖，是的。讀取沒有鎖定。
2. 當你查詢文件時，文件不會被緩存在內存中，但它們的元數據將會被緩存。

GridFS可能不是您的問題的最佳解決方案。在處理這種類型的情況時，寫鎖定會變得很痛苦，特別是對於大文件。還有其他數據庫可以爲你解決這個問題。 HDFS是一個不錯的選擇，但正如你所說，它非常複雜。我會建議考慮像Riak或亞馬遜S3的存儲機制。他們更傾向於存儲文件，並且不會帶來重大缺陷。 S3和Riak都擁有出色的管理設施，並且可以處理大量文件。雖然與Riak，我知道，你必須做一些文件分塊存儲文件超過100MB。儘管如此，對於巨大的文件大小來說，對某種程度的分塊通常是一種最佳做法。將文件傳輸到數據庫時會發生很多不好的事情 - 從網絡超時到緩衝區溢出等。無論採用哪種方式，您的解決方案都需要對大量文件進行大量調整。

Answer 3

您是否考慮將元數據保存到MongoDB並將實際文件寫入Amazon S3？兩者都具有出色的驅動程序，而後者則是高度冗餘的雲/ cdn文件存儲。我會給它一個鏡頭。