这是一个创建于 1564 天前的主题，其中的信息可能已经有所发展或是发生改变。
需求：一个小时大概有 180w 个不超过 10kb 的小文件要存储在单机设备上(只提供单机)，目前直接写文件会直接造成程序性能基本不可用
想法： 1.目前有想过的是打包成一个大文件直接建立自有索引，但是这么做的话程序需要改动很多(主要是其他部门的)，而且本部门人手有限，开发维护起来可能有困难。 2.也有查过一些文件存储框架，首先大部分框架是分布式的，我们只能提供单机，不知道这个会不会造成影响；其次，因为其他部门有个功能必须是对文件进行直接读取操作的(貌似 ceph 是可以当成一个挂载卷的这种，不太了解，如理解错误希望指出)，不能够通过网络 api 调用操作(如 seaweedfs)。
所以想请教下大家，有没有那种单机适合这种小文件大量读写的。 写多，读少，不删除。
 |
1
opengps 2020-09-10 15:35:57 +08:00
单机的话，得规划下文件夹的创建，避免单个文件夹下太多文件导致的索引变慢
另外如果 cpu 扛得住的话，可以考虑 base64 存数据库，合理设计表结构，比如分库分表配合 |
 |
3
wzw 2020-09-10 15:39:31 +08:00 via iPhone
Ssdb 加 python/go 写个接口
|
 |
4
Mirana 2020-09-10 15:49:50 +08:00
写多读少不删除 最好的 io pattern 是 append only 而且不需要 gc
感觉 tfs 会好一点 |
 |
7
drehere 2020-09-10 16:03:35 +08:00
这个其实是跟 Linux 硬盘类型有关的，ext3 和 ext4 是不同的，主要要解决的就是 inode 的个数
|
 |
8
gfreezy 2020-09-10 16:04:12 +08:00
sqlite
|
 |
9
zjyl1994 2020-09-10 16:14:09 +08:00 via Android
搞一个 btrfs 格式的磁盘试试？
|
 |
10
wangritian 2020-09-10 16:34:54 +08:00
项目中写小文件的任务改成单文件追加，设计一个简单协议，对这个大文件分段，比如前 8 字节表示段数据大小，再扫描到\0 是该小文件的路径，其余是小文件数据，积累一定时间或数据量时新建一个大文件，然后调用一个外部程序按协议拆解前一个大文件，不知道这个方案是否可行
|
 |
11
hakono 2020-09-10 16:45:49 +08:00
虽然没用过，但也许可以考虑下无压缩 zip 。。。。
记录下文件保存在哪个 zip 里就行了。。。。。 不过无压缩 zip 适不适合 180w/h 写入就不知道了 |
 |
12
594duck 2020-09-10 17:33:46 +08:00
leveldb 和 rocksdb 适合干这活，之前公司他们就是这么弄的。
但是要知道这二个 DB 是写优化的，写起来异常的猛 ，但是读不行。 |
|
13
594duck 2020-09-10 17:35:53 +08:00
另外你一秒钟要写 5000 个文件，而且 IO 如此碎，一定要考虑 RAID10 了，RAID 卡的 Cache 一定要大，越大越好
|
 |
14
MeteorCat 2020-09-10 17:37:40 +08:00 via Android
单机存储小文件方案不清楚，但是缺点我遇到过一个，那就是 inode 利用达到 100 ％，直接使用 df -i 看到磁盘直接把 inode 爆了，这个是你使用单机存储大量文件必须要处理的问题
|
 |
15
kuro1 2020-09-10 17:43:00 +08:00
ipfs 单机开启 badgerds，本质是 db
|
|
16
kuro1 2020-09-10 17:45:21 +08:00
关于第二点，可以使用 ipfs mount，关闭 gateway port
|
 |
18
myzincx OP 思考了一下，准备使用 fuse 在外面写一层接口，主要是实现 open write read 之类的必须函数，然后通过函数在内部调用其他数据库，实现对上层应用的透明，不知道大家认为可行否？
|
|
19
myzincx OP 其他数据库的话找个高吞吐量的就行，也可以用 Redis 做缓存，延后组成大文件落地。这样的话当其他项目要使用到其中的文件时，可以直接去数据库里查询到数据然后返回即可。
|
 |
