SeaweedFS: sistema rápido de almacenamiento distribuido para blobs, objetos, archivos y datalake

Artículo original ↗ Discusión en Hacker News ↗

SeaweedFS, un sistema de almacenamiento distribuido de código abierto inspirado en Haystack de Facebook, está atrayendo atención como una alternativa rápida y rentable a S3 y otros almacenes de objetos autoalojados para cargas de trabajo con miles de millones de archivos pequeños o medianos. Quienes comentan informan de un buen rendimiento y fiabilidad a escala, especialmente frente a MinIO en algunas configuraciones con mucho uso de HDD, pero señalan compromisos en complejidad de configuración, documentación operativa escasa, semántica POSIX incompleta y los desafíos habituales de ejecutar almacenamiento distribuido de forma segura en producción. El hilo sitúa SeaweedFS junto a alternativas como Ceph, Garage, JuiceFS y ZFS tradicional, destacando cómo la compatibilidad de APIs, el diseño de metadatos, el erasure coding y la carga operativa influyen en la elección del backend de almacenamiento.

Despliegues reales y rendimiento

  • Varios usuarios informan que SeaweedFS se ejecuta en producción o en laboratorios: PVs de Kubernetes, laboratorios domésticos, más de 250TB de audio, más de 50TB de replays de juegos, miles de millones de miniaturas y miles de millones de archivos pequeños.
  • Recibe elogios constantes por su rendimiento con muchos objetos pequeños/medianos (miniaturas, XML, PDFs), buena latencia incluso en percentiles altos y uso eficiente de HDD.
  • Algunos señalan que “simplemente funciona” una vez configurado, con años de operación estable incluso a escalas más pequeñas (~250k objetos).

Comparación con alternativas

  • Se compara con frecuencia con MinIO: históricamente MinIO era más débil con archivos diminutos, aunque las versiones nuevas mejoraron; un equipo aún encontró que SeaweedFS era más rápido para cargas de trabajo de HDD de más de 100TB, especialmente por la sobrecarga del erasure coding de MinIO y su modelo rígido de expansión.
  • Garage se sugiere como una opción S3-only más simple, con código más fácil de leer pero sin erasure coding y con licencia AGPL.
  • Ceph se considera potente pero pesado/complejo; un comentario afirma que SeaweedFS tiene una sobrecarga de metadatos mucho menor y escrituras más rápidas gracias a su erasure coding a nivel de volumen.
  • Longhorn se menciona como almacenamiento en bloque (similar a EBS) más que como algo tipo S3.
  • JuiceFS requiere un almacenamiento de respaldo separado (por ejemplo, S3, SeaweedFS) y no es un SDS autónomo; una persona que lo probó vio problemas de corrección con backends lentos.

Arquitectura y diseño

  • Construido sobre un almacén de blobs append-only al estilo Haystack: grandes “volúmenes” con blobs empaquetados y metadatos separados, orientado a operaciones de disco/red de O(1) por acceso.
  • Las capas superiores de archivos y S3 son servicios de metadatos encima de blobs; los metadatos pueden almacenarse en distintos backends (Postgres, Cassandra, Redis, etc.).
  • Los volúmenes son append-only con un proceso de “vacuum” para recuperar espacio después de eliminaciones.

Desafíos operativos y fiabilidad

  • La configuración, las herramientas y los drivers CSI se describen como oscuros o torpes; los sidecars CSI pueden consumir muchos recursos.
  • Hubo problemas en el pasado con objetos sin replicar suficientemente durante escrituras concurrentes intensas; se cree que están corregidos en versiones más recientes.
  • Ejecutar bases de datos como Postgres sobre el montaje CSI de SeaweedFS falló para un usuario; otros advierten que las bases de datos sobre sistemas de archivos de red genéricos son arriesgadas.

Cuándo usarlo frente a S3 en la nube

  • Para cargas de trabajo completamente en AWS, quienes comentan ven poca ventaja frente a S3.
  • Para despliegues on-prem o fuera de la nube, SeaweedFS resulta atractivo para evitar costes de egress y aprovechar HDD baratos.

Lagunas de documentación y claridad

  • Se piden repetidamente mejores docs sobre: comportamiento de archivos pequeños, fragmentación e impacto del vacuum, reparación de scrubbing/bitrot, procedimientos de actualización y trade-offs detallados entre backends de filer.
  • Algunas explicaciones arquitectónicas sobre “blobs vs files vs objects” se consideran poco claras o incompletas.