Warum DynamoDB zum Flaschenhals wurde
Die Search API von Perplexity verarbeitet eine anspruchsvolle Arbeitslast: Jede Anfrage ruft etwa 100 bis 120 Page Keys ab, typischerweise in Batches von 10 bis 20. Jeder Datensatz ist im Durchschnitt etwa 50 KB groß, was zu einem erheblichen Datenvolumen pro Abfrage führt. Dieses Zugriffsmuster, kombiniert mit einem schnell wachsenden Web-Index, legte die Grenzen eines nutzungsbasierten Abrechnungsmodells schnell offen.
Die Kostenstruktur von DynamoDB berechnet jedes gelesene oder geschriebene Byte. Als der Datenindex von Perplexity wuchs und der Produktionsverkehr zunahm, skalierten diese Byte-basierten Lesekosten linear, wodurch die verwaltete Datenbank immer teurer wurde. Dieser wirtschaftliche Druck wurde zu einem wesentlichen Treiber für Perplexity, seine Datenbankstrategie neu zu bewerten.
Neben den Kosten legte die verwaltete Natur von DynamoDB kritische Kontrollgrenzen fest. Perplexity konnte grundlegende Datenbankverhaltensweisen nicht anpassen, um sie für seine spezifischen Zugriffsmuster zu optimieren. Ingenieuren fehlte die Fähigkeit, Folgendes zu bestimmen:
- Partitionsplatzierung auf spezifischen Maschinen
- Lokaler Speicher, der für Caching zugewiesen wurde
- Welches Replikat auf eine Leseanfrage antwortete
Dieser Mangel an granularer Kontrolle, insbesondere bei der Replikat-Auswahl, bedeutete, dass ein langsames Replikat einen gesamten Batch-Lesevorgang verzögern konnte, was die Tail Latency für Benutzer erheblich beeinträchtigte. Perplexity benötigte eine flexiblere und leistungsfähigere Lösung.
Das langsamste Replikat gab das Tempo vor
Batch-Lesevorgänge in DynamoDB verstärkten die Latenz. Eine einzelne Suchanfrage, die 100 bis 120 Page Keys in Batches von 10 bis 20 abrief, bedeutete, dass ein langsames Replikat die gesamte Anfrage verzögern konnte, selbst wenn andere Datensätze schnell eintrafen. Dieses Phänomen, bei dem die langsamste Operation die Gesamtleistung bestimmt, ist als Tail Latency bekannt.
Perplexity begegnete dem durch den Bau von CobbleDB, einem spezialisierten Hot Key-Value Store. CobbleDB wurde in Rust entwickelt und läuft auf RocksDB, wobei Daten direkt vom lokalen NVMe-Speicher bereitgestellt werden. Keys werden logisch nach Partition gruppiert, was eine effiziente Datenlokalität gewährleistet. Diese Architektur verlieh Perplexity eine granulare Kontrolle über Caching und Datenplatzierung – Fähigkeiten, die in verwalteten Diensten fehlen.
Ein zustandsloser Router orchestriert die Lesevorgänge von CobbleDB. Er sendet parallele Anfragen an mehrere Replikate und setzt Hedged Reads ein: Wenn ein Replikat verzögert, sendet der Router sofort denselben Lesevorgang an ein anderes Replikat. Diese aggressive Strategie minimiert die Auswirkungen langsamer Knoten und reduziert die Tail Latency für Batch-Operationen erheblich. Dieser Ansatz senkte die mittlere Batch-Leselatenz von 31,4 Millisekunden auf 5,6 Millisekunden und die P99-Latenz von 123 Millisekunden auf nur 24 Millisekunden – eine fast fünffache Verbesserung.
Der 5-fache Gewinn – und was die Zahlen bedeuten
Der Wechsel von Perplexity zu CobbleDB verbesserte die Batch-Leselatenz in der Produktion drastisch. Die mittlere Antwortzeit sank von 31,4 ms bei DynamoDB auf nur 5,6 ms. Noch beeindruckender ist, dass die P99 Tail Latency – die zuvor ganze Suchanfragen aufhielt – von 123 ms auf etwa 24 ms sank, was einer etwa fünffachen Geschwindigkeitssteigerung entspricht.
Dieser Leistungsschub ging mit einem erheblichen wirtschaftlichen Vorteil einher. Das interne Kostenmodell von Perplexity prognostizierte, dass CobbleDB über alle Verpflichtungsstufen hinweg mindestens 20 % günstiger als DynamoDB sein würde. Synthetische Tests bestätigten zudem die Robustheit von CobbleDB und zeigten einen stabilen Durchsatz von bis zu 500.000 Anfragen pro Sekunde ohne Leistungsabfall.
Obwohl diese Ergebnisse beeindruckend sind, spiegeln sie Perplexity’s spezifische Arbeitslast und das operative Modell wider. Ihre einzigartige Search API, die durch Batch-Reads von 100-120 Page-Keys mit jeweils durchschnittlich 50 KB gekennzeichnet ist, profitierte direkt von der maßgeschneiderten Architektur von CobbleDB, einschließlich der Verwendung von Hedged Reads zur Minderung der Tail-Latenz.
Dieser Erfolg garantiert nicht universell, dass eine maßgeschneiderte Datenbank für jedes Team oder jeden Anwendungsfall besser abschneidet als Managed Services. Die individuelle Lösung von Perplexity wurde für ihre präzisen Anforderungen optimiert und nutzte zwei Ingenieure sowie KI-Agenten, um ein System zu entwickeln, das einzigartig auf ihre Skalierungs- und Kostenfaktoren zugeschnitten ist. Weitere Details zur Architektur finden Sie unter CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Zwei Ingenieure, KI-Agenten und der versteckte Kompromiss
Die schnelle Entwicklung von CobbleDB beleuchtet eine neue Grenze im Engineering. Etwa 40.000 Zeilen Rust-Code wurden in rund zwei Monaten von zwei Ingenieuren geliefert, die in Zusammenarbeit mit KI-Coding-Agenten arbeiteten. Diese schnelle Umsetzung unterstreicht das Potenzial für KI-gestützte Entwicklung.
Die Arbeitsteilung war entscheidend. KI-Agenten übernahmen repetitive Aufgaben wie das Schreiben von Tests, das Implementieren von Fixes, das Generieren von Observability-Hooks, das Erstellen von Dokumentationen und das Nachverfolgen von CI/CD-Follow-ups. Währenddessen behielten die menschlichen Ingenieure die Verantwortung für strategische Elemente:
- Architekturdesign
- Code-Review
- Deployment-Gates
- Produktionsentscheidungen
Diese Zusammenarbeit ermöglichte es dem kleinen Team, sich mit ungewöhnlicher Geschwindigkeit zu bewegen und menschliches Fachwissen auf Probleme mit hoher Hebelwirkung zu konzentrieren.
Der Ersatz eines Managed Service wie DynamoDB bringt jedoch einen erheblichen operativen Kompromiss mit sich. Perplexity übernimmt nun direkt die Verantwortung für Hardwareausfälle, Datensicherungen und die Sicherstellung kontinuierlicher Zuverlässigkeit. Während dieses Modell eine beispiellose Kontrolle und Leistung für spezialisierte Hyperscale-Workloads bietet, erfordert es ein Maß an operativer Reife und Ressourcenbindung, das sich die meisten Startups nicht leisten können. Der Erfolg von CobbleDB ist ein Beweis für maßgeschneidertes Engineering, aber er kommt mit den versteckten Kosten einer erhöhten operativen Belastung.
Häufig gestellte Fragen
Was ist CobbleDB?
CobbleDB ist der interne Key-Value-Store von Perplexity, der entwickelt wurde, um Suchdaten mit geringerer Latenz und niedrigeren Kosten als das vorherige DynamoDB-Setup bereitzustellen.
Wie hat CobbleDB die Latenz reduziert?
Es verwendet RocksDB auf lokalem NVMe und parallele Replica-Reads, mit Hedged Reads, die eine langsame Anfrage bei einem anderen Replica wiederholen.
Wie viel schneller war CobbleDB als DynamoDB?
Die gemeldete mittlere Batch-Read-Latenz sank von 31,4 ms auf 5,6 ms, während die P99-Latenz von 123 ms auf etwa 24 ms sank.
Haben KI-Agenten CobbleDB autonom gebaut?
Nein. Agenten unterstützten bei Aufgaben wie Tests, Fixes, Monitoring und Dokumentation, während Ingenieure das System entwarfen, Änderungen überprüften und Produktions-Releases kontrollierten.