我打算在網絡服務器上存儲很多圖像（> 100,000）。如何在網絡服務器上存儲許多圖像？
該文件名將用於前。
324-2012-07-25-143544.jpg
的文件名是建立這樣的：
用戶id年 - 月 - 日 - HHMMSS.jpg
這個文件名將被保存在一個mysqldatabase中，並將被讀取，並從文件名中知道文件路徑 - >
個圖像/用戶名/年/月/日/用戶id年 - 月 - 日 - HHMMSS.jpg
所以在本例中是
圖像/ 324/2012/07/25/324-2012-07-25-143544.jpg
將everythin保存在basefolder/images中時可能發生的任何性能問題？
謝謝！
分割文件，就像你正在做的那樣，避免在一個目錄中有很多文件時出現性能問題的好方法：在這種方法中，你要確保只有幾個條目（目錄或文件）在任何給定的目錄中。如果需要的話，還可以輕鬆分割多個卷 - 只需在不同的位置安裝一些高級目錄即可。
你應該考慮一些事情。
如果你打算對這些圖像的基本永久存儲，你可能希望根據ID來碎片。從數據庫方面處理起來更容易一些（出於同樣的原因，我們在數據庫設計中使用了任意的主鍵）。
Like @Veger建議：imageid 123456變成/12/1234/123456.jpg。
使用日期，用戶ID或自動增加的編號可能會帶來安全風險，雖然，因爲它們相對容易猜到，因此它很容易爲別人收穫的所有圖像。
此外，如果沒有理由讓用戶知道上傳日期，那麼在URL中包含日期可能會泄漏信息。
如果您使用的是非常難猜的密鑰，它可以提供一定程度的安全性，以防收穫和信息泄露。例如，您可以使用GUID：圖像ID 6f33395e-eda8-4486-8b8e-51ea0f91751b被存儲爲/6/6f33/6f33395e/6f33395e-eda8-4486-8b8e-51ea0f91751b.jpg。
有一個瘋狂的高數量的GUID（它是128位），所以它可能需要數百萬年的時間才能收穫一切（即使你沒有采取任何額外的步驟，如每小時每IP限制連接等） 。
如果你的圖片是揮發性的 - 也就是說，他們一定量的時間之後過期 - 那麼它實際上可能是最好的基於日期結構，如/2012/12/14/2012-12-14-hhmmss-userid.jpg到分片，也可以結合這與一個GUID並得到。
如果你想刪除2011年的所有文件，你只需要rm -rf 2011。一個很好的例子是什麼時候使用這個日誌文件。
您必須記住，這隻對非常有用很高的圖像數量，因爲您可以在數據庫中查詢以查找基於日期的過期圖像，然後只是一個一個地刪除它們-一。
使用碎片的多個圖像的粒度更高您計劃最終商店，但請記住，如果你去過於詳盡，你會失去很多的開銷磁盤空間目錄條目。
目標是將每個目錄的條目數保持爲文件系統可以處理的條目數;好的經驗法則似乎是大約10,000最大。你必須預測你的網站將在下一段時間獲得的流量。不要發瘋，想一下你可能每天會有數百萬用戶。重新碎片並不是不可能的，但這是一種痛苦。預測未來幾年你的增長並處理它。如果你的增長速度更快，並且必須重新分片，那麼解決這個問題是一個很好的問題。如果你的磁盤空間不足，因爲你的目錄條目比你的圖片佔用更多的空間，那麼這是一個愚蠢的問題。
我會做這樣的：
例如，圖像編號1存儲爲/0/1.jpg，圖像編號1234567存儲爲/123/1234567.jpg（您可以存儲10000個文件到目錄中）。
最容易，噪音最小，並優化目錄中的文件數量（而不是浪費大量的半滿目錄）。
如果你真的要存儲很多的圖像，使用2個子目錄！像/0/0/1.jpg和/1/12345/123456789.jpg
如果你想使用日期部分作爲目錄結構，那麼確保你將它們唯一地存儲在數據庫中 - 如果它只用於絕對文件訪問，這沒問題。如果他們有可能會以編程方式使用（列出有圖像的有效年限），則將其存儲爲單獨的字段。沒有比嘗試將一個Dd字段拆分爲多個來處理更糟糕的事情了...... – Basic