Perplexity ha deciso che stava pagando troppo per DynamoDB e non otteneva il controllo desiderato sulle prestazioni di lettura. Pertanto, ha progettato il proprio database: CobbleDB.
Sviluppato da due ingegneri in due mesi con l’assistenza di centinaia di agenti di codifica persistenti, CobbleDB è un sistema di memorizzazione chiave-valore di circa 40.000 righe in Rust che ora gestisce parte del traffico di ricerca in produzione di Perplexity. L’azienda ha misurato una latenza media di lettura per batch pari a 5,6 millisecondi dopo il trasferimento, rispetto ai 31,4 ms su DynamoDB prima dell’aggiornamento, mentre il p99 è passato da 123 ms a 24,2 ms.
Si prevede un costo almeno inferiore del 20% rispetto a DynamoDB e l’intenzione è di open-sourcere il database in un secondo momento.
Tuttavia, il database stesso è solo una parte della storia. Il professor Andy Pavlo della CMU ha sostenuto al Percona Live all’inizio di quest’anno che i database rappresentano la sfida più difficile e importante per gli agenti di intelligenza artificiale, in parte perché gli errori che coinvolgono dati di produzione possono essere difficili o impossibili da invertire.
Perplexity ha comunque utilizzato centinaia di agenti per contribuire a costruirne uno, ma non sono stati autorizzati ad accedere ai dati di produzione.
Perché DynamoDB non riusciva a stare al passo
Ogni ricerca richiede che il livello di servizio recuperi passaggi e embeddings vettoriali pre-chunked, con una singola chiamata all’API di ricerca che estrae da 100 a 120 chiavi di pagina in lotti di 10 a 20. Ogni elemento pesa in media circa 50 KB.
DynamoDB ha fornito a Perplexity poco controllo su come gestisse le letture, il che ha significato che un replica lenta poteva bloccare l’intero processo. Inoltre, ha addebitato per il flusso costante di letture e scritture di grandi dimensioni generate dalla ricerca, dal crawling e dalla riprocessazione, rendendo difficile giustificare i costi cloud man mano che il traffico e il corpus crescevano.
Tre livelli per i dati di ricerca
La stack di archiviazione è suddivisa in tre parti. Pillar mantiene lo stato durevole dei documenti in YTsaurus su HDD, inclusi metadati versione, chunk e embeddings, mentre Lorry raggruppa gli aggiornamenti in batch specifici per partizione e li sposta tramite S3 a CobbleDB.
I dati delle pagine elaborati sono distribuiti su tre repliche per partizione, con URL hashed come chiavi e RocksDB mantiene in memoria i dati frequentemente accessibili mentre il resto rimane su NVMe locale. Le letture rimangono all’interno della stessa zona di disponibilità quando possibile, e il router può provare un’altra replica se una è lenta, evitando di bloccare il batch.
Latenza di lettura per batch circa 5 volte inferiore
Perplexity gestiva circa 200.000 richieste al secondo quando ha misurato CobbleDB a 5,6 ms per una lettura media batch, in calo dai 31,4 ms registrati su DynamoDB. Al p99, la latenza è passata da 123 ms a 24,2 ms.
In test di carico successivi, CobbleDB ha raggiunto le 500.000 richieste al secondo prima che le prestazioni iniziassero a declinare.
Il confronto deve essere preso con una grande cautela; le metriche di DynamoDB e CobbleDB non sono state testate fianco a fianco con traffico identico: i dati di DynamoDB sono stati registrati prima del passaggio, e quelli di CobbleDB successivamente. Perplexity ha eseguito in modo separato benchmark sintetici utilizzando batch di 10-15 chiavi con valori che variano da 100 byte a 100 KiB.
Gli agenti l’hanno costruito, gli ingegneri l’hanno controllato
Gli agenti hanno mantenuto il contesto attraverso le sessioni, identificando problemi con le assunzioni di ripristino e la configurazione runtime mentre lavoravano su correzioni e test. Tuttavia, non erano responsabili della gestione del database.
La proprietà ha costi a lungo termine
Completare CobbleDB in otto settimane ha risolto il collo di bottiglia ingegneristico immediato di Perplexity, ma mantenere un datastore personalizzato potrebbe rivelarsi considerevolmente più difficile. I risultati di latenza non provengono da un benchmark controllato fianco a fianco, e i risparmi previsti non includono gli ingegneri necessari per mantenere CobbleDB e rispondere quando qualcosa si rompe.
Come Shopify e Ramp, che hanno costruito agenti di codifica personalizzati attorno a modelli di terze parti, Perplexity ha mantenuto l’infrastruttura cloud ma ha sostituito un servizio gestito con qualcosa costruito per le proprie esigenze. CobbleDB dimostra come lo sviluppo assistito dall’IA stia cambiando questo calcolo, rendendo l’infrastruttura personalizzata più pratica per team ingegneristici di dimensioni più piccole.