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

[rykinia]

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

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

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

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

[kokutou]

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

[kokutou]

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

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

[kokutou]

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

[wangxkww]

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

[murmur]

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

[ziseyinzi]

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

[Tianao]

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

[rykinia]

@kokutou 倒不是，是企业盘

[cheng6563]

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

[rykinia]

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

[reallittoma]

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

[heguangyu5]

有个 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]

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

[cpstar]

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

[wangxkww]

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

[rykinia]

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

我最后搭了个 hbase 解决了。