一个关于数据库存储大量文件的问题 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
vegforlive
V2EX    程序员

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

  •  
  •   vegforlive 2022-11-02 10:40:25 +08:00 3274 次点击
    这是一个创建于 1098 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    现在想到的办法:

    1. 将文件的路径存到数据库里,但是文件的路径经常改变,感觉不太方便
    2. 将文件本体存放到数据库里,但是这样数据库就会很大,可能有几个 T 不知道会不会崩
    16 条回复    2022-11-02 20:02:01 +08:00
    likeme
        1
    likeme  
       2022-11-02 10:44:24 +08:00
    可以自己搭建一个文件服务器吧。。。
    txzhanghuan
        2
    txzhanghuan  
       2022-11-02 10:48:20 +08:00
    为啥要经常移动?
    mrli2012
        3
    mrli2012  
       2022-11-02 10:49:09 +08:00
    能描述下是什么文件吗?为什么需要经常移动和修改?
    tool2d
        4
    tool2d  
       2022-11-02 10:50:22 +08:00
    如果我是你,就只在数据库存文件 hash 。一般数据库资料都需要尽可能定期自动化双备份,以防硬盘损坏。

    再写一个自用的文件访问模块,采用 everything 的 NTFS 目录快速读取。你磁盘文件路径会变,文件名称 /大小 /日期 /hash 这些都是固定不变的,还是比较容易定位的。
    vegforlive
        5
    vegforlive  
    OP
       2022-11-02 10:50:34 +08:00
    @likeme 现在就是保存在文件服务器上,在文件服务器上对文件进行操作
    @txzhanghuan 因为要经常对这些数据进行修改处理,处理完之后可能要重命名之类的,现在公司没有啥规范
    rekulas
        6
    rekulas  
       2022-11-02 10:52:42 +08:00
    几个 t 而已,对有些数据库来说毫无压力,比如 rocksdb leveldb
    不过放数据库管理没那么方便 建议还是用专业的文件服务器,有开源的
    jhatfdu2
        7
    yjhatfdu2  
       2022-11-02 11:07:22 +08:00   1
    建议使用对象存储,比如 minio 之类的
    lookStupiToForce
        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/)
    ggvm
        9
    ggvm  
       2022-11-02 12:58:19 +08:00
    2 文本放进数据肯定是个馊主意,这样备份数据库成为了不可能。

    思路应该是延续方案 1 ,文件路径变化之后,更新一下原来的数据,写好变更流水日志备查即可。
    littlewing
        10
    littlewing  
       2022-11-02 13:15:16 +08:00
    不要性能随你怎么放啊,能用就行
    clorischan
        11
    clorischan  
       2022-11-02 13:23:53 +08:00
    文件系统本身就是一种数据库, 其物理存储结构基于磁盘扇区的
    专优化于文件存储的 Key(Path) / Value(File)数据库

    除非存储系统这一块的业务因为一些原因不便调整
    不然在文件系统上再套娃一个数据库感觉意义不大
    eason1874
        12
    eason1874  
       2022-11-02 13:24:11 +08:00   1
    这不就是最常见的内容附件么

    做个媒体库管理页面,文件存储还是放目录,上传后自动生成 UUID 作为实际存储文件,同步往媒体数据库写入一条附件信息,path 是实际存储路径(固定,不可修改),然后存个 rewrite uri 作为友好访问路径(可修改,访问时重写或者跳转到真实路径),还有 filename 、mtime 、description 、tag 这些属性信息(可修改,建索引,可查询)
    S2Line
        13
    S2Line  
       2022-11-02 15:51:02 +08:00
    用对象存储不就完事了吗
    sshang
        14
    sshang  
       2022-11-02 15:52:29 +08:00
    对象存储 + 适合的元数据管理工具
    dx3759
        15
    dx3759  
       2022-11-02 18:46:43 +08:00
    对象存储+元数据管理
    adoal
        16
    adoal  
       2022-11-02 20:02:01 +08:00
    可能你最迫切需要解决的是为啥要在服务器的文件系统里任性整理文件的问题,这个是业务层面的根源。
    而不是挑选技术方案。

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

    当然,用文件系统,总有人会忍不住“既然放在文件系统里,我能看到,能操作,那我手痒直接去整理总不会犯啥大错吧”……所以换对象存储也好
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     1507 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 27ms UTC 16:38 PVG 00:38 LAX 08:38 JFK 11:38
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86