O banco de dados da Perplexity é 5x mais rápido... Duas pessoas o construíram

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Perplexity’s database is 5x faster… Two people built it #dynamodb #aws #perplexity · Canal: Better Stack · 01:35 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Engenharia de software com IA, Inferência e otimização de modelos

Resumo

A Perplexity substituiu o DynamoDB por um armazenamento próprio de chave-valor, o Cobble DB, para reduzir custos e controlar melhor o desempenho das leituras em lote. O sistema usa RocksDB em cada nó e faz leituras em paralelo entre réplicas, podendo tentar outra réplica quando uma está lenta. Em produção, a latência mediana de leitura em lote caiu de 31,4 ms para 5,6 ms, e a latência P99 caiu de 123 ms para 24 ms. Segundo o modelo de custos da Perplexity, o Cobble DB também custa pelo menos 20% menos que o DynamoDB em todos os níveis de compromisso mencionados. Dois engenheiros desenvolveram o sistema em dois meses com ajuda de AI agents, enquanto os engenheiros mantiveram a responsabilidade pela arquitetura e pela revisão das alterações.

Pontos-chave

Uma requisição da API pode precisar de 100 a 120 chaves de páginas, divididas em lotes de 10 a 20 registros de cerca de 50 KB cada.
Como o DynamoDB cobra pelos bytes lidos e gravados, o crescimento do índice da Perplexity elevava os custos.
O Cobble DB permite à Perplexity controlar melhor o posicionamento das partições, o uso de memória para cache e as réplicas que atendem às requisições.
As leituras são executadas em paralelo entre réplicas, e uma leitura pode ser enviada a outra réplica se a primeira estiver lenta.
A latência mediana de leitura em lote caiu de 31,4 ms para 5,6 ms; a latência P99 caiu de 123 ms para 24 ms.
De acordo com o modelo de custos da Perplexity, o Cobble DB é pelo menos 20% mais barato que o DynamoDB nos níveis de compromisso citados.
O Cobble DB tem cerca de 40 mil linhas de Rust e foi desenvolvido em dois meses por dois engenheiros com ajuda de AI agents.
Os AI agents contribuíram com correções, testes, monitoramento, documentação e acompanhamento de CI e etapas de revisão; os engenheiros projetaram a arquitetura e revisaram as alterações.

Capítulos

Início	Capítulo	Resumo
00:00	Limites e custos do DynamoDB	O volume de chaves consultadas pela busca da Perplexity aumentava a conta do DynamoDB à medida que o índice crescia.
00:32	Como funciona o Cobble DB	A Perplexity criou um armazenamento de chave-valor com RocksDB e leituras paralelas entre réplicas para evitar que uma réplica lenta atrase todo o lote.
01:03	Desempenho, custos e desenvolvimento com AI agents	O Cobble DB reduziu a latência e, segundo a Perplexity, os custos, e foi construído por dois engenheiros com ajuda de AI agents.

Citações

Cada byte que você lê ou grava é cobrado. — 00:00

Se uma réplica estiver lenta demais, o Cobble DB pode enviar essa mesma leitura para outra. — 00:32

A latência mediana de leitura em lote caiu de 31,4 milissegundos para 5,6. — 01:03

O Cobble DB tem cerca de 40 mil linhas de Rust. — 01:03

Conceitos e entidades

Perplexity (empresa): Empresa que substituiu o DynamoDB pelo Cobble DB para atender às necessidades de seu índice de busca.
DynamoDB (ferramenta): Serviço gerenciado de banco de dados que a Perplexity substituiu, em parte devido aos custos de leitura e gravação.
Cobble DB (ferramenta): Armazenamento próprio de chave-valor da Perplexity, desenvolvido para melhorar o controle e o desempenho das leituras em lote.
RocksDB (ferramenta): Banco de dados usado em cada nó do Cobble DB.
Rust (conceito): Linguagem de programação usada na implementação do Cobble DB.
AI agents (conceito): Agentes de IA que auxiliaram no desenvolvimento com correções, testes, monitoramento, documentação e acompanhamento de CI e revisão.

