Computational storage: quando o SSD deixa de ser armazém e vira processador

Estamos testemunhando o fim de uma era na arquitetura de computadores. Durante décadas, operamos sob a tirania do modelo de Von Neumann, onde a CPU é o rei absoluto e o armazenamento é apenas um servo passivo, um armazém distante e frio. Essa hierarquia funcionou bem quando processávamos megabytes. Hoje, na era dos petabytes, ela está colapsando sob o próprio peso.

O modelo atual é logisticamente insano. Gastamos uma quantidade absurda de energia e largura de banda para mover montanhas de dados brutos do SSD para a memória RAM, apenas para que a CPU descarte 90% deles em uma operação simples de filtragem. É como transportar toda a água do Rio Amazonas até São Paulo apenas para filtrar um copo de água potável. O futuro do armazenamento não é apenas guardar bits; é processá-los onde eles nascem. Bem-vindos à era do Computational Storage.

Resumo em 30 segundos

O Gargalo: A arquitetura atual desperdiça energia e tempo movendo dados inúteis do disco para a CPU via barramentos limitados (PCIe).

A Solução: Computational Storage Drives (CSDs) integram processadores (ARM, RISC-V ou FPGAs) diretamente no SSD para executar tarefas in-situ.

O Futuro: Com a chegada do CXL 3.0, o armazenamento deixa de ser periférico e torna-se um nó de processamento ativo, reduzindo latência e consumo energético em data centers.

O colapso da arquitetura centrada na CPU

A Lei de Moore desacelerou para as CPUs, mas a densidade de armazenamento continua a explodir. Temos SSDs NVMe corporativos ultrapassando 30TB e 60TB de capacidade em formatos como E1.S e E3. No entanto, a "estrada" que liga esse armazenamento ao processador — o barramento PCIe — não cresceu na mesma proporção.

Temos um problema de física básica: a gravidade dos dados. Dados têm massa, metaforicamente falando. Mover um petabyte de dados através de um data center consome mais energia do que processar esses dados. Quando você analisa a telemetria de um servidor de banco de dados moderno, percebe que a CPU gasta ciclos preciosos apenas gerenciando a movimentação de I/O (Input/Output), interrupções e trocas de contexto, em vez de executar a lógica de negócios real.

Figura: O gargalo de Von Neumann: uma representação visual da desproporção entre a capacidade massiva de armazenamento e a via estreita de transporte para a CPU.

O barramento PCIe 5.0 e o iminente 6.0 são rápidos, mas não são mágicos. Se você precisa varrer um Data Lake de 100TB para encontrar registros de uma data específica, a abordagem tradicional exige ler tudo, trafegar tudo pelo barramento, alocar na DRAM e deixar a CPU filtrar. É um desperdício de recursos computacionais e energéticos que não podemos mais sustentar.

O SSD como um computador: CSDs e FPGAs

A resposta da indústria é o Computational Storage Drive (CSD). Imagine um SSD NVMe Enterprise que, além dos chips de memória NAND Flash e do controlador tradicional, possui um motor de computação dedicado. Pode ser um núcleo ARM, um processador RISC-V ou, mais comumente em cenários de alta performance, um FPGA (Field-Programmable Gate Array).

Neste novo paradigma, o "host" (o servidor principal) envia uma pergunta ao disco, não uma ordem de leitura. Em vez de dizer "leia os blocos de 0 a 10.000", o sistema operacional diz: "envie-me apenas as linhas onde a coluna 'DATA' é igual a '2024'".

O SSD processa isso internamente. O FPGA varre os dados brutos na velocidade da interface da NAND (que é muito mais rápida que o PCIe), filtra o lixo e devolve ao host apenas o resultado refinado. O tráfego no barramento cai drasticamente. A carga na CPU principal desaparece.

💡 Dica Pro: Em ambientes de banco de dados como PostgreSQL ou MySQL, o uso de Pushdown Predicates (empurrar a query para o disco) pode acelerar consultas analíticas em até 10x, liberando a CPU do servidor para lidar com mais conexões simultâneas.

Tipos de processamento In-Situ

Não estamos falando de transformar o SSD em um PC completo, mas de descarregar tarefas específicas e intensivas de dados. Existem duas categorias principais de implementação que vemos ganhando tração:

Fixed Function (Função Fixa): O drive vem de fábrica programado para fazer uma coisa muito bem. Geralmente compressão/descompressão transparente, criptografia avançada ou erasure coding. O host nem sabe que isso está acontecendo; ele apenas vê um disco mais rápido e com mais espaço lógico.
Programmable (Programável): Aqui reside a verdadeira revolução. O drive possui um ambiente de execução (como um container Linux leve ou um kernel eBPF) onde os desenvolvedores podem implantar microcódigo. Você pode rodar uma função de transcodificação de vídeo ou uma inferência de IA simples diretamente no armazenamento.

Tabela Comparativa: SSD Tradicional vs. Computational Storage

Para visualizar o impacto na infraestrutura, comparemos o fluxo de uma operação de busca em Big Data:

