三种东西永远不要放到数据库里

我已经在很多演讲里说过,改进你的系统的最好的方法是先避免做“蠢事”。我并不是说你或你开发的东西“蠢”,只是有些决定很容易被人们忽略掉其暗含的牵连,认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。作为一个顾问,像这样的事情我到处都能见到,我还从来没有见过做出这样的决定的人有过好的结果的。

图片,文件,二进制数据

既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错了!?错,不是这样的!别的先不提,在很多数据库语言里,处理大字段都不是很容易。

把文件存放在数据库里有很多问题:

  • 对数据库的读/写的速度永远都赶不上文件系统处理的速度
  • 数据库备份变的巨大,越来越耗时间
  • 对文件的访问需要穿越你的应用层和数据库层

这后两个是真正的杀手。把图片缩略图存到数据库里?很好,那你就不能使用nginx或其它类型的轻量级服务器来处理它们了。

给自己行个方便吧,在数据库里只简单的存放一个磁盘上你的文件的相对路径,或者使用S3或CDN之类的服务。

短生命期数据

使用情况统计数据,测量数据,GPS定位数据,session数据,任何只是短时间内对你有用,或经常变化的数据。如果你发现自己正在使用定时任务从某个表里删除有效期只有一小时,一天或数周的数据,那说明你没有找对正确的做事情的方法。使用redisstatsd/graphiteRiak,它们都是干这种事情更合适的工具。这建议也适用于对于收集那些短生命期的数据。

当然,用挖土机在后花园里种土豆也是可行的,但相比起从储物间里拿出一把铲子,你预约一台挖土机、等它赶到你的园子里挖坑,这显然更慢。你要选择合适的工具来处理手头上的事。

日志文件

把日志数据存放到数据库里,表面上看起来似乎不错,而且“将来也许我需要对这些数据进行复杂的查询”,这样的话很得人心。这样做并不是一个特别差的做法,但如果你把日志数据和你的产品数据存放到一个数据库里就非常不好了。

也许你的日志记录做的很保守,每次web请求只产生一条日志。对于整个网站的每个事件来说,这仍然会产生大量的数据库插入操作,争夺你用户需要的数据库资源。如果你的日志级别设置为verbose或debug,那等着看你的数据库着火吧。

你应该使用一些比如Splunk Loggly或纯文本文件来存放你的日志数据。这样去查看它们也许会不方便,但这样的时候不多,甚至有时候你需要写出一些代码来分析出你想要的答案,但总的来说是值得的。

可是稍等一下,你是那片不一样的雪花,你遇到的问题会如此的不同,所以,如果你把上面提到的三种东西中的某一种放到了数据库里也不会有问题。不,你错了,不,你不特殊。相信我。

[英文原文:Three things you should never put in your database ]
分享这篇文章:

10 Responses to 三种东西永远不要放到数据库里

  1. Null says:

    非常欣赏作者敢于发表”一刀切”言论的勇气,尤其是在数据库领域.

  2. 忧郁 says:

    很有用,记住了

  3. haitao says:

    基本符合我的习惯

    只是php好像无法保存session信息,因为没有一个常驻的内存区域可以放那些

  4. 新新 says:

    多谢指正,表示很受用

  5. waninlezu says:

    我就把 日志放数据库里了..查询很方便.
    有一个专门的 logserver 来存放这个库.
    目前尚未看到鸭梨.

    • colbox says:

      数据小那是什么压力。。。我在维护一个别人编写的程序,日志放在数据库里。我现在维护起来压力山大。。

  6. % says:

    多谢博主提醒,这就去改进!

  7. yonker says:

    三条理由不能完全站稳:
    1.如果你的应用对写入性能要求不苛刻,速度是在可接受的范围的。
    何况,像Oracle这类可以支持裸设备的特性,直接跳过文件系统,谁说比文件系统慢。
    2.备份耗时,不放在数据库中就不备份了吗?备份是都需要考虑的问题,数据库提供的增量备份特性是可以考虑的。
    3.穿越应用层和数据库层,虽然带来了路径的增加,但也带来可管理性和可维护性,并且利用数据库和应用层的缓存策略,可以加快并发访问的速度。

  8. hotdigger says:

    短生命期的数据不放在数据库中这条的确很好。我需要去改进我的系统。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.