關於圖片存入硬碟目錄還是存入資料庫

存入目錄和資料庫的例項我都遇到過。我覺得要看具體的需求。寫入目錄和寫入資料庫　其實備份都是很方便的　資料庫主從自動備份。其它優點就跟前面人說的人一樣。另外　寫入目錄不好的地方　會有很多垃圾資料無法清理　會有很多靜態檔案的重複但名字不一樣，ＤＢ存入不好的就是不太透明和直接提供靜態快取可能需要特殊的支援 但是可以解決垃圾資料和靜態檔案內容重複的問題　對於超大量的靜態檔案是否適合ＤＢ我就不清楚了。至於ＤＢ的讀取速度問題　可以有解決方案的　另外其實靜態檔案的ＤＢ應該是最後的儲存　減少他的訪問　大部分都是走的ＣＤＮ和本地快取（web前端也可以進行快取）

存入目錄效能好，便於運維管理、備份。

寫入目錄比寫入DB效能好：直接把temp file移動到目標位置即可，存資料庫的話還要拼湊sql，db server還要parse sql, write into file

從目錄讀取比從DB讀取效能好：任何WEB Server可以直接把目錄裡的圖片輸出給客戶端，C模組乾的活兒，從資料庫讀還要經過PHP中轉一道

對運維工程師而言，存入目錄有利於運維、備份、反向代理快取等等，比存在DB裡面方便很多 都是就事論事。沒有談到什麼樣的規模適合什麼樣的解決方案。

如果是小型應用，單機或者一個機房裡面的簡單叢集就頂的起的，目錄好。簡單方便。但是程式程式碼要處理好目錄路徑的問題，機器出現故障，要恢復，那是個災難。路徑絕對不能錯。

如果是超級大型應用，比如google自己的服務要用到圖片的，facebook的圖片服務，分散式，全球多資料中心，你看你還怎麼依靠作業系統的目錄來管理？ 這種情況下，必然是寫自己的分散式檔案系統，比如谷歌的Bigtable，也可以理解成nosql了。 Amazon的S3儲存服務，是基於文件型資料庫的，也是nosql。現在很多網站直接把自己的二進位制資料放在S3，能夠滿足全球分散式管理，並且不用自己動手。

沒有絕對的答案。還是那句話，看i的應用的規模，以及擴充套件性的需要。沒有絕對的答案。

單純比效能是nosql > mysql > 目錄

但是 mysql只要稍微做點優化，應該就 mysql == nosql，即使nosql好，估計也只能好個常數而已。

因為 訪問目錄檔案，是很慢的，他裡面有自己的一套索引，這套索引訪問估計不是hash，xp單個目錄超過10,000個檔案（個人經驗，寫了超多程式碼測試過），速度就迅速下降，window7效能良好，超過1,000,1000效能才會迅速下降，在100,000效能也很不錯（結論來自carmack）。

linux效能不清楚，但是比xp快20倍以上（至少吧）。訪問和寫的速度。

上面都是個人經驗。

關鍵看圖片儲存的規模及訪問的規模。 不同的需求就會有不同的解決方案： 1）在小規模的圖片儲存和訪問量的情況下，完全可以用單機的檔案系統來解決這個需求，在Linux中有針對小檔案儲存的檔案系統。 2）當圖片的規模不能用單機的硬碟來儲存了，就需要考慮分散式的儲存方案了（Facebook就用Hbase來進行儲存的，豆瓣採用自己開的BeansDB）。當然，如果有錢可以考慮買單獨的儲存裝置（比如EMC的）。 硬碟目錄好

1) 速度是一樣的 最後都是磁碟IO 2) 檔案於資料庫分開才方便備份 3) 方便分佈部署 4) 方便CDN

各種方便

個人理解 1、資料庫本身會成為瓶頸，所以啥都放進資料庫是不對的。。。 2、分開放有利於檔案訪問優化，有可能會快過資料庫