转载

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

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

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

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

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

对运维工程师而言，存入目录有利于运维、备份、反向代理缓存等等，比存在DB里面方便很多都是就事论事。没有谈到什么样的规模适合什么样的解决方案。

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

如果是超级大型应用，比如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的）。硬盘目录好

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

各种方便

个人理解 1、数据库本身会成为瓶颈，所以啥都放进数据库是不对的。。。 2、分开放有利于文件访问优化，有可能会快过数据库

正文到此结束