O que é RocksDB? O armazenamento chave-valor incorporado

O que é RocksDB?

RocksDB é um armazenamento chave-valor persistente e incorporável, otimizado para armazenamento rápido. Ele recebe chaves e valores como arrays arbitrários de bytes, mantém esses dados ordenados e os armazena de forma durável em disco. 

O mais importante a entender desde o início é que RocksDB é uma biblioteca, não um servidor. Não há processo ao qual se conectar, porta para abrir nem linguagem de consulta para aprender.

RocksDB se integra a uma aplicação e é executado dentro do processo dela, lendo e gravando arquivos no disco local. É isso que torna RocksDB rápido: não há um salto de rede entre o código da aplicação e os dados que ele manipula. Ele é minimalista porque deixa intencionalmente a replicação, o particionamento e as consultas para o que for construído sobre ele.

Em resumo, RocksDB é um mecanismo de armazenamento: o componente central sobre o qual bancos de dados como TiDB e YugabyteDB são construídos.

RocksDB é igual ao LevelDB?

Não, mas ambos têm origem na mesma base de código. RocksDB surgiu em 2012 como um fork do LevelDB, o armazenamento chave-valor leve criado por Jeff Dean e Sanjay Ghemawat no Google. 

LevelDB foi criado para ambientes modestos, como o backend IndexedDB de um navegador ou um único dispositivo embarcado. Por isso, adotou várias decisões de design adequadas a esses cenários, incluindo compactação em uma única thread, uso conservador de memória e poucas opções de ajuste.

Os engenheiros do Facebook, hoje Meta, usaram essa base e a reconstruíram para cargas de trabalho de servidores. A missão era aproveitar ao máximo o hardware moderno e, ao mesmo tempo, lidar com conjuntos de dados muito maiores que a memória sob pressão contínua de escrita. 

RocksDB teve seu código aberto publicado em 2013 e se distanciou bastante do LevelDB. Ele passou a oferecer compactação multithread, famílias de colunas, transações, backups, operadores de mesclagem, estilos de compactação plugáveis e uma lista notoriamente extensa de opções de ajuste.

LevelDB e RocksDB têm semelhanças familiares, mas tratá-los como intercambiáveis deixou de ser razoável há uma década.

Como RocksDB funciona?

RocksDB é baseado em uma árvore de mesclagem estruturada em log (árvore LSM), uma estrutura de dados que troca a simplicidade de leitura por maior throughput de escrita. 

Basicamente, as escritas recebidas são registradas em um buffer na memória chamado memtable. Ao mesmo tempo, elas são acrescentadas a um log de escrita antecipada em disco para garantir durabilidade. 

Quando a memtable fica cheia, ela é congelada e descarregada no disco como um arquivo imutável e ordenado chamado Sorted String Table (SST). Os arquivos SST se acumulam em uma hierarquia de níveis, enquanto um processo em segundo plano chamado compactação os mescla continuamente, descartando valores sobrescritos e chaves excluídas para manter uma estrutura organizada, ordenada e durável.

As leituras verificam primeiro a memtable e depois percorrem os diferentes níveis de arquivos SST. Os filtros de Bloom permitem que RocksDB ignore arquivos que não podem conter a chave, enquanto um cache de blocos mantém os dados mais acessados na memória. Assim, a maioria das leituras nunca precisa acessar mais do que um ou dois arquivos.

Qual é a diferença entre árvores LSM e árvores B?

As árvores B, estrutura usada pela maioria dos bancos de dados tradicionais, atualizam os dados no próprio local, o que espalha escritas aleatórias pelo disco. As árvores LSM acrescentam dados e os processam em lotes, resultando em grandes escritas sequenciais — exatamente o que SSDs e cargas com alto volume de ingestão exigem. A contrapartida é que o valor atual de uma chave pode estar distribuído entre vários arquivos, exigindo compactação, filtros de Bloom e cache para manter esse custo sob controle. 

Cada decisão de design em uma árvore LSM acaba equilibrando três pressões:

• Amplificação de escrita
• Amplificação de leitura
• Amplificação de espaço

Melhorar duas delas tende a piorar a terceira. 

