各位大佬 有没有什么解决方案?
现在想到的办法:
1
likeme 2022-11-02 10:44:24 +08:00
可以自己搭建一个文件服务器吧。。。
|
2
txzhanghuan 2022-11-02 10:48:20 +08:00
为啥要经常移动?
|
3
mrli2012 2022-11-02 10:49:09 +08:00
能描述下是什么文件吗?为什么需要经常移动和修改?
|
4
tool2d 2022-11-02 10:50:22 +08:00
如果我是你,就只在数据库存文件 hash 。一般数据库资料都需要尽可能定期自动化双备份,以防硬盘损坏。
再写一个自用的文件访问模块,采用 everything 的 NTFS 目录快速读取。你磁盘文件路径会变,文件名称 /大小 /日期 /hash 这些都是固定不变的,还是比较容易定位的。 |
5
vegforlive OP |
6
rekulas 2022-11-02 10:52:42 +08:00
几个 t 而已,对有些数据库来说毫无压力,比如 rocksdb leveldb
不过放数据库管理没那么方便 建议还是用专业的文件服务器,有开源的 |
7
yjhatfdu2 2022-11-02 11:07:22 +08:00 1
建议使用对象存储,比如 minio 之类的
|
8
lookStupiToForce 2022-11-02 11:36:39 +08:00
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/) |
9
ggvm 2022-11-02 12:58:19 +08:00
2 文本放进数据肯定是个馊主意,这样备份数据库成为了不可能。
思路应该是延续方案 1 ,文件路径变化之后,更新一下原来的数据,写好变更流水日志备查即可。 |
10
littlewing 2022-11-02 13:15:16 +08:00
不要性能随你怎么放啊,能用就行
|
11
clorischan 2022-11-02 13:23:53 +08:00
文件系统本身就是一种数据库, 其物理存储结构基于磁盘扇区的
专优化于文件存储的 Key(Path) / Value(File)数据库 除非存储系统这一块的业务因为一些原因不便调整 不然在文件系统上再套娃一个数据库感觉意义不大 |
12
eason1874 2022-11-02 13:24:11 +08:00 1
这不就是最常见的内容附件么
做个媒体库管理页面,文件存储还是放目录,上传后自动生成 UUID 作为实际存储文件,同步往媒体数据库写入一条附件信息,path 是实际存储路径(固定,不可修改),然后存个 rewrite uri 作为友好访问路径(可修改,访问时重写或者跳转到真实路径),还有 filename 、mtime 、description 、tag 这些属性信息(可修改,建索引,可查询) |
13
S2Line 2022-11-02 15:51:02 +08:00
用对象存储不就完事了吗
|
14
sshang 2022-11-02 15:52:29 +08:00
对象存储 + 适合的元数据管理工具
|
15
dx3759 2022-11-02 18:46:43 +08:00
对象存储+元数据管理
|
16
adoal 2022-11-02 20:02:01 +08:00
可能你最迫切需要解决的是为啥要在服务器的文件系统里任性整理文件的问题,这个是业务层面的根源。
而不是挑选技术方案。 假如说用了对象存储,甚至直接把附件存在数据库里,如果没有倒逼着优化和规范化业务规则,那还是要整理文件、改文件名、改文件的层次组织方式,只不过从文件系统里直接操作变成了通过业务管理系统去操作,那业务管理系统里要开发这一块的功能。但如果倒逼着优化和规范化了业务规则,管理系统配套了,即使仍然保存在文件系统上,也没问题了。 当然,用文件系统,总有人会忍不住“既然放在文件系统里,我能看到,能操作,那我手痒直接去整理总不会犯啥大错吧”……所以换对象存储也好😄 |