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

[myzincx]

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

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

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

[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 字节表示段数据大小，再扫描到\0 是该小文件的路径，其余是小文件数据，积累一定时间或数据量时新建一个大文件，然后调用一个外部程序按协议拆解前一个大文件，不知道这个方案是否可行

[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 做缓存，延后组成大文件落地。这样的话当其他项目要使用到其中的文件时，可以直接去数据库里查询到数据然后返回即可。

[oyasumi]

s3 挺合适的