用 PostgreSQL 存图片等 binary 有什么坑吗

[liyafe1997]

如题，大概每个主条目下面关联有几张到一两百张不等的图片/文档之类的附件，每张图最大 500KB （入库时超大会自动压缩），文档也是不超过 500KB 。

目前测试数据（几十/百来个主条目）跑起来感觉挺香的，也没见什么性能问题。特别是设置好外键和 cascade delete 之后，主条目删除会自动把存 binary 的表中关联的附件一并干掉，比放文件系统好维护。文件系统还要自己处理数据关联和清理逻辑。

就是不知道以后数据量大了会有什么坑，预计之后主条目有数万个这样的量级。

[KongLiu]

数据库占用 IO 太高了，高并发就废了，而且以后配合 CDN 做加速也不方便，还有数据库存储一般都比对象云存储贵把

[wangtian2020]

我 sqlite 都不敢这么存

[liyafe1997]

@KongLiu 没有什么太高的并发需求，正常用户应该没考虑到高并发这个量级，但是怕的是 Internet 上乱跑的爬虫/搜索引擎 Bot 之类的。
「以后配合 CDN 做加速也不方便」，这个为什么呢？我还想着以后用 CDN 来帮缓存一些图，不用每次都进我的后端/数据库 IO 。

[zhengfan2016]

后面接手项目的开发：安卓架构(bushi

[JYii]

@liyafe1997 #3 你自己都说出隐患了，一个查询 api 就能把你 DB 打死。

[Vegetable]

IO 很难受，这么弄也很难做到正常文件服务器的能力，本来如空气一般自然的功能你都得自己实现，比如 http 304 。
你如果一开始选了这个架构，后边会越来越难受，只有一开始能爽点，与其后边难受，不如一开始做好资源管理，把删除的逻辑弄好。

[KongLiu]

@liyafe1997 用 OSS 配置一下就好了，你这种方式全靠自己控制。搞不到 OSS 配置本身就提供的功能，你自己要写一大堆

[liyafe1997]

@JYii 感觉在 HTTP Server 或者套一层 sqiud 做缓存能解决？甚至最外面还有一层 CDN 也能缓存？总之就是不用每次 HTTP GET 都去查 DB 。

[liyafe1997]

@KongLiu 那还得装一套 OSS

[xtreme1]

"条目"具体是什么东西?

[zephyru]

CDN 一般不都是通过图片的文件路径地址去访问的？
存文件系统里直接上传对应文件保持路径，项目里替换下请求的地址就好了。
你这种模式也并不是不能用 CDN 但确实不方便。
小文件存数据库主要问题还是开销大吧，基本没见过正经系统把文件直接存数据库里的。

[liyafe1997]

@xtreme1 你就理解成类似 V2EX 的帖子就好了，一条帖子下面可能挂有很多图片甚至文档等附件。

[AutumnVerse]

以前自己玩具项目这样搞过

就像楼上说的，数据库 io 扛不住，而且没法优化

[liyafe1997]

@zephyru CDN 请求我的 Server 也是 HTTP GET 哇，我的后端访问数据库中的图片也是 HTTP GET （ RESTful API ），查 db 再把图 binary data 通过 http response 弹回给你

[liyafe1997]

@AutumnVerse 现在想到的解决方案是在 HTTP Server 上做缓存，不知道加上这个之后，还有什么坑

[AutumnVerse]

正经做法是数据库存 oos 地址，后端返回 oos 地址，前端直接请求 oos ，这样减少服务端 io

[AutumnVerse]

@liyafe1997 缓存里面放图片？那你缓存的多大啊，你不怕缓存被撑爆吗

[liyafe1997]

@AutumnVerse 不想（懒得）再引入一套 OSS 了🤣

[AutumnVerse]

直接放磁盘路径都比放数据库好，直接放磁盘有一些文件系统，操作系统相关的优化方案，而且可以挂载远程磁盘的方式做分布式

[liyafe1997]

@AutumnVerse 直接放磁盘的话...我还是考虑 OSS 吧🤣
感谢解答