存儲少量圖像：blob或fs？

Question

我正在向我的網站添加一些功能，以便用戶可以上傳自己的個人資料圖片，所以我想知道是將它們作爲BLOB存儲在數據庫中，還是將它們放在文件系統中。

我在這裏發現了一個類似這樣的問題：Storing images in DB: Yea or Nay，但給出的答案更多地針對期待成千上萬乃至數百萬圖像的人，而我更關心的是小圖像（JPEG可能高達150x150像素）以及其中的一小部分：可能高達一兩千。

對於這種情況，DB BLOB vs Filesystem有什麼感受？客戶端如何從數據庫緩存圖像或從文件系統緩存圖像？

如果存儲在DB中的BLOB是要走的路 - 有什麼我應該知道的關於的地方要存儲它們嗎？由於我想大多數用戶不會上傳圖片，因此在需要時，我應該創建user_pics表（外部）加入常規users表嗎？

---

編輯：我重新打開了這個問題，因爲它不是那些您連接到兩個的副本。這個問題具體是關於使用數據庫或FS用於少量圖像的優點/缺點。正如我上面所說，另一個問題是針對那些需要存儲成千上萬張大型圖像的人。

Answer 1

要回答你的問題的部分：

如何客戶緩存圖像去從DB VS從文件系統？

對於數據庫：在數據庫中有一個last_modified字段。使用Last-Modified HTTP標頭，以便客戶端的瀏覽器可以正確緩存。當瀏覽器請求一個圖像「if newer」（不能記起它所謂的;一些HTTP請求標頭）時，一定要發送適當的響應。

對於文件系統：執行相同的操作，但文件的修改時間相同。

如果存儲在數據庫中的BLOB是要走的路 - 有什麼我應該知道在哪裏存儲它們？因爲我想大多數用戶不會上傳圖片，我應該在需要時創建一個user_pics表（外部）加入常規用戶表嗎？

我會把BLOB和相關的元數據放在它自己的表中，它與你的用戶表之間有某種關係。這樣做可以更輕鬆地爲數據優化表存儲方法，使事情更加整潔，併爲可擴展性留下空間（例如，一般的「文件」表）。

Answer 2

從提供服務，編寫代碼服務於他們，備份過程等角度來看，更方便嗎？你想給你正確的答案，而不是別人的正確答案。

Answer 3

從我的角度來看，任何可能留在數據庫之外的東西都應該留在外面。它可能是文件系統或單獨的表，您不需要每天覆制或備份。它使數據庫變得更輕，增長更慢，更容易理解和維護。

如果您在MSSQL上，請確保blob存儲在單獨的數據文件中。不像其他一切一樣在主體上。

Answer 4

在Windows上，儘可能多地放入數據庫。文件系統有點慢，有時甚至不可靠。

在Linux上，您有更多選項。在這裏，您應該考慮將大文件移動到文件系統中，並將名稱保存在數據庫中。如果您使用Ext3或ReiseFS等現代文件系統，您甚至可以創建許多性能相當不錯的小文件。

您還需要考慮如何訪問數據。如果您擁有數據庫中的所有內容，則您擁有一條訪問路徑，無需擔心另一組權限，但您必須處理讀取/寫入BLOB的額外複雜性。在許多DB中，BLOB不能被搜索。

在文件系統上，您可以在您的數據上運行其他工具，如果這些文件存儲在數據庫中，則這是不可能的。

Answer 5

我曾經遇到過一個類似的問題，用於一個小型的DMS文件。該場景與您的場景不同：最多可能是100個文件，每個文件的大小最多爲10 MB，而不是您對個人資料照片的期望值。但朋友給我的回答也適用於您的情況：

使用每個存儲系統來設計它的目的。

商店數據在數據庫。商店文件在文件系統。

這不是最終答案（*），但它對初學者來說是一個很好的經驗法則。

我從來沒有聽說過Windows FS緩慢，有時不可靠，正如Aaron Digulla在他的回答中所述。如果存在這樣的問題，這當然需要考慮。但是對於頭像圖片來說，這並不意味着我很重要。

（*）我知道，我知道，42 ...

Answer 6

我將它們存儲在數據庫中：

1. 備份/恢復是容易的（如果你的備份文件，並在數據庫中，時間點恢復更加複雜）
2. db中的交易意味着你永遠不應該指向一個不存在的文件名
3. 更少的機會有人會想出一個鬼鬼祟祟的方式來放置一個腳本到你的服務器上，通過一個狡猾的圖像上傳黑客

由於您在談論少量圖像，因此易用性/管理應優先考慮鏈接問題中討論的性能問題。

Answer 7

我認爲存在將它們存儲在數據庫中的可管理性優勢;他們可以備份並與其他數據一致地恢復 - 您不會忘記刪除過時的（可能，但可能性稍差），並且如果將數據庫遷移到另一臺計算機，則圖像將隨它。