數據庫設計和圖像文件系統管理？

Question

我正在尋找建立一個後端接受用戶上傳的圖像，重命名和存儲在一個文件系統（不，它不是一個Instagram的）

我想着簡單地重命名圖像和存儲在用戶文件夾：

圖像/ {用戶ID}/{用戶id} _ {MD5（時間戳）} JPG

的關聯也將被包括在數據庫中。

這是一個很好/足夠的模型？

Answer 1

本質上你的方法是不錯，但我的建議給你：

• 不使用時間戳的文件名，因爲你已經存儲在數據庫中的文件名，只需要創建額外的列對於時間戳< - > 文件關係。這種方式更容易管理像原創 創建，上次修改，甚至到期日期。
• 確保您存儲的文件名是唯一的。您不想意外存儲重複的文件名
• 對接受文件進行交叉檢查。如果文件成功保存到服務器但查詢失敗，請確保在發生故障時刪除 文件。或者，如果您的操作順序顛倒過來，請刪除 數據庫中的條目，如果文件無法保存到服務器。
• 如果圖像不允許公開訪問，您可以拒絕正常查看圖像，而是將用戶引導至 鏈接（PHP文件），並將文件名作爲GET變量。然後你可以 檢查SESSIONS和/或COOKIES，以確定他們是否有權以 查看它。如果是，則可以將輸出的標題設置爲 ，即jpeg或他們正在查看的任何類型的文件。

Answer 2

爲什麼不使用數據庫中的唯一ID，這使得它更容易找到文件。

此外，它不限制你如何構建你的文件，也許你不會總是想通過用戶名保存，如果每個文件都有一個綁定到數據庫的ID，這可能會簡單得多。

user/{database_id}.jpg 

Answer 3

有點兒取決於：

• 每個用戶有多少圖片？
• 約每個圖像的大小範圍？
• 有多少用戶？
• 你期望什麼樣的併發性？

如果上述大多數數字都很小，那麼您的方法可能會很長時間以足夠長的時間來讓您走得更遠，並且至少可以讓您開始。

我知道使用MySQL blob存儲獲得bad press，但這也是一個簡單的入門方法，您可以分割數據庫以在不需要進行任何巧妙編碼的情況下進行一些向外擴展。

也就是說......

如果在你的系統，你還指望用戶上傳大量文件，你可能會遇到文件系統的limits or performance issues。

如果您在Windows主機上，提防8.3 filename problem（很慢當目錄變大），爲您的文件名一定會超過8.3 :)

如果很多人都將上傳/同時下載 - 例如在高峯使用期間 - 您必須注意I/O爭用。如果你使用的是RAID 10卷，那麼你將會獲得更多，更好的是SSD（但是你可能會遇到存儲容量問題）。

如果有可能由不同的人上傳相同的圖像（跨多個文件夾複製），您建議的方法將不會是最節省空間的，在這種情況下，您最好使用數據（例如md5sum）和只存儲一個副本（是的，那麼管理問題與刪除）。

如果您期望很多人的大量圖像，您最終必須考慮擴展底層存儲。你可以通過{userid}和shard的一些函數在不同的卷或機器上對數據進行分區。這也會讓你獲得更好的併發吞吐量。

另一個問題：您是否總是隻提供原始圖像，或者您有時會發送重新縮放的副本？您可能需要縮放一次並始終返回預縮放版本，在這種情況下，您還需要考慮將縮放後的副本存儲起來。