Tradução completa (pt-BR)

00:00 A Perplexity acabou de abandonar o Dynamo DB, e dois engenheiros construíram a substituição. Mas essa nem é a parte mais surpreendente, então vamos por partes. O backend de busca da Perplexity busca muitas páginas de uma só vez. Uma única solicitação à API precisa de cerca de 100 a 120 chaves de página, divididas em lotes de 10 a 20, com cada registro tendo cerca de 50 kilobytes. E, no Dynamo DB, cada byte que você lê ou grava é cobrado. Então, à medida que o índice da Perplexity cresceu, a conta também cresceu. Mas o custo não era o único problema, porque o Dynamo DB é gerenciado.

00:32 A Perplexity não podia controlar qual máquina mantinha uma partição, quanta memória era usada para o cache ou até mesmo qual réplica respondia a uma solicitação. E, quando você lê um lote inteiro de uma vez, uma réplica lenta pode atrasar tudo. Então, a Perplexity construiu seu próprio armazenamento de chave-valor em memória, chamado Cobble DB. Cada nó roda no RocksDB. As chaves são agrupadas por partição, as leituras acontecem em paralelo entre as réplicas e, se uma delas estiver lenta demais, o Cobble DB pode enviar a mesma leitura para outra. E a diferença foi enorme. Em

01:03 produção, a latência mediana de leitura em lote caiu de 31,4 milissegundos para 5,6. O P99 caiu de 123 milissegundos para apenas 24, ou seja, ficou cerca de cinco vezes mais rápido. Embora o próprio modelo de custos da Perplexity indique que também é pelo menos 20% mais barato que o Dynamo DB em todos os níveis de compromisso atualmente. Mas há a parte sobre a qual todo mundo estava discutindo. O Cobble DB tem cerca de 40 mil linhas de, você adivinhou, Rust. E foi construído em dois meses por dois engenheiros, além de agents de IA. Esses agents

01:35 escreveram correções, testes, agents de monitoramento e documentação, e até acompanharam o CI e as etapas de revisão. Mas eles não estavam executando o sistema em produção. Os engenheiros ainda projetaram a arquitetura, revisaram as alterações e apertaram esse botão de forma explícita. Se você quiser mais análises de engenharia como esta, não deixe de se inscrever no canal Better Stack.

Transcrição original

[00:00] Perplexity just fired Dynamo DB and its replacement was built by two engineers. That’s not even the crazy thing here, so let’s break it down. Perplexity search back in fetches a lot of pages at once. A single API request needs around 100 to 120 page keys split into batches of 10 to 20 with each record around 50 kilobytes. And on Dynamo DB, every byte you read or write is billed. So as Perplexity’s index grew, so did the bill. But the cost wasn’t the only problem because Dynamo DB is managed.

[00:32] Perplexity couldn’t control which machine held a partition, how much memory was used for caching, or even which replica answered a request. And when you’re reading a whole batch at once, one slow replica can hold everything up. So Perplexity built its own key-value hot store called Cobble DB. Each node runs on RocksDB. Keys are grouped by a partition, reads happen across replicas in parallel, and if one replica is too slow, Cobble DB can send that same read to another one. And the difference here was massive. In

[01:03] production, median batch read latency dropped from 31.4 milliseconds to 5.6. P99 dropped from 123 milliseconds to just 24, so roughly five times faster. While Perplexity’s own cost model says it’s also at least 20% cheaper than Dynamo DB at every commitment lately. But there’s the part everyone was arguing about. Cobble DB is around 40,000 lines of, you guessed it, Rust. And it was built in two months by two engineers plus AI agents. Those agents

[01:35] wrote fixes, tests, monitoring agents, and docs, and even tracked CI and review gates. But they weren’t running production. The engineers still designed the architecture, reviewed the changes, and explicitly pushed on this button. If you want more engineering breakdowns like this, be sure to subscribe to the Better Stack channel.