请教下 v 站各位大佬一个关于删除二进制文件中一部分数据的问题(能不能行都不知道) - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
AboPlus
V2EX    程序员

请教下 v 站各位大佬一个关于删除二进制文件中一部分数据的问题(能不能行都不知道)

  •  
  •   AboPlus 2023-11-15 09:13:22 +08:00 2447 次点击
    这是一个创建于 747 天前的主题,其中的信息可能已经有所发展或是发生改变。

    现在的场景是,在创建完对象后会产生一个二进制文件,相当于有多少对象就会有多少个二进制文件,二进制文件存储在云端,前端要根据这个二进制文件来进行模型的渲染,在删除对象的时候,会把云端的二进制文件同步进行删除,同时释放用户的存储空间。

    现在是如果对象比较多的情况下,比如有一千个对象,那么相当于云端存储着一千个这样的二进制文件,那么从前端向云端对象存储获取数据的话相当于需要获取一千次才能拿到完整的数据,前端同事觉得请求会特别多。

    然后领导就提了个这样的需求,他希望把所有对象产生的二进制文件放在一个二进制文件中,这个情况如果不涉及到删除倒还好说,但是涉及到删除的话,应该是没有办法删除二进制文件中的一个片段吧?包括后续继续创建对象,要把这个对象产生的数据追加到这个总的二进制文件中,那么在删除某个对象的时候岂不是要是别出这个对象在这个总的二进制文件中的位置,然后重写一份总的二进制文件把除了那个要删除的对象以外的所有数据都写进来,同时每个对象还需要一些额外的属性用来标识它们在二进制文件中的位置,在产生新的文件后,还要把后续所有对象的这个属性都修改为新的位置。如果被删除的对象所处位置在总二进制文件的前面,那相当于对几乎所有对象都要进行修改。

    我目前觉得这个需求有点难搞,从我的视角来看,带来的问题远比能解决的问题多得多,甚至并不能解决原有的问题,对此想请教下各位大佬,对于这种情况各位有什么看法,可以分别从前端视角和后端视角给一些看法和建议。

    27 条回复    2023-11-15 14:09:07 +08:00
    NessajCN
        1
    NessajCN  
       2023-11-15 09:19:24 +08:00
    你得先说一下用什么库或方法创建的这些文件
    Nitroethane
        2
    Nitroethane  
       2023-11-15 09:25:54 +08:00   1
    感觉你这个是伪需求啊?「现在是如果对象比较多的情况下,比如有一千个对象,那么相当于云端存储着一千个这样的二进制文件,那么从前端向云端对象存储获取数据的话相当于需要获取一千次才能拿到完整的数据,前端同事觉得请求会特别多」:把你的接口改造成允许一个请求获取多个二进制文件呢?比如你的接口里 file_id 指定要下载的二进制文件的 ID ,把 file_id 改成数组类型,即一次可以指定多个文件 ID ,这样就可以实现批量下载,而且请求也不会很多。
    ktqFDx9m2Bvfq3y4
        3
    ktqFDx9m2Bvfq3y4  
       2023-11-15 09:29:26 +08:00
    把所有对象产生的二进制文件放在一个二进制文件中。

    Sqlite ?
    paopjian
        4
    paopjian  
       2023-11-15 09:38:28 +08:00   1
    还奇怪的需求啊,为什么要请求一千次,打包一次返回来不就好了?而且你们也太耿直了,点删除就删除文件了?有要求把所有数据保存半年的.
    cxtrinityy
        5
    cxtrinityy  
       2023-11-15 09:40:40 +08:00 via Android
    关键是解决根本问题前端觉得请求过多,以前写过上传的代码,用 multipart/form-data 一次性上传多个文件,搜了下,multipart/related 好像能实现对应的一次性下载多个文件。

    PS:当时用 httpurlconnection ,手撸的这个请求的 http 头和内容,感觉自由性挺高,应该不是特别难实现
    tool2d
        6
    tool2d  
       2023-11-15 09:41:15 +08:00   1
    如果我是你,会另外写一个服务器大文件缓存通道,1000 个文件根据 hash 特性,合并成几个文件后给前端下载。

    删除还是走原来的逻辑,不去动。
    seers
        7
    seers  
       2023-11-15 09:47:41 +08:00 via Android
    oss 提供打包下载功能啊,你云端生成完了打包一个下过来
    AboPlus
        8
    AboPlus  
    OP
       2023-11-15 10:17:57 +08:00
    @NessajCN 这些文件是算法端产生的,后端实际上只做这些文件的管理,包括云端的管理这些
    AboPlus
        9
    AboPlus  
    OP
       2023-11-15 10:21:31 +08:00
    @Nitroethane 目前前端是直接发请求到存储桶拿数据,目前没有经过后端服务,我考虑下走接口
    AboPlus
        10
    AboPlus  
    OP
       2023-11-15 10:25:38 +08:00
    @paopjian !!!好的大哥,我们这边后端就四个人,目前没有大佬,好多想法思考的都不太成熟,好多好的方案都是从 V 站上请教来的
    AboPlus
        11
    AboPlus  
    OP
       2023-11-15 10:55:25 +08:00
    @tool2d 大佬请教下,合并后的文件涉及到删除的时候不还是需要对合并后的文件进行处理吗,把被删除的数据移除掉
    paopjian
        12
    paopjian  
       2023-11-15 11:06:55 +08:00   1
    前端对于大量小图标有雪碧图 处理,图片合到一个大图片里, 你们可以有一个后台代码逻辑把常用的文件打包到一起,如果前端有删除操作,那先在前端略过处理,服务器再定期重新打包.
    用户的存储使用容量不应该是和文件大小强绑定的,而应该是和逻辑绑定,并且允许一定超量
    jones2000
        13
    jones2000  
       2023-11-15 11:08:42 +08:00   1
    参考 sqlite , 所有数据都是存一个文件里面。
    sofukwird
        14
    sofukwird  
       2023-11-15 11:12:41 +08:00 via Android
    文件索引保存在数据库里,然后只给前端返回文件索引
    你这是个 xy 问题,最好把实际需求说出来
    sofukwird
        15
    sofukwird  
       2023-11-15 11:16:13 +08:00 via Android   1
    看漏了,原来是模型文件,打包到一个文件里是正确的需求
    增删改的时候重新生成一个文件就好
    sofukwird
        16
    sofukwird  
       2023-11-15 11:17:20 +08:00 via Android
    二进制文件就用压缩包,压缩包是可以删除文件的
    tool2d
        17
    tool2d  
       2023-11-15 11:28:10 +08:00
    md5("filename1.bin + filename2.bin + filename3.bin") = e676e2aa0a8ebd318835b01ee4b5d21e.bin
    md5("filename1.bin + filename3.bin") = b02959106f2595f908b13eacf582ebab.bin

    "大佬请教下,合并后的文件涉及到删除的时候不还是需要对合并后的文件进行处理吗,把被删除的数据移除掉"

    我个人来说用 md5 作为合并文件名,就不涉及部分删除。因为只要小文件变动了,前端下载访问的 url 都不一样。

    如果大文件长时间没人访问,会自己清空数据。
    chnwillliu
        18
    chnwillliu  
       2023-11-15 11:28:54 +08:00 via Android
    好比一个 PSD 文件,里面包含多个图层,每个图层有自己的像素信息,前端增删改,保存后它就是一个 PSD 二进制文件啊。

    所以你只需要设计一个二进制文件格式,定义好结构
    InDom
        19
    InDom  
       2023-11-15 11:34:02 +08:00   1
    假设文件是 1...100 个文件,
    前端请求一个就是 file/1 如果获取特定 10 个文件,files/1,2,3,4,5,6,10,11,15,20...

    后段根据请求合并这些文件,作为一个返回给前端,如果会重复就以 hash 缓存
    chnwillliu
        20
    chnwillliu  
       2023-11-15 11:39:40 +08:00 via Android   1
    最简单的就是直接把包含所有模型的文件夹 zip 成一个文件,前端发一个请求然后用 in-memory 的 file system 直接 unzip 成 folder, 操作完了要写回去就再 zip 回去。

    不知道你这 1000 多个模型,一共有多大。
    0TSH60F7J2rVkg8t
        21
    0TSH60F7J2rVkg8t  
       2023-11-15 11:44:15 +08:00   1
    有云端对象存储,就不要合并一个 bin 文件啊,一个文件,你修改删除全是问题,怎么恢复合并又是问题。实际上,你只需要在数据库里保留所有二进制文件的云端位置,和文件信息,读取的时候从数据库拉,删除的时候,数据库软删除,前端不操作对象存储,服务器跑个定时任务,把软删除的数据库条目读出来,去云端对象存储里删除释放空间 就行了。
    okakuyang
        22
    okakuyang  
       2023-11-15 13:26:09 +08:00   1
    建议同一项目的模型文件用 zip 压缩成一个或者多个。

    估计你单个模型体积挺小的,这时候要考虑到云端存储规则有没有隐形一条,最小文件实体的大小。比如你单个文件体积小于 2.5MB ,但是云存储依旧按照 2.5MB 收费。

    如果没有立即删除文件的需求的可以只在数据库里标记删除。

    前端获取文件的时候用分片下载,虽然逻辑会写的麻烦一点,但是能够有效减少云存储的访问次数,可以省点钱。
    hanyu2pomelo
        23
    hanyu2pomelo  
       2023-11-15 13:28:56 +08:00
    用 mmap 可以解决吧
    AboPlus
        24
    AboPlus  
    OP
       2023-11-15 14:03:31 +08:00
    @sofukwird 直接操作压缩包,删除压缩包内的文件吗?好像是个好方法,那么剩下的就是解决如何处理云端压缩包中的文件的问题了!谢谢大佬!
    AboPlus
        25
    AboPlus  
    OP
       2023-11-15 14:05:51 +08:00
    @tool2d 意思是存在两份数据,一份数据是一个个的小文件,一份数据是将小文件合并后的大文件,是这个意思吗,然后任何一个小文件变动,都是需要重新 md5 出来一份新的大文件,是这样吗
    AboPlus
        26
    AboPlus  
    OP
       2023-11-15 14:07:59 +08:00
    @chnwillliu 数据量不太好估计,因为可能不止 1000 个模型
    aecra
        27
    aecra  
       2023-11-15 14:09:07 +08:00 via Android
    请求多没啥问题,开 HTTP2 就看带宽多大了,你这修改一下就改大文件是因为带宽比请求数量廉价吗?小文件还能使用缓存呢
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     3293 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 27ms UTC 00:39 PVG 08:39 LAX 16:39 JFK 19:39
    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