Block storage vs object storage: o que cada um resolve

1.00

Resposta direta: block storage guarda o dado em blocos ligados a uma máquina virtual, com latência baixa. É o formato de banco de dados, volume de sistema operacional e carga transacional. Object storage guarda o dado como objetos com metadados, acessados por API, com escala quase ilimitada e custo por GB menor. É o formato de arquivo, mídia, backup e log. NVMe é o tipo mais rápido de block storage, indicado para banco exigente e alta demanda de IOPS. Regra prática: dado lido e escrito o tempo todo pede block ou NVMe; dado guardado e acessado de vez em quando pede object.

A decisão block storage vs object storage parece detalhe de infraestrutura, mas mexe em custo, desempenho e na própria arquitetura da aplicação. E a escolha certa quase nunca é "o melhor armazenamento". É o armazenamento que combina com o padrão de acesso do seu dado. Banco de dados quer latência baixa e muito IOPS. Arquivo quer escala e custo por GB. Quando você separa esses dois mundos, para de pagar disco rápido para guardar log e para de sofrer com latência rodando banco no lugar errado.

Este post é para quem está desenhando (ou revisando) a camada de armazenamento e precisa decidir o que vai em cada tipo. Sem enrolação: primeiro a diferença em uma frase, depois cada tipo, quando usar, uma tabela e um checklist de 4 perguntas.

Block storage vs object storage: a diferença em uma frase

Pense em block storage como um armário de gavetas numeradas ao lado da sua mesa. O sistema operacional sabe em qual gaveta está cada pedaço do arquivo, pega os pedaços na ordem e monta o dado na hora. É rápido e previsível. A limitação é que o armário está preso àquela mesa: cresce até certo ponto e serve uma máquina de cada vez.

Object storage é outro modelo. Imagine um galpão gigante onde cada caixa tem uma etiqueta única com a descrição do conteúdo. Você não abre a caixa para trocar um item lá dentro. Pede a caixa inteira pela etiqueta, recebe, e se quiser mudar algo, devolve uma caixa nova no lugar. O galpão tem espaço quase infinito, sai barato por caixa e você acessa de qualquer lugar por um pedido, que é a API. A troca é que buscar a caixa leva um instante a mais do que abrir a gaveta ao lado.

A diferença, então, não é qualidade. É padrão de acesso. Gaveta ao lado para o que você mexe toda hora. Galpão etiquetado para o que você guarda e acessa de vez em quando.

O que é block storage

Block storage quebra o dado em blocos de tamanho fixo, cada um com um endereço próprio. Esses blocos são apresentados a uma máquina virtual como um volume, um "disco". Quem organiza os blocos em arquivos e pastas é o sistema de arquivos do próprio SO, do mesmo jeito que faria com um HD ou SSD local. Para a aplicação, é disco: ela lê e escreve sem saber que aquilo mora numa infraestrutura de nuvem.

Esse modelo entrega o que banco e sistema transacional precisam: latência baixa e IOPS alto (muitas operações de leitura e escrita por segundo). Por isso block storage é o lugar natural de:

Banco de dados relacional como SQL Server, Oracle, MySQL, MariaDB e PostgreSQL.
Volume de sistema operacional e boot das máquinas.
ERPs de mercado sob carga, que fazem escrita constante em banco.
Cache, fila e qualquer aplicação que trata o disco como memória rápida.

Na prática, é o disco onde a sua instância de banco de dados gerenciado roda. Na Optidata, esses volumes usam armazenamento premium, com NVMe como o tier mais rápido (mais sobre isso adiante).

O que é object storage

Object storage não trata o dado como disco. Trata como objeto: o conteúdo, mais os metadados (quem criou, quando, tipo, etiquetas), mais um identificador único. Esses objetos ficam em "baldes" (buckets), num espaço plano, sem a hierarquia de pastas do sistema de arquivos. Você acessa cada objeto por API, sobre HTTP, com operações simples de gravar e ler (PUT e GET), de qualquer lugar.

O ganho é escala e custo. Object storage cresce na horizontal para a casa dos petabytes sem você provisionar volume, e o custo por GB é baixo. É o formato certo para dado que você guarda em volume e não fica reescrevendo o tempo todo:

