A Perplexity migrou sua camada central de busca do Amazon DynamoDB para o CobbleDB, armazenamento chave-valor interno escrito em Rust. A mudança cortou a latência de leitura em lote em cinco vezes e reduziu ao menos os custos de armazenamento.
Por que o dynamodb virou um gargalo para a Perplexity
Cada consulta à Perplexity gera entre 100 e 120 chaves de páginas alvo, divididas em lotes paralelos de 10 a 20 chaves. A recuperação para LLMs extrai passagens completas e embeddings densos, com registros médios de cerca de 50 kilobytes.
Com tráfego acima de 200 mil requisições por segundo, a cobrança por byte transferido do DynamoDB ficou insustentável. A caixa-preta do serviço também impedia controle sobre latência de cauda e contenção com jobs de reprocessamento.
Leia também
Cloudflare redesenha cache DNS do 1.1.1.1 em Rust e libera 100 tb de memória
Como a nova arquitetura se divide em três sistemas
O Pillar roda sobre YTsaurus em discos mecânicos e mantém tabelas versionadas de metadados, passagens e vetores, com transações atômicas.
O Lorry agrupa exportações em arquivos em lote alinhados por partição, guarda payloads no Amazon S3 e avisa o CobbleDB, que ingere os lotes isolado do pipeline de escrita.
Cobbledb e os números em produção
O CobbleDB usa RocksDB sobre NVMe local, três réplicas por partição, roteamento por zona de disponibilidade e leituras especulativas quando uma réplica fica lenta. A interface batched MultiGet elimina round-trips.
| Métrica | DynamoDB | CobbleDB |
|---|---|---|
| Latência mediana | ||
| Latência p90 | ||
| Latência p99 | 123 ms |
Arraste para o lado para ver toda a tabela.
A latência mediana caiu de para, o p90 de para e o p99 de 123 ms para, com throughput de até 500 mil requisições por segundo em benchmarks.
Leia também:
Fonte: Infoq
