【轉帖】三種決不能放進資料庫的東西

 

原文：http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/

譯者：cxhuan 

        想我在一些演講中說的一樣，提升系統效能的最好的方式是千萬不要做“傻事”。我並不是說你或者你的開發人員是傻子，而是說人們容易忽略這些決策的隱形問題，沒有意識到一些問題的可維護性。作為一個諮詢顧問，這種案例我見多了，還沒見過有誰能夠很好地解決這個問題。

圖片，檔案和位元組資料
        你們的資料庫支援大容量位元據，所以你覺得應該把你的檔案放進去，對嗎？完全不是這樣的。這樣甚至不方便多種資料庫語言的綁定。將檔案儲存體在資料庫中有幾個問題：
        讀/寫資料到資料庫總比檔案系統慢
        Database Backup量巨大而且更耗時
        訪問檔案時要通過應用程式層和資料庫層
        最後兩條是真正的禍害。將縮圖放進資料庫？很好，但是現在你無法用代理器或者其他的輕量級Web伺服器來支撐他們了。
省省吧，儲存你硬碟檔案上的一個相對路徑到資料庫或者用類似於S3或CDN的東西代替就可以了。

臨時資料
        統計度量資料，GPS位置資訊，會話資料，任何只使用短時間或者經常變換的資料都是臨時資料。如果你發現自己花大量時間去刪除只使用一個小時、一天、一周的表格，那麼你就用了錯誤的工具了。使用 redis, statsd/graphite, Riak或者任何更適合的工具去工作吧。這種方法同樣適用於彙總性的臨時資料。與其預定時間等挖掘機趕到你那裡去挖個坑種番茄，還不如在車庫裡那個鐵剷出來挖來的快。做事要選用合適的工具。

日誌
        這個日誌表面上看好像是可以放進資料庫的，而且那個“我可能在未來需要用複雜的查詢語句來查詢他們”的言論好像更得人心。將日誌存進資料庫不可怕，可怕的是將他們和其他產品資訊放進同一個資料庫。也許你對日誌比較保守，一般將每個Web請求放進同一日誌行中。那樣仍然會對網站的每一個動作產生一條插入記錄來和使用者爭用資源。將你的記錄層級設為冗餘或者調試來代替用諸如Splunk，Loggly或者舊的簡單的檔案系統，不要放進產品資料庫。你需要偶爾的檢查他們，有時候甚至需要寫一小段代碼來找資料，這比在你的系統中放入固定資源要容易。
        你是獨立個體，你的問題與眾不同，所以你做了其中一項也無所謂。不，事實真不是這樣的。相信我。