Característica	SSD NVMe Tradicional	Computational Storage (CSD)
Movimentação de Dados	Envia 100% dos dados brutos para a RAM do Host.	Envia apenas o resultado filtrado (<1% dos dados).
Gargalo Principal	Largura de banda PCIe e Latência da DRAM.	Poder de processamento interno do SSD.
Consumo de Energia	Alto (transporte de dados + CPU Host em 100%).	Baixo (processamento local eficiente + CPU Host ociosa).
Latência de Resposta	Alta (espera a transferência completa para processar).	Baixa (processamento paralelo imediato na origem).
Custo	Menor custo por unidade de drive.	Maior custo inicial, mas menor TCO (Total Cost of Ownership) sistêmico.

O desafio da padronização: SNIA e NVMe

A tecnologia é brilhante, mas a implementação tem sido um campo minado de soluções proprietárias. Até recentemente, comprar um CSD significava reescrever sua aplicação para falar com a API específica daquele fabricante. Isso é a morte para a adoção em massa em datacenters.

A SNIA (Storage Networking Industry Association) e o consórcio NVM Express intervieram para colocar ordem na casa. O desenvolvimento do NVMe Computational Storage Command Sets é vital. O objetivo é criar um padrão onde o sistema operacional possa descobrir as capacidades de computação de um drive da mesma forma que descobre sua capacidade de armazenamento.

⚠️ Perigo: Evite adotar soluções de Computational Storage que exijam drivers proprietários obscuros ou modificações profundas no Kernel do Linux, a menos que você tenha uma equipe de engenharia dedicada. Aderência aos padrões da SNIA é o único caminho para a longevidade da infraestrutura.

Estamos caminhando para um modelo onde o Kubernetes poderá orquestrar "pods de armazenamento" que não apenas guardam dados, mas executam pré-processamento antes mesmo de os dados serem servidos aos pods de aplicação.

A convergência com CXL 3.0: O futuro descentralizado

Olhando para um horizonte de 5 a 8 anos, o Computational Storage deixará de ser uma "feature de SSD" para se tornar parte fundamental da arquitetura composable (componível) habilitada pelo CXL (Compute Express Link).

O CXL 3.0 permite o que chamamos de Memory Pooling e Fabric Attached Memory. No futuro próximo, o SSD não estará mais "atrás" de uma CPU específica. Ele será um dispositivo independente conectado a um switch CXL, acessível por qualquer processador no rack.

Neste cenário, o processamento no dispositivo (Computational Storage) torna-se crítico. Se o armazenamento é compartilhado e acessado via rede (mesmo que seja uma rede PCIe/CXL de baixa latência), filtrar os dados na origem é a única maneira de evitar o congestionamento do fabric.

Figura: A arquitetura do futuro com CXL: uma malha descentralizada onde CPUs, GPUs e Nós de Armazenamento Inteligente trocam dados refinados através de um fabric de alta velocidade.

Imagine treinar uma IA generativa. Em vez de a GPU puxar terabytes de imagens cruas, os drives de armazenamento CXL pré-processam as imagens (redimensionamento, normalização) e entregam tensores prontos diretamente para a memória da GPU, ignorando totalmente a CPU central. Isso é o Santo Graal da eficiência de infraestrutura.

O fim do armazenamento passivo

Não estamos apenas adicionando um processador ao SSD; estamos redefinindo a topologia do computador. O armazenamento passivo é uma relíquia do passado. Em um mundo onde a geração de dados supera nossa capacidade de transportá-los, a única saída lógica é levar a computação até os dados.

Para arquitetos de infraestrutura e engenheiros de dados, a recomendação é clara: comecem a avaliar onde seus ciclos de CPU estão sendo gastos. Se você está queimando núcleos de processador apenas para descompactar JSONs ou filtrar logs, sua arquitetura já está obsoleta. O hardware para corrigir isso já existe; a revolução agora é de mentalidade.

Perguntas Frequentes (FAQ)

O que é Computational Storage (CS)?

É uma arquitetura revolucionária onde o processamento é realizado diretamente no dispositivo de armazenamento (SSD), utilizando FPGAs ou processadores embarcados. Isso evita a movimentação desnecessária de dados brutos para a memória principal e CPU, tratando o dado onde ele reside.

Quais são os principais benefícios do processamento in-situ?

Os ganhos são sistêmicos: redução drástica da latência de I/O (o dado não precisa viajar), diminuição significativa do consumo de energia (menos dados trafegando no barramento PCIe consomem menos eletricidade) e a liberação da CPU host para focar em lógica de negócios complexa em vez de tarefas repetitivas de filtragem.

O Computational Storage substitui a CPU tradicional?

Não. Ele atua como um co-processador especializado ou um acelerador. O CS assume tarefas específicas, massivas e repetitivas (como compressão, criptografia, transcodificação e filtragem de banco de dados), trabalhando em simbiose com a CPU principal, que continua orquestrando o sistema e rodando as aplicações.