Object Storage vs Block Storage: Qual É Melhor?

O object storage ganha para ficheiros carregados por utilizadores, ativos estáticos, cópias de segurança e arquivos — essencialmente tudo o que acede via HTTP e raramente muta no lugar. O block storage ganha quando precisa de escritas aleatórias de baixa latência: bases de dados, volumes de arranque, sistemas de ficheiros de alta transação. Para cargas de trabalho de transferência de ficheiros especificamente, o object storage é quase sempre a escolha correta porque escala horizontalmente, custa 0,015-0,023 EUR/GB/mês contra 0,08-0,125 EUR/GB/mês para block, e gere buckets à escala de petabytes sem reparticionamento.

Como Diferem Realmente Por Baixo

O block storage expõe um dispositivo em bruto (uma LUN ou volume EBS) que o SO formata com ext4, XFS ou NTFS. Leituras e escritas acontecem em blocos de tamanho fixo, tipicamente 4 KB ou 16 KB, sobre iSCSI, NVMe-oF ou SCSI. O SO é dono do sistema de ficheiros; o dispositivo de bloco não sabe nada sobre ficheiros, apenas deslocamentos.

O object storage expõe uma API HTTP (S3, Azure Blob, GCS) onde cada objeto tem uma chave, bytes e metadados. Não há sistema de ficheiros por baixo — os objetos são unidades atómicas que coloca e obtém na íntegra. As escritas geram novas versões; não pode modificar o byte 1.000.000 de um objeto de 2 GB sem reescrever o objeto inteiro. Esta imutabilidade é uma funcionalidade: permite a replicação multi-região, o versionamento e as regras de ciclo de vida que o block storage não consegue facilmente igualar.

Comparação Rápida

| Dimensão | Object Storage | Block Storage | |----------|----------------|---------------| | API típica | S3 HTTP REST | POSIX + iSCSI/NVMe | | Custo (camada quente AWS) | 0,023 EUR/GB/mês | 0,08 EUR/GB/mês (gp3) | | Unidade máxima | 5 TB por objeto | 64 TiB por volume EBS | | Latência | 10-100 ms | Sub-milissegundo | | Leitores concorrentes | Ilimitados | Um host de cada vez (geralmente) | | Afirmação de durabilidade | 11 noves (S3) | 5-6 noves (EBS) | | Adequado para | Ficheiros, media, backups | Bases de dados, discos de arranque | | Inadequado para | Escritas aleatórias em ficheiros grandes | Escala horizontal além de um volume |

Débito vs Latência: Vencedores Diferentes

Um volume gp3 EBS serve leituras de 4 KB em menos de 1 ms; um GET S3 para os mesmos 4 KB demora 20-80 ms dependendo da região. Para um write-ahead log PostgreSQL a fazer 5.000 transações por segundo, essa diferença de latência é devastadora. Para um utilizador a transferir um .zip de 500 MB, é irrelevante porque o atraso no primeiro byte desaparece por trás do débito.

No débito sequencial, o object storage frequentemente ganha à escala. O S3 pode servir um único bucket a 5.500 pedidos GET/segundo por prefixo, e com particionamento da taxa de pedidos (chaves com prefixo em hash) isso chega às dezenas de milhares. Um único volume gp3 limita-se a 1.000 MB/s e 16.000 IOPS. Para dez utilizadores concorrentes a transferir um ficheiro de 10 GB, o object storage satura os seus canais; o block storage torna-se um gargalo.

Custo à Escala

Para 100 TB de media moderadamente fria:

S3 Standard: 2.300 EUR/mês
S3 Standard-IA: 1.250 EUR/mês
S3 Glacier Instant Retrieval: 400 EUR/mês
S3 Glacier Deep Archive: 99 EUR/mês
EBS gp3: 8.000 EUR/mês
EBS st1 (HDD otimizado para débito): 4.500 EUR/mês

O block storage não tem escalonamento. Paga o preço de acesso de pico por dados que toca uma vez por ano. As regras de ciclo de vida do object storage movem os objetos automaticamente: quente por 30 dias, Standard-IA por 60, Glacier após 90. Para um serviço de transferência de ficheiros que armazena carregamentos com expiração de 7 dias, o object storage com uma regra Expiration é dramaticamente mais barato do que correr um servidor suportado por EBS.

