一个关于数据库存储大量文件的问题

[vegforlive]

各位大佬 有没有什么解决方案？

1. 现在已知有很多数据要保存，比如说上万个十几兆的文件
2. 这些文件现在保存在硬盘上。用目录的方式进行管理，但是这些文件经常的移动和修改，导致路径经常变化，管理很不方便
3. 现在想把这些文件保存到数据库里，方便管理和快速查询，有没有什么好办法

现在想到的办法：

1. 将文件的路径存到数据库里，但是文件的路径经常改变，感觉不太方便
2. 将文件本体存放到数据库里，但是这样数据库就会很大，可能有几个 T 不知道会不会崩

[likeme]

可以自己搭建一个文件服务器吧。。。

[txzhanghuan]

为啥要经常移动？

[mrli2012]

能描述下是什么文件吗？为什么需要经常移动和修改？

[tool2d]

如果我是你，就只在数据库存文件 hash 。一般数据库资料都需要尽可能定期自动化双备份，以防硬盘损坏。

再写一个自用的文件访问模块，采用 everything 的 NTFS 目录快速读取。你磁盘文件路径会变，文件名称 /大小 /日期 /hash 这些都是固定不变的，还是比较容易定位的。

[vegforlive]

@likeme 现在就是保存在文件服务器上，在文件服务器上对文件进行操作
@txzhanghuan 因为要经常对这些数据进行修改处理，处理完之后可能要重命名之类的，现在公司没有啥规范

[rekulas]

几个 t 而已，对有些数据库来说毫无压力，比如 rocksdb leveldb
不过放数据库管理没那么方便 建议还是用专业的文件服务器，有开源的

[yjhatfdu2]

建议使用对象存储，比如 minio 之类的

[lookStupiToForce]

mysql, pgsql 和 mongodb 其实都可以
逻辑上数据量也就几万行，完全无压力，真实数据文件是数据库自己管理的，肯定会分文件管理，只要你磁盘没崩数据基本不会崩，不过得注意定期清理收缩数据库

mysql 用 longblob
pgsql 用 bytea 或者 large objects ( https://stackoverflow.com/questions/4386030/how-to-use-blob-datatype-in-postgres)
mongodb 用 GridFS ( https://www.mongodb.com/docs/manual/core/gridfs/)

[ggvm]

2 文本放进数据肯定是个馊主意，这样备份数据库成为了不可能。

思路应该是延续方案 1 ，文件路径变化之后，更新一下原来的数据，写好变更流水日志备查即可。

[littlewing]

不要性能随你怎么放啊，能用就行

[clorischan]

文件系统本身就是一种数据库, 其物理存储结构基于磁盘扇区的
专优化于文件存储的 Key(Path) / Value(File)数据库

除非存储系统这一块的业务因为一些原因不便调整
不然在文件系统上再套娃一个数据库感觉意义不大

[eason1874]

这不就是最常见的内容附件么

做个媒体库管理页面，文件存储还是放目录，上传后自动生成 UUID 作为实际存储文件，同步往媒体数据库写入一条附件信息，path 是实际存储路径（固定，不可修改），然后存个 rewrite uri 作为友好访问路径（可修改，访问时重写或者跳转到真实路径），还有 filename 、mtime 、description 、tag 这些属性信息（可修改，建索引，可查询）

[S2Line]

用对象存储不就完事了吗

[sshang]

对象存储 + 适合的元数据管理工具

[dx3759]

对象存储+元数据管理

[adoal]

可能你最迫切需要解决的是为啥要在服务器的文件系统里任性整理文件的问题，这个是业务层面的根源。
而不是挑选技术方案。

假如说用了对象存储，甚至直接把附件存在数据库里，如果没有倒逼着优化和规范化业务规则，那还是要整理文件、改文件名、改文件的层次组织方式，只不过从文件系统里直接操作变成了通过业务管理系统去操作，那业务管理系统里要开发这一块的功能。但如果倒逼着优化和规范化了业务规则，管理系统配套了，即使仍然保存在文件系统上，也没问题了。

当然，用文件系统，总有人会忍不住“既然放在文件系统里，我能看到，能操作，那我手痒直接去整理总不会犯啥大错吧”……所以换对象存储也好😄