Backup e arquivamento de dados.
Mídia: imagem, vídeo e áudio.
Log, telemetria e dado para data lake.
Arquivo estático de site e aplicação (assets, downloads, documentos).

Tem um detalhe que muda a conta quando você serve muito arquivo: tráfego de saída. Nos hyperscalers, ler e distribuir esses objetos costuma gerar cobrança de egress. Na Optidata, o Object Storage não tem cobrança de tráfego, o que deixa o custo de servir mídia e distribuir arquivo previsível. Segundo a Optidata, a plataforma processa mais de 15 petabytes, boa parte em cargas que combinam com esse modelo.

Onde entra o NVMe (e por que ele não substitui object storage)

NVMe não é uma terceira categoria ao lado de block e object. É o tipo mais rápido de block storage. Enquanto discos mais antigos conversam com o armazenamento por interfaces como SATA e SAS, o NVMe fala com a memória flash direto pelo PCIe, com muitas filas em paralelo. O resultado é latência muito baixa e IOPS muito alto.

Traduzindo para carga de trabalho: NVMe é o volume que você quer embaixo de um banco de dados exigente, de um sistema transacional com muita concorrência ou de um ERP de mercado no horário de pico. Onde cada milissegundo de acesso a disco vira tempo de resposta para o usuário, NVMe faz diferença.

O que NVMe não faz é resolver o problema que object storage resolve. Ele é rápido e caro, ligado a uma máquina, com escala limitada ao volume. Guardar milhões de arquivos frios em NVMe é desperdício. A leitura correta é esta: NVMe para o dado quente, object storage para o dado morno e frio. Um não briga com o outro, cada um cuida de um padrão de acesso.

Quando usar block, object ou NVMe

Use block ou NVMe quando

Um banco de dados vai gravar naquele volume.
É o disco de sistema operacional ou o boot de uma máquina.
A aplicação é transacional e sensível a latência (ERP de mercado, sistema de pedidos, financeiro).
Você precisa de IOPS alto e resposta imediata. Se for banco pesado sob carga, prefira NVMe.

Não use object storage quando

For rodar o disco de um banco de dados. A semântica e a latência estão erradas para isso.
For o volume de boot de uma máquina.
A aplicação precisar reescrever pedaços do dado o tempo todo, e não substituir o arquivo inteiro.

Use object storage quando

Precisa guardar backup, mídia, log ou arquivo em grande volume.
O dado cresce para dezenas de terabytes ou mais e não pode custar caro por GB.
Você quer acessar e distribuir o conteúdo por API, de qualquer lugar.

Não force block ou NVMe quando

O caso for arquivamento em massa raramente lido. Disco rápido aqui é dinheiro parado.
O objetivo for servir arquivo estático em escala. Object faz isso melhor e mais barato.

Tabela comparativa: block storage vs object storage vs NVMe

Critério	Block storage	Object storage	NVMe (tier premium de block)
Estrutura do dado	Blocos de tamanho fixo, com endereço	Objetos com metadados e ID único	Blocos, sobre flash em PCIe
Como se acessa	Ligado a uma VM, como um volume	Por API/HTTP (PUT/GET), de qualquer lugar	Ligado a uma VM, como um volume
Latência	Baixa	Maior	Muito baixa
IOPS e concorrência	Alto	Não é o forte	Muito alto
Escala	Limitada ao volume da VM	Praticamente ilimitada (petabytes)	Limitada ao volume da VM
Custo por GB	Médio a alto	Baixo	Alto
Edição do dado	No nível do bloco, contínua	Substitui o objeto inteiro	No nível do bloco, contínua
Caso típico	Banco, volume de SO, ERP de mercado	Backup, mídia, arquivo, log, data lake	Banco exigente, transacional de alta demanda
Onde tropeça	Guardar arquivo em massa fica caro	Não serve para disco de banco nem boot	Custo não compensa para dado frio

Como escolher em 4 perguntas

Um roteiro rápido para bater o martelo por carga de trabalho:

