这是一个创建于 1861 天前的主题，其中的信息可能已经有所发展或是发生改变。
需求：一个小时大概有 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