Por qué DynamoDB se convirtió en el cuello de botella
La API de búsqueda de Perplexity procesa una carga de trabajo exigente: cada solicitud recupera aproximadamente de 100 a 120 claves de página, generalmente en lotes de 10 a 20. Cada registro tiene un promedio de unos 50 KB, lo que genera un volumen de datos sustancial por consulta. Este patrón de acceso, combinado con un índice web en rápida expansión, expuso rápidamente las limitaciones de un modelo de facturación basado en el uso.
La estructura de costos de DynamoDB factura cada byte leído o escrito. A medida que el índice de datos de Perplexity creció y el tráfico de producción se intensificó, estos costos de lectura basados en bytes escalaron linealmente, haciendo que la base de datos gestionada fuera cada vez más costosa. Esta presión económica se convirtió en un factor importante para que Perplexity reevaluara su estrategia de base de datos.
Más allá del costo, la naturaleza gestionada de DynamoDB impuso límites de control críticos. Perplexity no podía ajustar los comportamientos fundamentales de la base de datos para optimizar sus patrones de acceso específicos. Los ingenieros carecían de la capacidad para dictar:
- La ubicación de la partición en máquinas específicas
- La memoria local asignada para el almacenamiento en caché
- Qué réplica respondía a una solicitud de lectura
Esta falta de control granular, particularmente sobre la selección de réplicas, significaba que una réplica lenta podía detener una lectura por lotes completa, afectando significativamente la latencia de cola para los usuarios. Perplexity requería una solución más flexible y de mayor rendimiento.
La réplica más lenta marcaba el ritmo
Las lecturas por lotes en DynamoDB amplificaban la latencia. Una sola solicitud de búsqueda, que recuperaba de 100 a 120 claves de página en lotes de 10 a 20, significaba que una réplica lenta podía retrasar toda la solicitud, incluso si otros registros llegaban rápidamente. Este fenómeno, en el que la operación más lenta dicta el rendimiento general, se conoce como tail latency (latencia de cola).
Perplexity abordó esto construyendo CobbleDB, un almacén especializado de clave-valor en caliente. Desarrollado en Rust, CobbleDB se ejecuta sobre RocksDB, sirviendo datos directamente desde el almacenamiento NVMe local. Las claves se agrupan lógicamente por partición, lo que garantiza una localidad de datos eficiente. Esta arquitectura otorgó a Perplexity un control granular sobre el almacenamiento en caché y la ubicación de los datos, capacidades ausentes en los servicios gestionados.
Un enrutador sin estado orquesta las lecturas de CobbleDB. Envía solicitudes paralelas a múltiples réplicas y emplea hedged reads (lecturas protegidas): si una réplica se retrasa, el enrutador envía inmediatamente la misma lectura a otra réplica. Esta estrategia agresiva minimiza el impacto de los nodos lentos, reduciendo significativamente la latencia de cola para las operaciones por lotes. Este enfoque redujo la latencia media de lectura por lotes de 31.4 milisegundos a 5.6 milisegundos, y la latencia P99 de 123 milisegundos a solo 24 milisegundos, una mejora de casi cinco veces.
La victoria de 5x y lo que significan los números
El cambio de Perplexity a CobbleDB mejoró drásticamente la latencia de lectura por lotes en producción. El tiempo de respuesta medio se desplomó de 31.4 ms en DynamoDB a solo 5.6 ms. Aún más sorprendente, la latencia de cola P99, que anteriormente retrasaba las solicitudes de búsqueda completas, cayó de 123 ms a aproximadamente 24 ms, lo que marca una aceleración de aproximadamente cinco veces.
Este aumento en el rendimiento vino acompañado de una ventaja económica significativa. El modelo de costos interno de Perplexity proyectó que CobbleDB sería al menos un 20% más barato que DynamoDB en todos los niveles de compromiso. Las pruebas sintéticas validaron aún más la robustez de CobbleDB, demostrando un rendimiento estable de hasta 500,000 solicitudes por segundo sin degradación del rendimiento.
Aunque estos resultados son impresionantes, reflejan la carga de trabajo y el modelo operativo específicos de Perplexity. Su API de búsqueda única, caracterizada por lecturas por lotes de 100-120 claves de página de 50 KB en promedio cada una, se benefició directamente de la arquitectura a medida de CobbleDB, incluido el uso de hedged reads para mitigar la latencia de cola.
Este éxito no garantiza universalmente que una base de datos personalizada supere a los servicios gestionados para todos los equipos o casos de uso. La solución a medida de Perplexity se optimizó para sus necesidades precisas, aprovechando a dos ingenieros y agentes de IA para crear un sistema adaptado de forma única a su escala y factores de costo. Para obtener más detalles sobre la arquitectura, lea sobre CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Dos ingenieros, agentes de IA y la compensación oculta
El rápido desarrollo de CobbleDB destaca una nueva frontera en la ingeniería. Aproximadamente 40,000 líneas de código Rust fueron entregadas en unos dos meses por dos ingenieros, trabajando en conjunto con agentes de codificación de IA. Esta rápida ejecución subraya el potencial del desarrollo aumentado por IA.
La división del trabajo fue fundamental. Los agentes de IA se encargaron de tareas repetitivas como escribir pruebas, implementar correcciones, generar hooks de observabilidad, producir documentación y realizar el seguimiento de las tareas de CI/CD. Mientras tanto, los ingenieros humanos mantuvieron la propiedad de los elementos estratégicos:
- Diseño de arquitectura
- Revisión de código
- Puertas de despliegue
- Decisiones de producción
Esta colaboración permitió al pequeño equipo moverse con una velocidad inusual, centrando la experiencia humana en problemas de alto impacto.
Sin embargo, reemplazar un servicio gestionado como DynamoDB introduce una compensación operativa significativa. Perplexity ahora asume directamente la responsabilidad de las fallas de hardware, las copias de seguridad de datos y la garantía de una fiabilidad continua. Si bien este modelo ofrece un control y un rendimiento inigualables para cargas de trabajo especializadas de hiperescala, exige un nivel de madurez operativa y compromiso de recursos que la mayoría de las startups no pueden permitirse. El éxito de CobbleDB es un testimonio de la ingeniería a medida, pero conlleva el costo oculto de una mayor carga operativa.
Preguntas frecuentes
¿Qué es CobbleDB?
CobbleDB es el almacén clave-valor interno de Perplexity, creado para servir datos de búsqueda con menor latencia y costo que su configuración anterior de DynamoDB.
¿Cómo redujo CobbleDB la latencia?
Utiliza RocksDB en NVMe local y lecturas de réplicas en paralelo, con hedged reads que reintentan una solicitud lenta contra otra réplica.
¿Cuánto más rápido fue CobbleDB que DynamoDB?
La latencia media reportada de lectura por lotes cayó de 31.4 ms a 5.6 ms, mientras que la latencia P99 cayó de 123 ms a unos 24 ms.
¿Los agentes de IA construyeron CobbleDB de forma autónoma?
No. Los agentes ayudaron con tareas como pruebas, correcciones, monitoreo y documentación, mientras que los ingenieros diseñaron el sistema, revisaron los cambios y controlaron las versiones de producción.