哪些東西不能放到數(shù)據庫里？

我已經在很多演講里說過，改進你的系統(tǒng)的最好的方法是先避免做“蠢事”。我并不是說你或你開發(fā)的東西“蠢”，只是有些決定很容易被人們忽略掉其暗含 的牽連，認識不到這樣做對系統(tǒng)維護尤其是系統(tǒng)升級帶來多大的麻煩。作為一個顧問，像這樣的事情我到處都能見到，我還從來沒有見過做出這樣的決定的人有過好 的結果的。

    圖片，文件，二進制數(shù)據

既然數(shù)據庫支持BLOB類型的數(shù)據，把文件塞進BLOB字段里一定沒有錯了！？錯，不是這樣的！別的先不提，在很多數(shù)據庫語言里，處理大字段都不是很容易。

把文件存放在數(shù)據庫里有很多問題：

對數(shù)據庫的讀/寫的速度永遠都趕不上文件系統(tǒng)處理的速度

數(shù)據庫備份變的巨大，越來越耗時間

對文件的訪問需要穿越你的應用層和數(shù)據庫層

這后兩個是真正的殺手。把圖片縮略圖存到數(shù)據庫里？很好，那你就不能使用nginx或其它類型的輕量級服務器來處理它們了。

給自己行個方便吧，在數(shù)據庫里只簡單的存放一個磁盤上你的文件的相對路徑，或者使用S3或CDN之類的服務。

    短生命期數(shù)據

使用情況統(tǒng)計數(shù)據，測量數(shù)據，GPS定位數(shù)據，session數(shù)據，任何只是短時間內對你有用，或經常變化的數(shù)據。如果你發(fā)現(xiàn)自己正在使用定時任務從某個表里刪除有效期只有一小時，一天或數(shù)周的數(shù)據，那說明你沒有找對正確的做事情的方法。使用redis， statsd/graphite， Riak，它們都是干這種事情更合適的工具。這建議也適用于對于收集那些短生命期的數(shù)據。

當然，用挖土機在后花園里種土豆也是可行的，但相比起從儲物間里拿出一把鏟子，你預約一臺挖土機、等它趕到你的園子里挖坑，這顯然更慢。你要選擇合適的工具來處理手頭上的事。

    日志文件

把日志數(shù)據存放到數(shù)據庫里，表面上看起來似乎不錯，而且“將來也許我需要對這些數(shù)據進行復雜的查詢”，這樣的話很得人心。這樣做并不是一個特別差的做法，但如果你把日志數(shù)據和你的產品數(shù)據存放到一個數(shù)據庫里就非常不好了。

也許你的日志記錄做的很保守，每次web請求只產生一條日志。對于整個網站的每個事件來說，這仍然會產生大量的數(shù)據庫插入操作，爭奪你用戶需要的數(shù)據庫資源。如果你的日志級別設置為verbose或debug，那等著看你的數(shù)據庫著火吧。

你應該使用一些比如Splunk Loggly或純文本文件來存放你的日志數(shù)據。這樣去查看它們也許會不方便，但這樣的時候不多，甚至有時候你需要寫出一些代碼來分析出你想要的答案，但總的來說是值得的。

可是稍等一下，你是那片不一樣的雪花，你遇到的問題會如此的不同，所以，如果你把上面提到的三種東西中的某一種放到了數(shù)據庫里也不會有問題。不，你錯了，不，你不特殊。相信我。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]