S3 são arquivos, mas não um sistema de arquivos

O que o S3 é (e não é)

  • Há amplo consenso: o S3 é um armazenamento de objetos / armazenamento chave–valor, não um sistema de arquivos tradicional.
  • Modelo central: mapeamento plano de chaves → objetos; chaves são strings opacas, e as operações são GET/PUT/DELETE de objeto inteiro.
  • Semânticas no estilo POSIX (inodes, diretórios como objetos de primeira classe, gravações parciais, renomeações atômicas) estão ausentes por design.
  • Alguns argumentam que o S3 ainda conta como “um tipo de sistema de arquivos” no sentido amplo (“sistema que gerencia arquivos”), enquanto outros insistem que isso dilui o termo e leva os usuários a pressupostos errados.

“Pastas” e semântica de caminhos

  • O S3 não tem diretórios reais. “Pastas” no console são açúcar de interface sobre prefixos de chave, às vezes implementadas com objetos marcadores de 0 bytes.
  • Consequências:
    • Você pode ter chaves como dir, dir/file, dir//file simultaneamente; barras não são especiais para o S3.
    • “Pastas” vazias desaparecem quando o último objeto com esse prefixo é excluído.
    • Renomear uma “pasta” exige copiar e excluir cada objeto com aquele prefixo (O(número de objetos) e não atômico).

Operações, desempenho e listagem

  • Sem modificação no local nem append; você precisa reenviar o conteúdo alterado ou fatiar em camadas superiores.
  • Copiar e renomear são implementados como copiar+excluir, com custo e latência escalando com o tamanho do objeto.
  • A listagem é uma diferença semântica e de desempenho importante:
    • O S3 lista por prefixo em ordem lexicográfica e suporta paginação; pode ser muito eficiente para varreduras e particionamento baseados em prefixo.
    • Caminhadas recursivas de diretórios no estilo POSIX são lentas e exigem muitas chamadas sequenciais de listagem; excluir ou esvaziar buckets grandes pode ser caro e complexo.

Bancos de dados e camadas de sistema de arquivos sobre S3

  • Executar bancos de dados tradicionais diretamente sobre o S3 é amplamente visto como um mau encaixe: latência, ausência de gravações parciais, sem “gravar se não existir” atômico.
  • Padrões bem-sucedidos:
    • Sistemas que são somente append ou tratam arquivos como partes imutáveis (por exemplo, motores analíticos, formatos de tabela como Delta/Iceberg/Hudi).
    • Arquiteturas que usam o S3 como plano de dados com uma camada separada, fortemente consistente, de metadados/índice (por exemplo, bancos usando WAL no S3 mais caches locais, ou serviços externos de metadados).
    • Camadas FUSE e VFS (por exemplo, rclone, sistemas de arquivos customizados) que emulam POSIX por meio de cache local, fragmentação e gerenciamento de metadados em outro lugar — úteis, mas complexas e com vazamentos de abstração.

Durabilidade, custo e alternativas

  • A durabilidade do S3 é muito elogiada; descrita como líder de mercado, com uso intenso de checksums e replicação, embora não sejam citadas validações de terceiros no estilo Jepsen.
  • O S3 é geralmente visto como barato para grandes conjuntos de dados frios; outros observam que existem armazenamentos de objetos mais baratos, mas que podem trocar confiabilidade ou recursos.
  • Para semânticas reais de sistema de arquivos e baixa latência, comentaristas apontam para EBS/EFS/FSx ou sistemas de arquivos on-premise; para configurações locais “parecidas com S3, mas mais simples”, são sugeridos servidores de armazenamento de objetos ou camadas customizadas.