O dado é lido e escrito o tempo todo, com pressa? Se sim, block ou NVMe. Se é guardado e acessado de vez em quando, object.
Um banco de dados ou o SO da máquina vão usar esse volume? Se sim, block ou NVMe, sem discussão. Se é arquivo, mídia, backup ou log, object.
O volume vai crescer para dezenas de terabytes ou mais de arquivo? Se sim, object resolve escala e custo. Se fica na casa do disco de uma VM, block dá conta.
Você precisa de latência mínima e muito IOPS? Banco transacional pesado ou ERP de mercado no pico pedem NVMe.

Na maioria dos ambientes, a resposta não é escolher um. É combinar: banco e sistema operacional em block ou NVMe, backup e mídia em object. O erro comum é jogar tudo no mesmo tipo e pagar caro por isso, seja em fatura, seja em latência.

Vantagens e limitações de cada um

Block storage

O que ganha: latência baixa, IOPS alto e semântica de disco que qualquer SO e qualquer banco entendem sem adaptação. É previsível e simples de operar.

Onde limita: a escala fica presa ao volume da máquina, o custo por GB é maior e guardar arquivo em massa aqui é desperdício de recurso caro.

Object storage

O que ganha: escala quase sem teto, custo por GB baixo e acesso por API de qualquer lugar. É a melhor casa para backup, mídia e distribuição de arquivo.

Onde limita: a latência é maior, não roda banco nem volume de boot, e você troca o objeto inteiro em vez de editar um pedaço. Para dado quente e transacional, não serve.

NVMe

O que ganha: é o mais rápido, com latência mínima e IOPS altíssimo. Faz diferença real embaixo de banco exigente e sistema de alta concorrência.

Onde limita: custo alto e escala de volume. Não faz sentido para dado frio e não resolve o problema de guardar arquivo em grande volume, porque continua sendo block.

Perguntas frequentes

Block storage é mais rápido que object storage?

Para acessar dado quente, sim. Block storage entrega latência baixa e IOPS alto porque o volume está ligado à máquina como um disco. Object storage é acessado por API, sobre HTTP, e prioriza escala e custo, não velocidade de acesso. Por isso banco vai em block (ou NVMe) e arquivo vai em object.

Posso rodar um banco de dados em object storage?

Não. Banco de dados precisa da semântica de disco e da latência baixa que só block storage entrega. Object storage substitui o objeto inteiro a cada gravação e responde por API, o que não combina com a escrita constante e granular de um banco. Rode o banco em block ou NVMe e use object para backup e exportação.

NVMe é a mesma coisa que SSD?

Não exatamente. SSD é o tipo de mídia (memória flash). NVMe é o protocolo e a interface pela qual essa flash conversa com a máquina, direto pelo PCIe. Um SSD comum usa interfaces mais antigas como SATA. Um volume NVMe usa flash sobre PCIe, com latência menor e IOPS maior. Todo NVMe usa flash, mas nem todo SSD é NVMe.

Object storage é sempre mais barato?

Por GB, geralmente sim, principalmente para dado morno e frio. Mas "mais barato" depende do padrão de acesso. Para dado quente, lido e escrito o tempo todo, o custo real aparece em latência e experiência, não só no preço do GB. E tem o tráfego de saída: em nuvem que cobra egress, servir muito arquivo encarece a conta. Na Optidata não há cobrança de tráfego, o que deixa esse custo previsível.

Qual tipo devo usar para backup?

Object storage é a escolha natural para backup, pela escala e pelo custo por GB. Some a isso o backup offsite, que é manter uma cópia dos seus dados guardada fora do site principal, para o caso de perder o ambiente de origem. A combinação usual é backup em object e, sobre isso, uma cópia offsite.

Dá para usar block e object juntos?

Sim, e é o mais comum. O desenho padrão coloca banco e sistema operacional em block ou NVMe e joga backup, mídia e log em object. Você paga velocidade só onde precisa de velocidade e paga por escala barata onde precisa guardar volume. É assim que a camada de armazenamento fica equilibrada em custo e desempenho.

Precisa desenhar essa camada por carga de trabalho? A Optidata testa isso com você numa POC sem compromisso, com preço fixo em real e licenças de banco inclusas.