Pourquoi DynamoDB est devenu le goulot d'étranglement
L'API de recherche de Perplexity traite une charge de travail exigeante : chaque requête récupère environ 100 à 120 clés de page, généralement par lots de 10 à 20. Chaque enregistrement pèse en moyenne environ 50 Ko, ce qui entraîne un volume de données substantiel par requête. Ce modèle d'accès, combiné à un index web en expansion rapide, a rapidement exposé les limites d'un modèle de facturation basé sur l'utilisation.
La structure de coûts de DynamoDB facture chaque octet lu ou écrit. À mesure que l'index de données de Perplexity augmentait et que le trafic de production s'intensifiait, ces coûts de lecture basés sur les octets ont évolué de manière linéaire, rendant la base de données gérée de plus en plus coûteuse. Cette pression économique est devenue un moteur important pour que Perplexity réévalue sa stratégie de base de données.
Au-delà du coût, la nature gérée de DynamoDB imposait des limites de contrôle critiques. Perplexity ne pouvait pas ajuster les comportements fondamentaux de la base de données pour optimiser ses modèles d'accès spécifiques. Les ingénieurs manquaient de la capacité de dicter :
- Le placement des partitions sur des machines spécifiques
- La mémoire locale allouée à la mise en cache
- Quel réplica répondait à une requête de lecture
Ce manque de contrôle granulaire, en particulier sur la sélection des réplicas, signifiait qu'un réplica lent pouvait bloquer une lecture par lots entière, impactant considérablement la latence de queue pour les utilisateurs. Perplexity avait besoin d'une solution plus flexible et performante.
Le réplica le plus lent donnait le rythme
Les lectures par lots dans DynamoDB amplifiaient la latence. Une seule requête de recherche, récupérant 100 à 120 clés de page par lots de 10 à 20, signifiait qu'un réplica lent pouvait retarder toute la requête, même si les autres enregistrements arrivaient rapidement. Ce phénomène, où l'opération la plus lente dicte la performance globale, est connu sous le nom de latence de queue (tail latency).
Perplexity a résolu ce problème en construisant CobbleDB, un magasin clé-valeur à chaud spécialisé. Développé en Rust, CobbleDB fonctionne sur RocksDB, servant les données directement depuis le stockage NVMe local. Les clés sont logiquement regroupées par partition, assurant une localité efficace des données. Cette architecture a accordé à Perplexity un contrôle granulaire sur la mise en cache et le placement des données, des capacités absentes dans les services gérés.
Un routeur sans état orchestre les lectures de CobbleDB. Il envoie des requêtes parallèles à plusieurs réplicas et utilise des lectures couvertes (hedged reads) : si un réplica est à la traîne, le routeur envoie immédiatement la même lecture à un autre réplica. Cette stratégie agressive minimise l'impact des nœuds lents, réduisant considérablement la latence de queue pour les opérations par lots. Cette approche a fait passer la latence médiane de lecture par lots de 31,4 millisecondes à 5,6 millisecondes, et la latence P99 de 123 millisecondes à seulement 24 millisecondes — une amélioration de près de cinq fois.
La victoire 5x — et ce que les chiffres signifient
Le passage de Perplexity à CobbleDB a considérablement amélioré la latence de lecture par lots en production. Le temps de réponse médian a chuté de 31,4 ms sur DynamoDB à seulement 5,6 ms. Plus frappant encore, la latence de queue P99 — qui bloquait auparavant des requêtes de recherche entières — est passée de 123 ms à environ 24 ms, marquant une accélération d'environ cinq fois.
Ce gain de performance s'est accompagné d'un avantage économique significatif. Le modèle de coût interne de Perplexity a projeté que CobbleDB serait au moins 20 % moins cher que DynamoDB sur tous les niveaux d'engagement. Des tests synthétiques ont en outre validé la robustesse de CobbleDB, démontrant un débit stable allant jusqu'à 500 000 requêtes par seconde sans dégradation des performances.
Bien que ces résultats soient impressionnants, ils reflètent la charge de travail et le modèle opérationnel spécifiques de Perplexity. Leur API de recherche unique, caractérisée par des lectures par lots de 100 à 120 clés de page d'une moyenne de 50 Ko chacune, a directement bénéficié de l'architecture sur mesure de CobbleDB, notamment grâce à l'utilisation de « hedged reads » pour atténuer la latence de queue.
Ce succès ne garantit pas universellement qu'une base de données personnalisée surpassera les services gérés pour chaque équipe ou cas d'utilisation. La solution sur mesure de Perplexity a été optimisée pour leurs besoins précis, s'appuyant sur deux ingénieurs et des agents IA pour concevoir un système parfaitement adapté à leur échelle et à leurs facteurs de coûts. Pour plus de détails sur l'architecture, lisez CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Deux ingénieurs, des agents IA et le compromis caché
Le développement rapide de CobbleDB met en lumière une nouvelle frontière en ingénierie. Environ 40 000 lignes de code Rust ont été livrées en près de deux mois par deux ingénieurs, travaillant en tandem avec des agents de codage IA. Cette exécution rapide souligne le potentiel du développement assisté par l'IA.
La division du travail a été cruciale. Les agents IA ont géré les tâches répétitives telles que l'écriture de tests, la mise en œuvre de correctifs, la génération de hooks d'observabilité, la production de documentation et le suivi des étapes CI/CD. Pendant ce temps, les ingénieurs humains ont conservé la responsabilité des éléments stratégiques :
- Conception de l'architecture
- Revue de code
- Portes de déploiement
- Décisions de production
Cette collaboration a permis à la petite équipe d'avancer avec une vitesse inhabituelle, en concentrant l'expertise humaine sur des problèmes à fort levier.
Cependant, remplacer un service géré comme DynamoDB introduit un compromis opérationnel significatif. Perplexity assume désormais directement la responsabilité des pannes matérielles, des sauvegardes de données et de la garantie d'une fiabilité continue. Bien que ce modèle offre un contrôle et des performances inégalés pour des charges de travail hyperscale spécialisées, il exige un niveau de maturité opérationnelle et d'engagement en ressources que la plupart des startups ne peuvent se permettre. Le succès de CobbleDB témoigne de l'ingénierie sur mesure, mais il s'accompagne du coût caché d'une charge opérationnelle accrue.
Questions fréquemment posées
Qu'est-ce que CobbleDB ?
CobbleDB est le magasin clé-valeur interne de Perplexity, conçu pour servir les données de recherche avec une latence et un coût inférieurs à ceux de leur configuration précédente sur DynamoDB.
Comment CobbleDB a-t-il réduit la latence ?
Il utilise RocksDB sur NVMe local et des lectures de réplicas en parallèle, avec des « hedged reads » qui relancent une requête lente sur un autre réplica.
À quel point CobbleDB était-il plus rapide que DynamoDB ?
La latence médiane rapportée pour les lectures par lots est passée de 31,4 ms à 5,6 ms, tandis que la latence P99 est passée de 123 ms à environ 24 ms.
Les agents IA ont-ils construit CobbleDB de manière autonome ?
Non. Les agents ont assisté sur des tâches telles que les tests, les correctifs, la surveillance et la documentation, tandis que les ingénieurs ont conçu le système, examiné les changements et contrôlé les mises en production.