需求:一个小时大概有 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/ |