数据库-对于小的图片(<20k)文件用数据库存储与用文件存储的优缺点?

数据库-对于小的图片(<20k)文件用数据库存储与用文件存储的优缺点?

泛泛之交 发布于 2017-05-11 字数 0 浏览 1216 回复 5

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

甜柠檬 2017-10-01 5 楼

小图片的话
数据库存储:
1.读、写方便些
2.不方便把图片批量导出
3.请求量大的话,并发是个问题,数据库压力,WEB太力都会大,因为是实时查库,实时header图片

文件存储:
1.存储要散列,一个目录下不能放太多文件
2.在数据库中要记录图片散列地址
3.好处是可以直接把整个图片目录同步到静态服或CDN。且可以打包下载
4.可以分布式存放
5.高请求服务器压力小

WEB应用我觉得一般情况下都不建议使用数据库存储。
客户端独立应用的话我觉得为了安全可以存在本地数据库里。

偏爱自由 2017-09-27 4 楼

小图片存储:
数据库:
1.数据读取稳定,写入方便。
2.输出到页面成功率高,基本不会有文件损坏只能读取一部分的情况。
3.不方便分布及同步。
4.重复数据无法剔除。
5.无法利用浏览器多个域名多线程特性,性能会成为问题。
6.修改量大会使得数据库碎片上升,性能下降。

文件系统:
1.需要有算法保持目录文件中的数量。
2.可以使用文件系统缓存和Squid等缓存。
4.可以给相同的图片用硬链接减少重复文件数目。
5.易分布,也可根据需要同步部分数据。
6.解决方案多。
7.可能因硬件或网络异常而造成的图片文件损坏。
8.对文件系统或存储方案有一定的要求

归属感 2017-08-27 3 楼

即使只有20K的头像文件,大量的话,对于数据库来说也是巨大的压力,毕竟这种二进制的文件没有必要存在数据库,而且存在数据库中的话,无法直观的预览查看文件。
数据库存储的话,我感觉优点有
1、方便备份,直接在数据库中了,作为一个字段。
2、程序简单,直接作为一个字段,也不用存储存放位置等信息,程序写起来应该比较节约脑细胞的样子,用户少的话还是挺不错滴选择~~ 【囧 我想不出其他的了】
文件的话:
1、可以存储在更多地方,比如分布式存储。
2、从数据库查出保存位置,直接引用的话速度应该会比从数据库读出来的时候小。
3、对内存占用应该明显的小,毕竟数据库到应用之间需要传送。
4、更好的预览和修改,以及对照片进行处理~~

主要看用户量的,如果用户量小的话,个人还是比较倾向于使用数据库存储的,方便~~

甜柠檬 2017-08-22 2 楼

不知道你说的数据库是否指关系数据库。用关系数据库存储的话,文件读和写都要经过SQL引擎,效率一定是比较差的,但是程序写起来会比较简单,数据一致性好。数据量和访问量都不大的情况下可以用。

用文件系统存的话,效率肯定要好得多,现在的文件系统对小文件的处理比以前好很多了。但如果是海量的小文件,那么文件的散列存储以及备份什么的都是很恶心的事情。另外通常文件要以某种关系(比如用户ID,类别)来组织展示,key一般也还是要放在关系数据库里的,而文件实体却放在文件系统上,数据一致性不太好维护。

用哪种方式还是得综合看应用的数据量和访问量,如果都很大,就用key-value数据库或者分布式存储解决方案吧。

浮生未歇 2017-05-21 1 楼

优点:
1,维护方便,备份、恢复只需要对付数据库即可。备份恢复虽然有些耗时,但我不用担心自己在文件系统上还拉了什么东西,非常方便;
2,文件元数据检索速度快,如果你需要列出所有文件名,数据库肯定比文件系统快;
3,发展方向,其实现在有postgresqlFS,是linux的一个用户层的文件系统扩展,和M$的winFS概念类似,整个文件系统就是一个数据库;
4,一定范围内,性能可以提高,尤其是大并发的范围,比文件系统性能好;
5,应用扩展更容易,因为程序处理的时候省缺了一系列FILE *的操作,数据库有现成的接口(还有处理片断的东西)。
缺点:
1,另外一些范围内性能会变差些,比如单用户大量文件的拷贝,差距大概在10%左右;
2,数据库大小增长比较明显,并且目前没有很好的扩展方式;文件系统可以利用NFS、NAS、SAN等方式扩展,而postgresql目前还是建议用RAID。不过这一点将来肯定会得到改进。
laser估计:在100T以下的库(文档、图片),还是用数据库存储好,超过100T(比如存储监控视频流),可能文件系统更好些)。