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

@sagnitude #79 那估计你是没做过百度，高德的这种地图服务，如果他们用的是你这种模式当我没说就好

@thealert 你也知道他们是面对十几亿人的服务，我可没说我这套服务可以无缝 scale 到全国十几亿客户端，我只是告诉楼主，至少在他的公司做到百度高德的级别之前，他这样做没问题

我发现我的某个项目和楼主的应用场景很像，但是我用的 MySQL 。我是用 blob 存储二进制数据，这个二进制数据就是用户在前端手写签名后，把签名图片转成二进制存在一个独立的中间表。
为啥这么做？离线部署的业务，服务器环境不可靠，所有数据能存数据库就存数据库，出问题了检查数据库数据就可以了，防止背锅。

@sagnitude #82 好的兄弟，明白

搭建个本地对象存储存图片，数据库存 id 即可；嫌麻烦直接本地建多级目录存储，数据库存路径；

用就是了，io 不是问题，PostgreSQL 就是吊，一把梭。

@adoal 正解，我的心态就是如此

刚毕业第一份工作用 mongo 干过，唯一遇到的坑是 mongo 当时不支持几十 MB 的文件。本来想修，结果当时带头人直接怼了用户不让存大文件。后来也有新同事说改对象存储更正规些，也被带头人怼回去了哈哈。讲究一个不到万不得已不优化。

GIS 相关+1 @sagnitude #35 是正解
小碎档太多了, 不是塞 db 就是塞 zip 这类的东西聚合成较大的档案来储存跟交换
尤其是 3D 相关的, 一个图层只包含小小一个区域随便就 700 多 M(700 多 x 百万)个档案, 至少我司这边的资料大多都是
一般常用 WMTS 图砖也不少, 能算出多少数量
例如 level 8 这层, 全球范围就是 4^8 = 65536 个档案
然后一般提供的 level 都是 0 到 18~22 左右
也就是 4^0 + 4^1 + 4^2 +....+4^22 个档案...
各位可以自行算一下(狗头

数据库有 acid 保证带来额外开销。
此外如果文件只有很小的修改，对于数据库来说也会全量更新。