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

Question

图片不大于50kb

是存入数据库（mysql,nosql）性能好还是存入目录性能好

请说明原因

Answer 1

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

Answer 2

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

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

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

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

Answer 3

硬盘目录好

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

各种方便

Answer 4

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

Answer 5

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

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

如果是超级大型应用，比如google自己的服务要用到图片的，facebook的图片服务，分布式，全球多数据中心，你看你还怎么依靠操作系统的目录来管理？
这种情况下，必然是写自己的分布式文件系统，比如谷歌的Bigtable，也可以理解成nosql了。
Amazon的S3存储服务，是基于文档型数据库的，也是nosql。现在很多网站直接把自己的二进制数据放在S3，能够满足全球分布式管理，并且不用自己动手。

没有绝对的答案。还是那句话，看i的应用的规模，以及扩展性的需要。没有绝对的答案。

Answer 6

单纯比性能是nosql > mysql > 目录

但是 mysql只要稍微做点优化，应该就 mysql == nosql，即使nosql好，估计也只能好个常数而已。

因为 访问目录文件，是很慢的，他里面有自己的一套索引，这套索引访问估计不是hash，xp单个目录超过10,000个文件（个人经验，写了超多代码测试过），速度就迅速下降，window7性能良好，超过1,000,1000性能才会迅速下降，在100,000性能也很不错（结论来自carmack）。

linux性能不清楚，但是比xp快20倍以上（至少吧）。访问和写的速度。

上面都是个人经验。

Answer 7

关键看图片存储的规模及访问的规模。
不同的需求就会有不同的解决方案：
1）在小规模的图片存储和访问量的情况下，完全可以用单机的文件系统来解决这个需求，在Linux中有针对小文件存储的文件系统。
2）当图片的规模不能用单机的硬盘来存储了，就需要考虑分布式的存储方案了（Facebook就用Hbase来进行存储的，豆瓣采用自己开的BeansDB）。当然，如果有钱可以考虑买单独的存储设备（比如EMC的）。