2011-07-16 56 views
1

在工作中,我開始研究一個程序,該程序可能會在一小時內生成數十萬個大多數小文件。我的前任已經發現,處理很多小文件會變得非常緩慢,所以他們採取了一些(在我看來)粗略的方法來緩解這個問題。使用數據庫而不是成千上萬的小文件

所以我問我的老闆爲什麼不用我們的數據庫來代替他,他給了我他着名的我知道的比你好看,並告訴我明顯是一個數據庫,沒有好的表現。

我的問題是,這是真的嗎?在我看來,數據庫引擎應該能夠比文件系統更好地處理這些數據。以下是我們的條件:

  • 該程序主要是寫數據。查詢要少得多,他們的表現也不是很重要。
  • 每天都可以生成數百萬個文件。其中大部分都很小(幾千字節),但有些可能很大。

如果您認爲我們應該選擇數據庫解決方案,您認爲哪種開源數據庫系統最適合? (如果我決定一個數據庫肯定會更好地工作,我要去推動的改變無論老闆說!)

+2

你的老闆可以很該死確保數據庫開發民間有優化的數據庫插入和檢索至少不亞於你的前任優化訪問這些數以千計的小文件。許多用戶都以MySQL作爲開源數據庫。許多這些用戶運行數十萬條記錄的數據庫。性能要比使用裸文件系統要好得多,部分原因是數據庫表通常可以保存在內存中(只是其中一種優化技術,您會發現)。 *顯然!* :-) –

回答

6

這是其中的一個又一個「這取決於」式的問題。

如果你只是寫數據(寫一次,讀幾乎沒有),那麼只需要使用文件系統。也許使用哈希目錄的方法來創建大量的子目錄(事情往往會緩慢,許多文件在一個單一的目錄中

如果你正在編寫成千上萬的事件供以後查詢(例如找到所有與X > 10和Y < 11),則數據庫聽起來像一個偉大的想法。

如果你正在寫幾十萬非關係型數據的位數(例如簡單的鍵 - 值對),那麼它可能是值得研究的一個NoSQL做法。

最好的辦法可能是原型所有你能想到的思想,衡量和比較!

+0

謝謝。這可能是我會做的。我將特別關注_NoSQL_數據庫,因爲我們的數據大部分類似於簡單的鍵值對(帶有一些不常用於查詢的註釋)。我們對文件系統的一個問題是當我們有這麼多的文件時,有時甚至打開一個新的文件來寫入可能會很慢。也許文件存儲或類似的東西可能會有所幫助。 – Elektito

+1

對於NoSQL方法,請查看[MongoDB](http://www.mongodb.org/)(及其[GridFS](http://www.mongodb.org/display/DOCS/GridFS)大文件)。你需要測試你的用例的性能,但它至少是一個相對簡單的解決方案。 – cwb

2

作爲一個最小的影響改進,我會將你的數百萬個小文件分割成多個目錄。所以說你使用uuids作爲你的文件名,我會在前面指出多餘的urn:uuid:,然後根據第一個字母製作16個目錄,並在裏面製作16個基於第二個字母的子目錄,並且如果你需要的話可以添加更多的關卡。僅此一項就會加快訪問速度。此外,我會刪除該目錄,只要它變空了,以確保目錄條目本身不會越來越大。

相關問題