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

图片,文件,二进制数据

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

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

●对数据库的读/写的速度永远都赶不上文件系统处理的速度

●数据库备份变的巨大,越来越耗时间

●对文件的访问需要穿越你的应用层和数据库层

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

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

短生命期数据

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

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

日志文件

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

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

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

时间: 2024-10-21 00:59:05

三种东西永远不要放到数据库里的相关文章

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

原始出处:http://simple-is-better.com/news/872 我已经在很多演讲里说过,改进你的系统的最好的方法是先避免做"蠢事".我并不是说你或你开发的东西"蠢",只是有些决定很容易被人们忽略掉其暗含的牵连,认识不到这样做对系统维护尤其是系统升级带来多大的麻烦.作为一个顾问,像这样的事情我到处都能见到,我还从来没有见过做出这样的决定的人有过好的结果的. 图片,文件,二进制数据 既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错

牢记这三种东西永远不要放到数据库

我已经在很多演讲里说过,改进你的系统的最好的方法是先避免做"蠢事".我并不是说你或你开发的东西"蠢",只是有些决定很容易被人们忽略掉其暗含的牵连,认识不到这样做对系统维护尤其是系统升级带来多大的麻烦.作为一个顾问,像这样的事情我到处都能见到,我还从来没有见过做出这样的决定的人有过好的结果的. 图片,文件,二进制数据 既然数据库支持BLOB类型的数据,把文件塞进BLOB字段里一定没有错了!?错,不是这样的!别的先不提,在很多数据库语言里,处理大字段都不是很容易. 把文

编写Unity3D着色器的三种方式

不管你会不会写Unity3D的shader,估计你会知道,Unity3D编写shader有三种方式,这篇东西主要就是说一下这三种东西有什么区别,和大概是怎样用的. 先来列一下这三种方式: fixed function shader vertex and fragment shader surface shader 为什么Unity3D要提供三种shader的编写方式呢?那是因为三种方式的编写的难易度有区别,对应着不同的使用人群.其实我觉得这是Uniy3D想得有点多了,着色器不单止是为了实现效果,

SQL2000的三种“故障还原模型”

一.SQL2000的三种“故障还原模型” 在数据库属性的“选项”页,“故障还原模型”栏,共有三项选择:简单.完全.大容量日志记录.它们的根本差别在于SQL2000对数据库日志的维护方式不同.下面逐个讲述: 1.“完全”模型 我们都想象得出,如果需要实现“时点还原”,则SQL2000必须将所有的事务记录无一遗漏地保存下来,成为一条不中断的链.在日志文件中,每一条事务记录都被编了号(称“LSN”),号码是连续的. 在“完全”模型下,SQL2000对事务日志进行最严格.最彻底的管理.中心原理就是:如果

详解Oracle数据货场中三种优化:分区、维度和物化视图

转 xiewmang 新浪博客 本文主要介绍了Oracle数据货场中的三种优化:对分区的优化.维度优化和物化视图的优化,并给出了详细的优化代码,希望对您有所帮助. 我们在做数据库的项目时,对数据货场的优化,大约的原理只有两个:一是数据分块储藏,便于数据的转储和管教:二是其中处理,长进数据供给的速度.本文主要介绍了Oracle数据货场中的三种优化:对分区的优化.维度优化和物化视图的优化,基上面两个大约的原理,借助于数据货场的观念,罗列数据库的优化措施:1.分区在数据货场中,事实表,索引表,维度表分

EF Codefirst生成数据库的三种方式

1.写在前头 不是什么高大上的东西,也不是完全原创的,大多是自己学习时去网上查的各种资料.只是发现学东西还是要写点东西,不然前边写着后边忘了,花的时间都浪费了,写写增加记忆吧.如果是有人刚开始学看到这个相信会有帮助的. 2.开搞 前几天写了篇小文章搞了下EF生成数据库时获取连接字符串的方式,发布时不小心勾选了发布到首页,秒秒钟就被管理员给撤销了( ⊙ o ⊙ ),确实太低端了,博客园锅锅撤销也是可以理解的,废话不多说,今天继续搞一搞获取完连接字符串后EF怎么生成数据库呢,有哪些方式呢? 第一种:

关系型数据库横向扩展的三种方法

本文是 Oracle Coherence 3.5一书,第一章: Achieving Performance, Scalability, and Availability Objectives,第二节:Achieving scalability中,数据库横向扩展部分的读书笔记. 传统的关系型数据库很难扩展,通常是纵向扩展,但到达一定程度时只能横向扩展. 数据库的横向扩展支持三种方法,即主从复制,集群和分片(sharding). 主从复制 主从复制(Master-slave replication)

EF三种数据库操作模型比较

https://blog.csdn.net/xiongmeiqin/article/details/80196089 EF 中 Code First 的数据迁移以及创建视图 写在前面: EF 中 Code First 的数据迁移网上有很多资料,我这份并没什么特别.Code First 创建视图网上也有很多资料,但好像很麻烦,而且亲测好像是无效的方法(可能是我太笨,没搞成功),我摸索出了一种简单有效的方法,这里分享给大家. EF是Entity Framework(实体框架)的简写,是微软出品的用来

三种数据库访问——Spring3.2 + Hibernate4.2

前三篇随笔中介绍了 用原生的JDBC访问数据库.一种高效的数据库连接池druid.用Spring的JDBC框架访问数据库. 本文继续介绍第三种数据库访问的解决方案:Spring3.2 + Hibernate4.2 ORM框架 Hibernate是一个开源的ORM框架,能自动为对象生成相应SQL并透明的持久化对象到数据库,我们首先来了解一下什么是“ORM”. ORM全称对象关系映射(Object/Relation Mapping),指将Java对象状态自动映射到关系数据库中的数据上,从而提供透明化