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

[myzincx]

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

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

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

[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 大小

[libook]

可以尝试存在数据库里管理，比如 MongoDB 对于 16M 以上的文件可以用 GridFS，对于 16M 以下的可以用 BinData，自己没用过，感兴趣可以简单做一下压测。

https://docs.mongodb.com/manual/core/gridfs/