Esse triângulo é o modelo mental mais importante para entender os ajustes do RocksDB. 

Para que RocksDB é usado?

RocksDB é usado sempre que uma aplicação precisa de armazenamento chave-valor rápido, durável e ordenado no disco local, sem a sobrecarga de executar um servidor de banco de dados separado. Exemplos concretos deixam esse padrão mais claro do que categorias.

Kafka Streams mantém o estado de cada tarefa de processamento — agregações em andamento, joins e cálculos em janelas — em um armazenamento RocksDB local. Isso permite que o estado cresça além da memória e sobreviva a reinicializações sem acrescentar uma viagem de ida e volta pela rede a cada consulta.

O ZippyDB da Meta envolve RocksDB com uma camada de replicação, gerenciamento de shards e serviços de configuração para oferecer um armazenamento chave-valor distribuído e totalmente gerenciado. A divisão de responsabilidades é clara: RocksDB fornece o armazenamento, enquanto toda a estrutura de servidor é construída ao redor dele.

A camada de armazenamento do TiDB executa RocksDB em cada node como mecanismo subjacente de um banco de dados SQL distribuído. Ela codifica a estrutura das tabelas em prefixos de chave para que a varredura de uma tabela se torne uma única leitura contígua sobre chaves ordenadas.

Todo validador da Solana baseado em Agave grava o ledger no RocksDB, usando o slot como chave para que dados consecutivos do ledger fiquem adjacentes no disco.

Os dois últimos exemplos são interessantes porque as chaves são armazenadas em ordem — por byte, como padrão, ou por um comparador personalizado —, o que torna eficientes as varreduras de intervalos e as buscas por prefixo.

Grande parte do design de esquemas em sistemas reais baseados em RocksDB se resume a explorar essa ordenação.

Quem usa RocksDB?

Além dos sistemas acima, RocksDB é fundamental para qualquer sistema que precise de um mecanismo de armazenamento incorporado, comprovado em produção e otimizado para escrita. As equipes o escolhem porque podem aproveitar uma década de robustez em produção desenvolvida pela Meta, em vez de criar um mecanismo do zero.

Entre os principais exemplos,

• Kafka Streams o utiliza como mecanismo padrão para armazenamentos de estado
• Apache Flink oferece um backend de estado do RocksDB para estados com checkpoint grandes demais para permanecer na memória
• MyRocks o incorpora como um mecanismo de armazenamento do MySQL, desenvolvido na Meta para reduzir o espaço de armazenamento de algumas das maiores frotas de MySQL existentes
• A camada de armazenamento do TiDB, TiKV, usa RocksDB com instâncias separadas para logs do Raft e dados chave-valor
• O armazenamento de documentos do YugabyteDB, DocDB, usa RocksDB
• O BlueStore do Ceph usa RocksDB para metadados de armazenamento de objetos
• ArangoDB oferece RocksDB como seu mecanismo de armazenamento padrão desde a versão 3.4 e como seu único mecanismo desde a versão 3.7

RocksDB é usado principalmente em cargas de trabalho com muitas escritas, maiores que a memória e executadas em SSDs — um ponto ao qual voltaremos mais adiante neste artigo.

Como a Solana usa RocksDB?

Solana é uma blockchain de alto desempenho e baixa latência baseada em Prova de Participação, conhecida por seu foco em velocidade, eficiência e aplicações para consumidores. O ledger da Solana reside no RocksDB. O cliente validador Agave armazena o ledger no Blockstore, um componente que contém um banco de dados RocksDB dividido em espaços de chaves independentes e ajustáveis. 

Famílias de colunas separadas armazenam dados de shreds, códigos de correção de erros dos shreds — ou seja, as unidades brutas dos dados do ledger conforme chegam pela rede —, status de transações, índices de endereços para assinaturas e diversos metadados.

O padrão de escrita de um validador é extremo em comparação com a maioria das cargas de trabalho de bancos de dados. Um validador precisa ingerir shreds continuamente, indexados por números de slot que aumentam de forma quase monotônica, na velocidade máxima da rede, para sempre. Um arquivo não podado do ledger ultrapassa facilmente centenas de terabytes e cresce, no mínimo, dezenas de terabytes por ano.

