stamatios
← Voltar ao feed
Ventilador turbo gira sobre fileiras de gavetas de aço organizadas, banco chave-valor TurboKV escrito em Rust
Open Source · Dev & Engenharia

TurboKV traz banco chave-valor embutido e assíncrono em Rust

resumo de ~3 min

O que é o TurboKV

TurboKV é um banco de dados chave-valor embutido e assíncrono escrito em Rust, distribuído sob licença Apache-2.0 na versão 0.6. Ele oferece batches atômicos, varreduras ordenadas por intervalo, durabilidade configurável, compressão e compactação em segundo plano. A instalação é feita via cargo add turbokv, com dependência do runtime Tokio. O formato persistido usa filtro de Bloom com AES de hardware, e o README orienta compilar com flags específicas de AES em alvos x86/x86_64 e ARM/AArch64.

Presets de durabilidade

A biblioteca expõe três presets de DbOptions. O modo fast() desabilita o WAL e garante apenas visibilidade em memória, voltado a caches. O modo durable(), recomendado como padrão, grava registros no WAL sem sincronização a cada escrita, permitindo recuperação de queda de processo com checkpoints periódicos contra perda de energia. O modo paranoid() executa sync_all do grupo do WAL antes de retornar, oferecendo a garantia mais forte, sujeita aos limites do sistema de arquivos e do dispositivo.

O modo durable não deixa o WAL sem sincronizar indefinidamente: flushes explícitos ou em segundo plano e o fechamento limpo sincronizam os dados, e a rotação de segmento completo do WAL também. Com os padrões, a memtable gira em torno de 64 MiB, a tarefa em segundo plano verifica memtables imutáveis a cada 60 segundos e o segmento do WAL gira em 1 GiB. O documento ressalva que esses checkpoints não impõem um limite exato de perda de 64 MiB, pois o flush é assíncrono, a contabilidade de memória é aproximada e uma mutação grande pode cruzar o limite.

API e operações

Chaves e valores são sequências arbitrárias de bytes via AsRef<[u8]>, com codificação de strings por conta do chamador. As operações incluem insert, insert_many (em massa, sem transição atômica de visibilidade), get, remove (gravação de tombstone), take (retorno e remoção atômicos), contains_key e write_batch, que publica todas as operações atomicamente - leitores veem o estado anterior ou o batch completo.

Com o WAL habilitado, um registro ou batch completo precisa caber no limite de payload u32 do WAL. Uma mutação falha ou cancelada pode já ter chegado ao WAL, e o README recomenda inspecionar a chave ou reabrir antes de repetir operações não idempotentes.

As varreduras ordenam chaves lexicograficamente por bytes brutos e capturam uma visão coerente de um ponto no tempo. Há versões que alocam tudo de imediato (range, scan_prefix) e iteradores de streaming, cujo avanço é síncrono e pode envolver leituras via mmap, validação de checksum, descompressão e bloqueio de cache. Iteradores devem ser descartados rapidamente, pois fixam leitores do snapshot e a posse do diretório.

A biblioteca também expõe flush(), compact() (com relatório de arquivos, bytes, duração e tombstones recuperados), status(), logical_stats() e physical_stats(). A abertura de um Db tem posse exclusiva do diretório de dados, e descartar o handle não constitui encerramento limpo - é preciso usar close() ou close_with_status().

Benchmarks

Os benchmarks comparam TurboKV 0.6.0, fjall 2.11.2 e redb 2.6.3 em três repetições, medindo chaves reconhecidas por segundo. No preenchimento sequencial de uma chave por transação, TurboKV Fast registrou 2.989.537 e Durable 1.774.574, contra 485.252 do fjall Buffer e apenas 1.397 do redb Eventual. Em batches de 1.000 chaves, TurboKV Durable alcançou 2.380.390 e Paranoid 162.938.

O protocolo usou 200.000 chaves determinísticas de 20 bytes com valores de 400 bytes (84 MB lógicos, acima da memtable de 64 MiB), compressão e cache de blocos desabilitados e cache de páginas do sistema operacional não limpo. O documento faz uma ressalva importante: o redb com Durability::Eventual executa um F_BARRIERFSYNC do macOS a cada transação, então seus números de chave única são contexto arquitetural, não comparação de durabilidade equivalente; tempos consolidados entre motores não são comparados.

As medições foram feitas em 28 e 29 de agosto de 2026, em um Apple M4 com 32 GiB de RAM, macOS 15.3.2, APFS e rustc 1.88.0, com artefatos JSON e relatórios textuais disponíveis no repositório.