20
oyasumi 2020-09-10 19:36:11 +08:00 via Android
s3 挺合适的
|
 |
21
xupefei 2020-09-10 19:50:01 +08:00 via iPhone
ZFS 应该可以解决问题，
|
 |
22
livepps 2020-09-10 20:47:27 +08:00
dropbox 好像是文件都做成 4m 的块，大的切割成 4m，小的多个拼接成 4m，然后维护索引
|
|
23
livepps 2020-09-10 20:55:46 +08:00
小文件太多，直接存硬盘，还是考虑拼接成大文件存储比较好，碎片也少。
读取的时候分步： 1. 其他文件读取文件的接口做个封装 2. 每次调用，根据索引和文件长度，从 4m 快里面提取出数据拼接，创建临时文件。 3. 然后再读取上面创建的临时文件。 |
 |
24
fancyhan 2020-09-10 21:11:10 +08:00 via iPhone
每秒大概 1500iops，你的后端撑不住么？还是没有固态硬盘
|
 |
25
crclz 2020-09-10 23:20:04 +08:00
数据库是最优解
|
 |
26
black11black 2020-09-10 23:39:12 +08:00
感觉你这个需求，因为是小文件，直接存 sql 里就行了吧。比如用 LOB 存二进制。
因为感觉上只有两个需求，一个是存储，另一个是根据名称读取，似乎 sql 很完美 |
 |
27
love 2020-09-11 00:18:06 +08:00 via Android
@MeteorCat 有些文件系统无限 inode 的，比如 reiserfs，用 ext 存小文件是不行
|
 |
28
Mithril 2020-09-11 00:54:57 +08:00
直接内存映射开个大文件，然后自己往里面写小文件并且建立索引。具体实现方法随便参考个文件系统就行。
主要是避免让操作系统去干这个事。小文件量大了 inode 不够用，大概率你得去搞不同的文件系统，迁移性很成问题。按你这个单机的需求八成软件是要安装在客户那里的，让人家去换个 OS 和 FS 不太现实。你可以参考下 FaceBook 的 Haystack，或者其 Go 的实现 weed-fs 。 Ceph 维护是个大坑，单机你就还是不要碰了。 |
 |
29
Thiece 2020-09-11 04:35:21 +08:00
InfluxDB ？
|
 |
30
optional 2020-09-11 08:07:41 +08:00 via iPhone
minio s3fs 挂载到本地
|
 |
31
zengming00 2020-09-11 08:46:17 +08:00
存数据库是对的
|
 |
32
listenerri 2020-09-11 08:55:49 +08:00
好像有大厂自己实现的专门存储小文件的文件系统
|
 |
33
ruanimal 2020-09-11 09:37:43 +08:00
leveldb + ssd 吧
|
 |
34
gotonull 2020-09-11 11:29:25 +08:00
我们公司用的 rocksdb
|
 |
35
firstfire 2020-09-11 13:13:38 +08:00
只要 10KB 大小的话，MongoDB 也可以存，还可以顺带的存储文件的元数据信息
|
 |
36
purplewall 2020-09-11 19:23:49 +08:00
这些数据好像才 18GB，要不试试看挂载 ramfs 直接写到内存里，或者直接映射一块足够大的内存。
|
 |
37
ungrown 2020-09-12 15:19:26 +08:00
你说的自定义 FUSE 思路可行，功能是简单的，但开发调试过程一定是痛苦的，这个没辙。
所以在此之前，强烈建议你再试一些已经存在的工具、方法： ZFS 绝对值得一试，“终极文件系统”真不是凭空吹的牛逼； 大量小文件打包成一个大文件的思路也值得一试，这事其实很多游戏都在干，就我自己玩过的，魔兽 3 、dota2，都如此。 |
 |
38
jones2000 2020-09-12 22:06:22 +08:00
Hadoop + Hbase
|
 |
39
devinmagic 2020-09-13 11:24:18 +08:00
@MeteorCat 可以在格式化的使用-N 参数设置 inode 大小
|
 |
40
libook 2020-09-14 17:16:03 +08:00
可以尝试存在数据库里管理，比如 MongoDB 对于 16M 以上的文件可以用 GridFS，对于 16M 以下的可以用 BinData，自己没用过，感兴趣可以简单做一下压测。
https://docs.mongodb.com/manual/core/gridfs/ |
Select Language