Com a compactação em níveis, as famílias de colunas de shreds geraram tanto trabalho de compactação em segundo plano que os validadores começaram a sofrer pausas de escrita, o mecanismo integrado do RocksDB para desacelerar a ingestão quando a compactação fica para trás. 

Por volta de 2021, as famílias de colunas de shreds migraram para a compactação FIFO, um estilo mínimo que simplesmente exclui o arquivo mais antigo quando o limite de tamanho é atingido. Em geral, FIFO não é seguro para cargas de trabalho genéricas. No entanto, como as chaves dos shreds chegam em uma ordem de slots quase monotônica, os validadores podiam descartar o arquivo mais antigo, pois ele continha os slots mais antigos. Isso alinhou quase perfeitamente o estilo de compactação ao formato da carga de trabalho.

Otimizações posteriores na compactação em níveis reduziram sua amplificação de I/O a ponto de FIFO deixar de oferecer vantagens. Por isso, o caminho FIFO foi descontinuado em junho de 2024 e removido em novembro daquele ano.

Firedancer, o cliente validador da Solana da Jump Crypto escrito em C, abandona completamente RocksDB em favor de uma camada de armazenamento interna e desenvolvida especificamente para essa finalidade.

Saber se um mecanismo de armazenamento criado do zero pode superar uma década de robustez e ajustes do RocksDB é uma questão em aberto e interessante na engenharia de validadores.

Quando RocksDB é a ferramenta errada?

RocksDB é a ferramenta errada com mais frequência do que sua ampla adoção sugere. A superfície de configuração é enorme, com centenas de opções cujas interações não são óbvias. Por isso, uma configuração inadequada tende a ser o resultado padrão, não a exceção. 

Além disso, as configurações padrão do RocksDB são razoáveis, mas não ideais. Para obter ganhos reais de desempenho, os desenvolvedores precisam entender as compensações de amplificação descritas acima. Uma ingestão intensa e contínua pode superar a compactação em segundo plano, provocando pausas de escrita que tendem a ocorrer justamente quando o sistema está mais ocupado.

Além do mais, RocksDB é uma biblioteca, não um servidor. Tudo o que um servidor de banco de dados comum forneceria — como replicação, particionamento, backups, controle de acesso, uma camada de consulta e ferramentas operacionais — precisa ser construído.

O formato da carga de trabalho também faz uma enorme diferença. 

RocksDB é um mecanismo orientado a linhas, consultas pontuais e varreduras de intervalos. Cargas analíticas que examinam grandes faixas de dados e agregam informações entre colunas são mais bem atendidas por um armazenamento colunar como ClickHouse.

Nada disso é motivo para evitar RocksDB. É, na verdade, motivo para escolhê-lo de forma deliberada. Na Helius, avaliamos esses riscos diretamente ao reformular nossa camada de arquivamento e escolher RocksDB, pois a carga de trabalho tinha exatamente o formato para o qual RocksDB foi criado: consultas pontuais e varreduras de intervalos estreitos em um grande conjunto de dados com uso intenso de acréscimos. 

Conclusão

RocksDB é um armazenamento chave-valor incorporável, persistente e ordenado que troca conveniências operacionais por desempenho bruto no disco local. Ele surgiu do LevelDB, foi aprimorado na Meta para SSDs e máquinas com múltiplos núcleos e hoje está presente em vários sistemas ao redor do mundo, de processadores de streams e bancos de dados SQL distribuídos a clusters de armazenamento e ao ledger da Solana.

Se trabalhar em configurações de RocksDB de alto desempenho e em grande escala parece empolgante, venha construir conosco.

A Solana avança rapidamente para se tornar a camada de liquidação das finanças globais, e a infraestrutura por trás dela utiliza exatamente os mecanismos descritos nesta série. Resolva problemas complexos de sistemas em escala planetária usando alguns dos melhores hardwares que o dinheiro pode comprar.

Estamos contratando para diversas posições em nossa equipe de engenharia. Veja todas as vagas abertas em helius.dev/careers.