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//filesimultaneamente; 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).
- Você pode ter chaves como
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.