V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
hardwork
V2EX  ›  程序员

几百万张缩略图硬盘存储方案?

  •  
  •   hardwork · 2019-06-03 18:06:47 +08:00 · 4281 次点击
    这是一个创建于 2030 天前的主题,其中的信息可能已经有所发展或是发生改变。

    怎么存储才能较高效读写,每张图片也就几 k 到几十 k,之前存在一个文件夹下,inode 太大,rm -rf 都要删很久很久,就像卡死了一样.

    c++的小服务,有什么存储库可用吗,或者如何分散合并到硬盘?

    30 条回复    2019-06-04 15:05:27 +08:00
    keepeye
        1
    keepeye  
       2019-06-03 18:15:20 +08:00
    上 hdfs 之类的文件系统?小文件合并存储,当然读取的话要走接口了
    also24
        2
    also24  
       2019-06-03 18:17:32 +08:00
    噗嗤,之前存过几十万张,每张 0.5~1MB 左右的,即使丢进 SSD,读写的时候还是想死,关注一下大家有什么好方案
    hardwork
        3
    hardwork  
    OP
       2019-06-03 18:17:38 +08:00
    @keepeye 只是个小服务,而且这个量级好像也没必要使用第三方云服务,linux 自带文件系统搞定搞定最好
    aquariumm
        4
    aquariumm  
       2019-06-03 18:18:08 +08:00 via Android
    最方便的就是生成然后上传到 oss
    Jirajine
        5
    Jirajine  
       2019-06-03 18:18:21 +08:00 via Android
    用私有格式直接合并存储合并读写
    andyzhshg
        6
    andyzhshg  
       2019-06-03 18:18:53 +08:00
    leveldb 之类的 kv 应该可以吧?
    keepeye
        7
    keepeye  
       2019-06-03 18:24:44 +08:00
    要不 直接丢到 mongodb 里?
    Livid
        8
    Livid  
    MOD
       2019-06-03 18:25:32 +08:00 via iPhone   ❤️ 3
    早点习惯用云解决这类问题,就可以早点从这类问题背后的性能、备份、CDN 等等更细节的问题里解脱出来。
    goreliu
        9
    goreliu  
       2019-06-03 18:25:35 +08:00 via Android
    这个还要看具体是怎么读写的。比如读、新增、删除文件都是什么频率的。

    如果图片的大小相差不大,可以这样简单实现。把图片按大小分成几类,比如小于 10k、10k - 30k、30k、50k 等等。然后为每类图片分配一个大文件和索引文件。像 10k 文件按 10k 的块来使用,在索引文件记录文件名和对应文件偏移。

    这样虽然会浪费一些空间。但写入读取(因为省去打开关闭过程,比单文件读要快)、删除(只需要写索引文件)图片都非常快。

    如果不想费事,可以找个 kv 数据库,但性能会差些。
    swulling
        10
    swulling  
       2019-06-03 18:30:23 +08:00 via iPhone
    本地的话建议用 LevelDB 或者 rocksdb 这种本地 kv 存储
    Klingon
        11
    Klingon  
       2019-06-03 18:32:06 +08:00
    图片量不小了。可以用阿里云腾讯云,不放心的话可以用 minio 搭建个私有存储。
    dsnake1984
        12
    dsnake1984  
       2019-06-03 18:33:31 +08:00
    腾讯 cos 便宜好用~ 不烦神。
    cy97cool
        13
    cy97cool  
       2019-06-03 18:36:16 +08:00 via Android
    seaweedfs
    snappyone
        14
    snappyone  
       2019-06-03 18:42:04 +08:00 via Android   ❤️ 1
    一定自己存的话肯定不能丢一个文件夹,文件名 hash 之后取 hash 前缀分文件夹存试试
    xuddk727
        15
    xuddk727  
       2019-06-03 18:47:34 +08:00
    了解一下 mr4c, google earth engine?
    aec4d
        16
    aec4d  
       2019-06-03 20:26:34 +08:00
    直接用 ext4 存了千万级缩略图的表示,没什么性能问题,跑的很欢,不需要特别做优化
    原图是存在了 S3 上,本地缩略图再不济可以获得原图再生成一次缩略图

    https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
    opengps
        17
    opengps  
       2019-06-03 20:31:02 +08:00 via Android
    必须用单机环境的话,你得知道目录下最多 500 张
    justou
        18
    justou  
       2019-06-03 20:40:35 +08:00
    HDF5 可以了解一下
    https://www.hdfgroup.org/
    dog
        19
    dog  
       2019-06-03 20:53:50 +08:00 via iPhone
    @opengps 为啥最多 500 张?
    winglight2016
        20
    winglight2016  
       2019-06-03 20:55:28 +08:00
    百万级的文件,单机不好搞了吧,不想上专门的文件系统,也可以导入 RMDB 里面
    loading
        21
    loading  
       2019-06-03 20:57:42 +08:00 via Android
    minio
    可以做分布式了,都说是开源的 aws s3
    luozic
        22
    luozic  
       2019-06-03 21:14:30 +08:00 via iPhone
    小图 不上 DB 那种存文件的,读取不是想死?
    opengps
        23
    opengps  
       2019-06-03 21:14:34 +08:00 via Android
    @dog 只是个概念,单个文件夹之下的数量不宜过多
    wbrobot
        24
    wbrobot  
       2019-06-03 21:25:50 +08:00
    豆瓣是自己造轮子解决的:beansdb
    zzl22100048
        25
    zzl22100048  
       2019-06-04 10:00:05 +08:00   ❤️ 1
    两个亿的图片怎么比较好?频繁读,少量写
    FrankHB
        26
    FrankHB  
       2019-06-04 13:55:02 +08:00
    @Livid 单机呢?
    然后不管多出来的网络成本,确定把问题转换为风险管控和砍价上兜得住么。
    二次开发成本呢?
    (怕是要和抠脚皮大汉打一架:Who does that server really serve?)
    我现在要在本机索引万以上的大小 1M 左右的截图,要求能任意两图之间快速预览加注标签近似比较自动去重,持久存储效率平均不低于 FLIF 的 30%;暂且先不管价钱,有什么 IaaS 方案能救吗?
    tenwx
        27
    tenwx  
       2019-06-04 14:03:27 +08:00
    @FrankHB zfs 可以做到自动去重,但可能有点耗内存
    FrankHB
        28
    FrankHB  
       2019-06-04 14:19:12 +08:00
    @tenwx 不是基于直接二进制比较或者 hash 的去重,跟内容特征相关,基本上肯定是要二次开发的。
    不过这个是没支持手动标注分类的优先级高……考虑到我的输入数据中大部分特征相似分类也不太复杂,但是各种奇形怪状,不容易自动提取,短时间内弃疗了,实在不行等标记完一并手动凑数吧。
    个别情况有损压缩和无损图源会在同一个地方倒是适合自动,不过数量不多也算了……
    yanzixuan
        29
    yanzixuan  
       2019-06-04 15:02:04 +08:00
    @keepeye hbase 吧。还挺好用的。
    yanzixuan
        30
    yanzixuan  
       2019-06-04 15:05:27 +08:00
    @winglight2016 riak 吧。分布式的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3390 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 11:37 · PVG 19:37 · LAX 03:37 · JFK 06:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.