• 请不要在回答技术问题时复制粘贴 AI 生成的内容
hardwork
V2EX  ›  程序员

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

  •  
  •   hardwork · Jun 3, 2019 · 5406 views
    This topic created in 2717 days ago, the information mentioned may be changed or developed.

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

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

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

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

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

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

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