未分類
17 9 月 2020

单机存储大量的小文件该如何选择？

单机存储大量的小文件该如何选择？

資深大佬 : myzincx 6

需求：一个小时大概有 180w 个不超过 10kb 的小文件要存储在单机设备上(只提供单机)，目前直接写文件会直接造成程序性能基本不可用

想法： 1.目前有想过的是打包成一个大文件直接建立自有索引，但是这么做的话程序需要改动很多(主要是其他部门的)，而且本部门人手有限，开发维护起来可能有困难。 2.也有查过一些文件存储框架，首先大部分框架是分布式的，我们只能提供单机，不知道这个会不会造成影响；其次，因为其他部门有个功能必须是对文件进行直接读取操作的(貌似 ceph 是可以当成一个挂载卷的这种，不太了解，如理解错误希望指出)，不能够通过网络 api 调用操作(如 seaweedfs)。

所以想请教下大家，有没有那种单机适合这种小文件大量读写的。 写多，读少，不删除。

大佬有話說 (39)

  • 資深大佬 : opengps

    单机的话，得规划下文件夹的创建，避免单个文件夹下太多文件导致的索引变慢
    另外如果 cpu 扛得住的话，可以考虑 base64 存数据库，合理设计表结构，比如分库分表配合

  • 主 資深大佬 : myzincx

    @opengps 创建文件夹可以考虑，数据存数据库就不太可了，其他项目组需要扫描原始文件使用。感谢回答

  • 資深大佬 : wzw

    Ssdb 加 python/go 写个接口

  • 資深大佬 : Mirana

    写多读少不删除 最好的 io pattern 是 append only 而且不需要 gc
    感觉 tfs 会好一点

  • 主 資深大佬 : myzincx

    @Mirana tfs 还有在维护吗？

  • 主 資深大佬 : myzincx

    @wzw 这种无法表现为数据卷的通过网路通信的不可用

  • 資深大佬 : drehere

    这个其实是跟 Linux 硬盘类型有关的，ext3 和 ext4 是不同的，主要要解决的就是 inode 的个数

  • 資深大佬 : gfreezy

    sqlite

  • 資深大佬 : zjyl1994

    搞一个 btrfs 格式的磁盘试试？

  • 資深大佬 : wangritian

    项目中写小文件的任务改成单文件追加，设计一个简单协议，对这个大文件分段，比如前 8 字节表示段数据大小，再扫描到 是该小文件的路径，其余是小文件数据，积累一定时间或数据量时新建一个大文件，然后调用一个外部程序按协议拆解前一个大文件，不知道这个方案是否可行

  • 資深大佬 : hakono

    虽然没用过，但也许可以考虑下无压缩 zip 。。。。
    记录下文件保存在哪个 zip 里就行了。。。。。

    不过无压缩 zip 适不适合 180w/h 写入就不知道了

  • 資深大佬 : 594duck

    leveldb 和 rocksdb 适合干这活，之前公司他们就是这么弄的。

    但是要知道这二个 DB 是写优化的，写起来异常的猛 ，但是读不行。

  • 資深大佬 : 594duck

    另外你一秒钟要写 5000 个文件，而且 IO 如此碎，一定要考虑 RAID10 了，RAID 卡的 Cache 一定要大，越大越好

  • 資深大佬 : MeteorCat

    单机存储小文件方案不清楚，但是缺点我遇到过一个，那就是 inode 利用达到 100 ％，直接使用 df -i 看到磁盘直接把 inode 爆了，这个是你使用单机存储大量文件必须要处理的问题

  • 資深大佬 : kuro1

    ipfs 单机开启 badgerds，本质是 db

  • 資深大佬 : kuro1

    关于第二点，可以使用 ipfs mount，关闭 gateway port

  • 資深大佬 : Mirana

    @594duck 主不删文件，所以 rocksdb 这种 需要做 merge 的 db，写放大贼高，不太合适

  • 主 資深大佬 : myzincx

    思考了一下，准备使用 fuse 在外面写一层接口，主要是实现 open write read 之类的必须函数，然后通过函数在内部调用其他数据库，实现对上层应用的透明，不知道大家认为可行否？

  • 主 資深大佬 : myzincx

    其他数据库的话找个高吞吐量的就行，也可以用 Redis 做缓存，延后组成大文件落地。这样的话当其他项目要使用到其中的文件时，可以直接去数据库里查询到数据然后返回即可。

  • 資深大佬 : jiangwenwenmodes

    s3 挺合适的

  • 資深大佬 : xupefei

    ZFS 应该可以解决问题，

  • 資深大佬 : livepps

    dropbox 好像是文件都做成 4m 的块，大的切割成 4m，小的多个拼接成 4m，然后维护索引

  • 資深大佬 : livepps

    小文件太多，直接存硬盘，还是考虑拼接成大文件存储比较好，碎片也少。
    读取的时候分步：
    1. 其他文件读取文件的接口做个封装
    2. 每次调用，根据索引和文件长度，从 4m 快里面提取出数据拼接，创建临时文件。
    3. 然后再读取上面创建的临时文件。

  • 資深大佬 : fancyhan

    每秒大概 1500iops，你的后端撑不住么？还是没有固态硬盘

  • 資深大佬 : crclz

    数据库是最优解

  • 資深大佬 : black11black

    感觉你这个需求，因为是小文件，直接存 sql 里就行了吧。比如用 LOB 存二进制。

    因为感觉上只有两个需求，一个是存储，另一个是根据名称读取，似乎 sql 很完美

  • 資深大佬 : love

    @MeteorCat 有些文件系统无限 inode 的，比如 reiserfs，用 ext 存小文件是不行

  • 資深大佬 : Mithril

    直接内存映射开个大文件，然后自己往里面写小文件并且建立索引。具体实现方法随便参考个文件系统就行。
    主要是避免让操作系统去干这个事。小文件量大了 inode 不够用，大概率你得去搞不同的文件系统，迁移性很成问题。按你这个单机的需求八成软件是要安装在客户那里的，让人家去换个 OS 和 FS 不太现实。你可以参考下 FaceBook 的 Haystack，或者其 Go 的实现 weed-fs 。
    Ceph 维护是个大坑，单机你就还是不要碰了。

  • 資深大佬 : Thiece

    InfluxDB ？

  • 資深大佬 : optional

    minio s3fs 挂载到本地

  • 資深大佬 : zengming00

    存数据库是对的

  • 資深大佬 : listenerri

    好像有大厂自己实现的专门存储小文件的文件系统

  • 資深大佬 : ruanimal

    leveldb + ssd 吧

  • 資深大佬 : gotonull

    我们公司用的 rocksdb

  • 資深大佬 : firstfire

    只要 10KB 大小的话，MongoDB 也可以存，还可以顺带的存储文件的元数据信息

  • 資深大佬 : purplewall

    这些数据好像才 18GB，要不试试看挂载 ramfs 直接写到内存里，或者直接映射一块足够大的内存。

  • 資深大佬 : ungrown

    你说的自定义 FUSE 思路可行，功能是简单的，但开发调试过程一定是痛苦的，这个没辙。
    所以在此之前，强烈建议你再试一些已经存在的工具、方法：
    ZFS 绝对值得一试，“终极文件系统”真不是凭空吹的牛逼；
    大量小文件打包成一个大文件的思路也值得一试，这事其实很多游戏都在干，就我自己玩过的，魔兽 3 、dota2，都如此。

  • 資深大佬 : jones2000

    Hadoop + Hbase

  • 資深大佬 : devinmagic

    @MeteorCat 可以在格式化的使用-N 参数设置 inode 大小