Todo banco de dados relacional trava se voc\u00ea trocar o disco dele por um bucket S3. E toda tentativa de guardar 40 milh\u00f5es de imagens de usu\u00e1rio num volume de bloco vira um pesadelo de gerenciamento de sistema de arquivos antes do primeiro milh\u00e3o. O problema n\u00e3o \u00e9 a ferramenta. \u00c9 a arquitetura por tr\u00e1s dela.<\/p>\n\n\n\n
Object storage e block storage resolvem problemas diferentes porque foram desenhados com trade-offs diferentes: um otimiza para escala horizontal e metadados ricos, o outro para lat\u00eancia baixa e acesso rand\u00f4mico. Confundir os dois na hora de arquitetar custa retrabalho de migra\u00e7\u00e3o seis meses depois, quando o volume de dados j\u00e1 n\u00e3o cabe mais na decis\u00e3o errada.<\/p>\n\n\n\n
Este artigo cobre a diferen\u00e7a estrutural entre os dois modelos, os cen\u00e1rios t\u00e9cnicos onde cada um vence, e onde a resposta certa \u00e9 usar os dois ao mesmo tempo.<\/p>\n\n\n\n
Block storage divide os dados em blocos de tamanho fixo, cada um com um endere\u00e7o pr\u00f3prio. O sistema operacional enxerga esses blocos como se fossem um disco f\u00edsico conectado \u00e0 m\u00e1quina, seja via iSCSI, Fibre Channel ou o driver de bloco que a cloud exp\u00f5e para a VM.<\/p>\n\n\n\n
Essa camada de abstra\u00e7\u00e3o \u00e9 o que permite instalar um sistema de arquivos por cima (ext4, XFS, NTFS) e tratar o volume como qualquer disco local. O kernel gerencia aloca\u00e7\u00e3o, o sistema de arquivos gerencia hierarquia de diret\u00f3rios, e a aplica\u00e7\u00e3o n\u00e3o sabe (nem precisa saber) que o disco \u00e9 remoto.<\/p>\n\n\n\n
Na pr\u00e1tica, isso significa:<\/p>\n\n\n\n
O Locaweb Cloud sustenta esse modelo com discos NVMe de at\u00e9 8.000 IOPS e volumes adicionais dimensionados por GB, o que cobre o caso de uso mais comum: banco de dados que precisa de lat\u00eancia previs\u00edvel independente de quanto ele cresce.<\/p>\n\n\n\n
Rodar essa camada no core da internet brasileira muda o c\u00e1lculo de lat\u00eancia de forma concreta. Um volume de bloco anexado a uma VM com peering local responde em dezenas de milissegundos para usu\u00e1rios no Brasil, contra uma rota que atravessa fronteira em provedores sem data center nacional.<\/p>\n\n\n\n
Object storage n\u00e3o divide dados em blocos. Ele trata cada arquivo como um objeto \u00fanico, guardado com seus metadados e um identificador dentro de um namespace plano, o bucket. N\u00e3o existe hierarquia de pastas de verdade: o que parece uma estrutura de diret\u00f3rios (“imagens\/2026\/produto-123.jpg”) \u00e9, na pr\u00e1tica, uma chave de string dentro do mesmo espa\u00e7o plano.<\/p>\n\n\n\n
Essa escolha de design tem duas consequ\u00eancias diretas:<\/p>\n\n\n\n
Metadados ricos por objeto (data de cria\u00e7\u00e3o, tags customizadas, controle de vers\u00e3o) tornam esse modelo naturalmente mais f\u00e1cil de indexar e buscar em escala do que uma \u00e1rvore de diret\u00f3rios com milh\u00f5es de arquivos.<\/p>\n\n\n\n
Essa arquitetura tamb\u00e9m muda como voc\u00ea pensa em durabilidade. Em vez de depender de RAID num \u00fanico array de disco, o object storage replica cada objeto entre m\u00faltiplos n\u00f3s do cluster automaticamente. Perder um n\u00f3 n\u00e3o significa perder dado, porque a c\u00f3pia redundante j\u00e1 est\u00e1 em outro lugar da malha, um design que favorece consist\u00eancia de longo prazo sobre velocidade de escrita individual.<\/p>\n\n\n\n