关于图片存入硬盘目录还是存入数据库

sai8808
  • 779

图片不大于50kb

是存入数据库(mysql,nosql)性能好还是存入目录性能好

请说明原因

回复
阅读 29.8k
7 个回答

存入目录和数据库的实例我都遇到过。我觉得要看具体的需求。写入目录和写入数据库 其实备份都是很方便的 数据库主从自动备份。其它优点就跟前面人说的人一样。另外 写入目录不好的地方 会有很多垃圾数据无法清理 会有很多静态文件的重复但名字不一样,DB存入不好的就是不太透明和直接提供静态缓存可能需要特殊的支持 但是可以解决垃圾数据和静态文件内容重复的问题 对于超大量的静态文件是否适合DB我就不清楚了。至于DB的读取速度问题 可以有解决方案的 另外其实静态文件的DB应该是最后的存储 减少他的访问 大部分都是走的CDN和本地缓存(web前端也可以进行缓存)

存入目录性能好,便于运维管理、备份。

写入目录比写入DB性能好:直接把temp file移动到目标位置即可,存数据库的话还要拼凑sql,db server还要parse sql, write into file

从目录读取比从DB读取性能好:任何WEB Server可以直接把目录里的图片输出给客户端,C模块干的活儿,从数据库读还要经过PHP中转一道

对运维工程师而言,存入目录有利于运维、备份、反向代理缓存等等,比存在DB里面方便很多

硬盘目录好

1) 速度是一样的 最后都是磁盘IO
2) 文件于数据库分开才方便备份
3) 方便分布部署
4) 方便CDN

各种方便

楼上的方案都对,我有一些自己的理解
1、数据库本身会成为瓶颈,所以啥都放进数据库是不对的。。。
2、分开放有利于文件访问优化,有可能会快过数据库

都是就事论事。没有谈到什么样的规模适合什么样的解决方案。

如果是小型应用,单机或者一个机房里面的简单集群就顶的起的,目录好。简单方便。但是程序代码要处理好目录路径的问题,机器出现故障,要恢复,那是个灾难。路径绝对不能错。

如果是超级大型应用,比如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的)。

你知道吗?

宣传栏