一亿个图片和 pdf 文件，单机，只新增不删除，怎么管理？

This topic created in 1835 days ago, the information mentioned may be changed or developed.

领导说 OSS 太贵了，自己搞了个服务器，拿几个机械硬盘组了个 RAID5 ，15T 容量。

我目前是格式化成了 XFS ，挂载参数调了下，然后根据前缀保存到不同的 zip 文件中，比如 000xxx.jpg 就保存到 000.zip ，zip 用 store 方式不压缩。

但越往后写入越慢，猜测还是有碎片，或者写入方式有问题（看了下 zip4j 是复制一个新的包加进去然后删掉原来的,如果能直接写而不创建新的也许好很多）。

不知道有没有更好点的方法，seaweed 似乎单节点最大 8T 不方便，hbase 的 mob 可行吗？

zip

写入

保存

OSS

16 replies • 2021-11-13 10:59:16 +08:00

kokutou

Nov 4, 2021

机械盘不会是叠瓦吧。。。
垂直机械盘越往后并不会越慢啊。

kokutou

Nov 4, 2021

想起来那个确实会越慢，但是是内外圈的区别。
最后剩余的几个 t 就不要用了。

比如这种 4t 的，最后 3200-4000gib 的我就分个区存视频了。

kokutou

Nov 4, 2021

可以试试加个临时盘，zip 写完了后，再复制进去，就是完整的大文件，不是碎片了。

LaoK666

Nov 4, 2021

为啥要把数据打包成 zip ？方便批量下载么？

murmur

Nov 4, 2021

叠瓦盘的问题是读写一起并发会雪崩甚至卡住，复制一个新包删掉原来的大概率就是读写问题

ziseyinzi

Nov 4, 2021

为啥 zip+1,直接用文件夹呢？

Tianao

Nov 4, 2021

@kokutou #1 任何机械盘都存在磁盘碎片问题啊。

rykinia

Nov 4, 2021

@kokutou 倒不是，是企业盘

cheng6563

Nov 4, 2021

zip 附加文件基本都是文件碎片，建议直接建目录放文件。
除非你真的要分布式存储不然不要用 seaweed hbase 什么的，性能最好的就是文件系统直接放文件。
机械盘不是叠瓦的吧，叠瓦盘写入就是会爆炸的。

rykinia

Nov 4, 2021

@wangxkww 文件多了以后，ls 之类的命令就没法用了，会卡死。然后，根据这个 http://genomewiki.ucsc.edu/index.php/File_system_performance#ext4_filesystem
理论上文件数量多了以后性能还是会下降，所以我想的是加一个类似索引的步骤

reallittoma

Nov 4, 2021

你这里 zip 相当于又一个文件系统了，文件系统套文件系统，能不慢吗

heguangyu5

Nov 4, 2021

有个 lib 叫 LMDB, http://www.lmdb.tech/doc/
基于 LMDB 有个项目叫 memcachedb, https://github.com/LMDB/memcachedb
可以对 memcachedb 做下改造,新增加一个 mmap 的巨大文件(当然要控制一下这个文件占用的 file cache 大小),然后把图片和 pdf 文件保存到这个大文件里,然后将 offset 保存到 memcachedb 的 LMDB 文件里,再让 LMDB 文件始终都在内存里.
这样文件的查找和新增都是在操作内存中的 LMDB,文件的写入和读取都是基于 mmap,只要内存稍大一点,应该就不是问题了.

kokutou

Nov 4, 2021

@Tianao #7
另外分个区里写 zip ，zip 写满了后，再复制过去就可以避免碎片了
但是要是随机的往每个 zip 里写，不存在写完一个 zip ，这方法就不行。

cpstar

Nov 4, 2021

公有 OSS 太贵。自己搞服务器，上 minio 啊，弹性扩展，也还是对象存储

LaoK666

Nov 4, 2021

@rykinia 那用多级文件夹感觉就可以吧，这样还好配合 minio 直接提供访问服务

rykinia

Nov 13, 2021

@wangxkww minio 单机也相当于直接操作硬盘里的文件，这个还是要多台服务器才能发挥出来实力。

我最后搭了个 hbase 解决了。