Haystack 模型与 master、volume、filer

一句话总结

SeaweedFS将数百万个小文件打包成几个大容器文件。没有与文件数量相同的inode，也没有与文件数量相同的元数据查询。

为什么需要这个？

有很多人经历过把100万个缩略图放在文件系统里会发生什么。虽然磁盘使用量很少，但inode就会用完，ls花费几分钟，备份工具花费几天时间来stat每个文件。4KB文件100万个在数据上只有4GB，但在文件系统中是100万个元数据条目。

对象存储也不能解决这个问题。每个对象都会产生元数据记录，请求也会按对象分组，所以数量即是成本和负担。

SeaweedFS 采用来自脸书的 Haystack 论文的方法。将小文件连成大文件，只记住位置（偏移量和长度）。如果 1,000 个文件放入一个文件中，inode 就一个，读取只需要一次偏移量扫描。

怎么行动

有三种恶魔。

主机（基本9333）只管理卷的布局。决定哪些卷在哪个卷服务器上，新文件要写在哪里。没有文件元数据这一点很重要——所以主机不会成为瓶颈。

卷服务器（默认8080号码）有实际数据。将卷文件（.dat）和索引（.idx）作为一个对，通过文件ID找到偏移量进行读取。

文件处理器（默认8888）是上面叠加目录结构和POSIX属性的单独无状态服务器。如果想基于路径进行写入和读取，请通过文件处理器。S3网关也在上面。

基本流程是这样的。在大师那里/dir/assign请求文件ID（例如：3,01637037d6)并收到卷服务器地址，将文件上传到该服务器。读取时/dir/lookup找到卷位置，然后从该服务器接收。这两个步骤是SeaweedFS的核心，文件夹和S3网关是其上的便利层。

在现场相遇的样子

如果诚实地整理选择标准的话，就是这样。如果文件量大，数量即是问题的话，SeaweedFS很强。如果以大文件为主，只需要S3 API的小规模的话，Garage这样的轻量级选择更好。如果组织规模大，有存储团队的话，Ceph RGW是经过验证的选择。

风险也应该诚实地看待。SeaweedFS是发布最活跃的领域，但提交集中度很高——创始人的提交有9,968个，比第2名（530个）的数字不同。这并不意味着项目要死掉，而是意味着对Bus Factor的担忧是合理的。

而且，这种判断实际上是有必要的背景。MinIO社区版经历了2025年5月功能缩减、9-10月停止发布、12月维护模式，于2026年3-7月依次归档了存储库。虽然许可证一直是AGPLv3，但由于高等级CVE的修改没有以官方映像的形式出现，转换成本被转嫁给了用户。教训不是“MinIO不好”，而是单一供应商拥有CLA的开源基础设施，其供应商的业务转型即意味着项目的命运。在数据物理沉积的层次上，这种风险直接转化为迁移成本。

音量变大的话会发生什么事呢？

将小文件装入大体积的结构中，随之而来的是该结构固有的运营项目。其中首先遇到的是体积数量和大小的上限。

卷服务器不会无限创建卷。最大数量和卷大小有一个上限，如果没有任何可用卷，上传全部失败。此时出现的症状很严重，因为磁盘有余地，服务器也还在运行，所以会一直说“为什么不行”。查看主机返回的分配信息中可用卷是否为空是诊断的捷径。上限是启动服务器时确定的值，所以在容量计划中必须将磁盘大小和这两个值一起设定。

**删除的位置不会马上恢复。**删除文件会从索引中删除，但卷文件中的那个位置会保持原样。要恢复，必须重新压缩卷，在此期间，该卷将成为只读文件。所以在删除量大的工作负载中，什么时候压缩决定了实际使用量。

**复制是体积单位。**不是每个文件都决定副本数量，而是创建体积时决定了该体积的复制方式，所以如果以后要更改，必须创建新的设置的体积并移动。这是一开始确定时需要谨慎的值。

而且不能忘记文件处理器的元数据在单独的存储库中。即使备份卷数据，如果不同时接收文件处理器的数据库，路径结构就会全部消失，数据虽然存在，但无法知道哪个文件是什么状态。备份计划必须始终包含两个，恢复测试也必须同时恢复两个。

下次实习要做的事情

直接启动主机、卷、文件夹，获得文件ID上传并查询。放入500个小文件确认卷文件数量，在最后一次实践中将同一体裁文件放入文件系统、S3、SeaweedFS三个地方，以数字比较特性。