Consistência e Concorrência

O S3 agora proporciona consistência forte de leitura-após-escrita para PUTs e DELETEs, globalmente. O Azure Blob e o GCS igualam. Isto removeu um dos argumentos históricos contra o object storage — costumava ver surpresas de "consistência eventual" onde um ficheiro recém-carregado devolvia 404 por alguns segundos.

Mas os escritores concorrentes ainda importam. O block storage assume geralmente um único escritor; existem modos multi-attach mas acrescentam complexidade. O object storage deixa um milhão de clientes fazer PUT simultaneamente, com semântica de último-escritor-ganha (ou versionamento para guardar todos). Para um sistema de partilha de ficheiros onde dois utilizadores podem carregar ficheiros diferentes com a mesma chave, o versionamento no bucket preserva ambos.

Quando as Aplicações de Transferência de Ficheiros Precisam de Block Storage Mesmo Assim

A ressalva: a aplicação que serve o object storage frequentemente corre em hosts suportados por block. Uma API de carregamento de ficheiros precisa de um disco local para colocação em fila temporária (fragmentos multipart, análise antivírus), armazenamento de metadados (geralmente em PostgreSQL no EBS) e registos. Os objetos em si vão para S3/R2/Blob; a maquinaria à volta deles vive em block.

Para carregamentos em streaming de alto débito, os pipelines em memória superam o disco. Bibliotecas como aws-sdk-js e boto3 suportam carregamentos multipart em streaming que nunca tocam o disco local. Um serviço de carregamento bem afinado pode empurrar um ficheiro de 5 GB do cliente para o object storage com menos de 500 MB de RAM e zero ficheiros temporários.

Metadados: A Diferença Silenciosa

O object storage transporta metadados com cada objeto: metadados de sistema (tamanho, mtime, etag), metadados de utilizador (pares chave-valor arbitrários, cabeçalhos x-amz-meta-*) e etiquetas. Pode pesquisar por metadados via S3 Object Lambda, relatórios de Inventário ou combinando com o DynamoDB. O block storage deixa os metadados inteiramente ao sistema de ficheiros, o que significa etiquetar 10 milhões de ficheiros requer uma base de dados personalizada.

Para uma aplicação de transferência que precisa de responder "encontrar todos os ficheiros acima de 100 MB carregados na semana passada por utilizadores em França" instantaneamente, os metadados de objeto mais um inventário Parquet permitem consultar com o Athena em segundos. A mesma questão num volume de block montado via NFS é um comando find que demora horas.

Cifração e Controlo de Acesso

Ambos os tipos de armazenamento suportam cifração em repouso com AES-256. O object storage torna fácil o controlo de acesso por objeto: políticas de bucket, URLs pré-assinadas, ACLs de objeto e condições IAM. O acesso ao block storage é mais grosseiro — o volume completo está anexado ou não.

Para partilha segura de ficheiros com ligações de transferência com tempo limitado, as URLs pré-assinadas S3 (válidas por no máximo 7 dias) são o padrão. Para transferências com zero exposição de texto simples do lado do servidor, a cifração do lado do cliente antes do carregamento funciona com qualquer armazenamento de objetos. O HexaTransfer encripta com AES-256-GCM no browser e armazena apenas texto cifrado — o backend de objetos vê bytes sem significado.

A Regra de Decisão Simples

Faça três perguntas:

Acede aos dados via uma API de sistema de ficheiros (POSIX, SMB, NFS)? Se sim, block ou file storage.
Acede-lhe via HTTP, raramente o muta, e quer escala ilimitada? Se sim, object storage.
O conjunto de dados tem mais de 10 TB e está a crescer? Quase sempre object storage.

Para cargas de trabalho de transferência de ficheiros, a resposta à (2) é sempre sim. Use S3, R2, Azure Blob ou GCS para os ficheiros em si, e reserve o block storage para a base de dados e a camada web que os gere.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.