用于 blob、对象、文件和数据湖的 SeaweedFS 快速分布式存储系统
SeaweedFS 是一个受 Facebook Haystack 启发的开源分布式存储系统，作为适用于数十亿小型或中型文件工作负载的快速、低成本替代方案，正在受到关注，可替代 S3 和其他自建对象存储。评论者报告称它在大规模场景下性能和可靠性都很强，尤其是在某些重 HDD 的部署中相较 MinIO 更有优势，但也指出其配置复杂、运维文档稀缺、POSIX 语义不完整，以及在生产环境中安全运行分布式存储的常见挑战。该讨论将 SeaweedFS 与 Ceph、Garage、JuiceFS 和传统 ZFS 等替代方案并列，强调 API 兼容性、元数据设计、纠删码和运维负担如何影响存储后端的选择。
真实部署与性能
- 多位用户报告 SeaweedFS 已在生产环境或实验环境中运行：Kubernetes PV、家庭实验室、250TB 以上音频、50TB 以上游戏回放、数十亿缩略图，以及数十亿级小文件。
- 对其在大量小/中等对象（缩略图、XML、PDF）上的性能给予持续好评，即使在高百分位上也有不错的延迟，并且对 HDD 的利用效率很高。
- 有人提到一旦配置好，它就“只是能用”，即便在较小规模（约 25 万对象）下也能稳定运行多年。
与替代方案的比较
- 经常与 MinIO 对比：从历史上看，MinIO 在极小文件上的表现较弱，不过新版本已有改进；但有一个团队仍然认为 SeaweedFS 在超过 100TB 的 HDD 工作负载上更快，尤其是考虑到 MinIO 的纠删码开销和刚性的扩容模型。
- Garage 被建议作为更简单的仅 S3 选项，代码更容易阅读，但没有纠删码，且采用 AGPL 许可。
- Ceph 被认为功能强大，但笨重且复杂；有评论声称 SeaweedFS 的元数据开销低得多，并且由于其卷级纠删码，写入更快。
- Longhorn 被提到是块存储（类似 EBS），而不是类似 S3 的对象存储。
- JuiceFS 需要单独的后端存储（例如 S3、SeaweedFS），并不是独立的 SDS；一位测试者在后端较慢时看到了正确性问题。
架构与设计
- 基于类似 Haystack 的仅追加 blob 存储：大型“卷”中打包 blob，并配有独立元数据，目标是在每次访问时实现 O(1) 级别的磁盘/网络操作。
- 更高层的文件和 S3 层本质上是构建在 blob 之上的元数据服务；元数据可以存储在不同后端（Postgres、Cassandra、Redis 等）中。
- 卷是仅追加的，通过“vacuum”过程在删除后回收空间。
运维挑战与可靠性
- 设置、工具和 CSI 驱动被描述为晦涩或笨拙；CSI sidecar 可能占用较多资源。
- 过去在高并发写入时曾出现对象副本不足的问题；据认为在新版本中已修复。
- 一位用户在 SeaweedFS CSI 挂载上运行 Postgres 失败；其他人警告说，把数据库放在通用网络文件系统上是有风险的。
何时使用 vs 云端 S3
- 对于完全在 AWS 上的工作负载，评论者认为相较于 S3 没有多少优势。
- 对于本地部署或非云部署，SeaweedFS 因可避免出站流量费用并利用廉价 HDD 而具有吸引力。
文档与清晰度缺口
- 多次呼吁改进以下方面的文档：小文件行为、碎片化及 vacuum 的影响、scrubbing/bitrot 修复、升级流程，以及 filer 后端之间更细致的权衡。
- 一些关于“blobs vs files vs objects”的架构解释被认为不够清晰或不完整。