CobbleDB to własny, rozproszony magazyn klucz-wartość Perplexity, przygotowany do szybkiego podawania wcześniej opracowanych fragmentów stron i osadzeń wektorowych podczas wyszukiwania AI. Perplexity podało, że po przeniesieniu części obsługi wyszukiwania z Amazon DynamoDB mediana opóźnienia odczytu spadła z 31,4 ms do 5,60 ms, a opóźnienie p99 ze 123 ms do 24,2 ms.
Nie jest to jednak nowa baza ogólnego przeznaczenia. CobbleDB ma obsługiwać konkretny, powtarzalny wzorzec odczytów zasilanych asynchronicznym potokiem przetwarzania dokumentów. To właśnie wąski zakres zadania pozwolił Perplexity podporządkować projekt szybkości odczytu.
Perplexity zbudowało CobbleDB dla wymagającego obciążenia wyszukiwania
Wartości przechowywane przez CobbleDB obejmują podzielone na fragmenty treści stron oraz wektorowe reprezentacje tych fragmentów. Klucze są haszowanymi identyfikatorami stron. Gdy wyszukiwarka potrzebuje danych, system pobiera wiele rekordów w partii zamiast obsługiwać każde żądanie jako całkowicie niezależny odczyt.
Pojedyncze żądanie Search API obejmuje około 100–120 kluczy stron, dzielonych na mniejsze partie. W opisanym środowisku produkcyjnym przeciętny element miał około 50 KB. CobbleDB korzysta z RocksDB, przechowuje często używane rekordy w pamięci, a dane spoza pamięci odczytuje z lokalnych nośników NVMe.
Perplexity wdrożyło CobbleDB dla części architektury obsługującej wyszukiwanie. Nie wynika z tego zastąpienie Amazon DynamoDB we wszystkich zastosowaniach firmy.
Zgłaszane przyspieszenie jest duże, ale pomiar nie był testem równoległym
Perplexity porównało okres działania z Amazon DynamoDB z okresem po migracji do CobbleDB. Firma podała następujące wartości dla odczytów partiami:
| Miara | Amazon DynamoDB przed migracją | CobbleDB po migracji |
| Mediana opóźnienia | 31,4 ms | 5,60 ms |
| p90 | 56,7 ms | 9,77 ms |
| p99 | 123 ms | 24,2 ms |
Mediana oznacza środkową wartość pomiarów, a p99 pokazuje granicę, poniżej której mieściło się 99% odczytów. Z podanych liczb wynika spadek mediany o około 82,2%. To wynik porównania przed migracją i po niej, przy ruchu produkcyjnym w różnych okresach, a nie jednoczesnego testu identycznego ruchu na obu systemach.
Pomiary opóźnienia wykonano przy około 200 tys. żądań na sekundę. W późniejszym teście obciążeniowym Perplexity podało osiągnięcie 500 tys. żądań na sekundę, zanim wydajność zaczęła spadać. To rezultat testu obciążeniowego, a nie deklaracja stałego ruchu produkcyjnego na takim poziomie.
Pillar, Lorry i CobbleDB dzielą między siebie pracę
Projekt rozdziela trzy etapy, które wcześniej były silniej związane ze ścieżką obsługi danych:
| Komponent | Rola w opisanej architekturze | Wykorzystywana technologia |
| Pillar | Przechowuje wersjonowany, trwały stan dokumentów, w tym metadane, fragmenty i osadzenia | YTsaurus oraz pamięć masowa HDD |
| Lorry | Odczytuje rekordy eksportu, tworzy partie dopasowane do partycji i dostarcza je do CobbleDB | Amazon S3 jako warstwa danych |
| CobbleDB | Przyjmuje przygotowane partie i obsługuje szybkie odczyty podczas zapytań | Rust, RocksDB, pamięć i lokalne NVMe |
Lorry tworzy pliki dla poszczególnych partycji, zapisuje je w Amazon S3 i rejestruje je w CobbleDB. Repliki mogą pobierać oraz stosować aktualizacje niezależnie, także wtedy, gdy jedna z nich musi nadrobić opóźnienie. Ułatwia to zarówno przyrostowe aktualizacje, jak i odbudowę większych zbiorów danych.
Każda partycja CobbleDB ma trzy repliki umieszczone na trzech różnych węzłach. Bezstanowy router haszuje klucze, grupuje odczyty według partycji i wysyła je równolegle. Preferowana jest replika w tej samej strefie dostępności; gdy odczyt z jednego węzła trwa zbyt długo, system może skierować żądanie także do innej repliki. Do pobierania wielu rekordów służy mechanizm RocksDB MultiGet.
Setki agentów kodujących pomagały, ale decyzje produkcyjne należały do ludzi
Rdzeń CobbleDB ma około 40 tys. linii kodu w Rust. Perplexity podało, że system powstał w około dwa miesiące przy pracy dwóch ludzkich inżynierów wspieranych przez setki stale działających agentów kodujących AI.
Agenci pomagali między innymi w przeglądaniu kodu, wykrywaniu ryzyka, przygotowywaniu testów i poprawek, dokumentowaniu oraz utrzymywaniu kontekstu projektu. Ludzie ustalali architekturę, przeglądali istotne zmiany i autoryzowali operacje produkcyjne. To ważne rozróżnienie: CobbleDB nie został przedstawiony jako infrastruktura uruchomiona bez ludzkiego nadzoru.
Szybkość i niższy koszt oznaczają własny ciężar operacyjny
Wewnętrzny model kosztowy Perplexity oszacował koszt warstwy przechowywania CobbleDB na co najmniej 20% niższy niż w Amazon DynamoDB przy analizowanych poziomach zobowiązań. Kalkulacja nie obejmowała kosztów pracy inżynierów związanych z utrzymaniem własnej bazy ani reagowaniem na awarie.
To sedno kompromisu. Amazon DynamoDB jest usługą zarządzaną, natomiast CobbleDB daje Perplexity kontrolę nad rozmieszczeniem partycji, pamięcią podręczną, trasowaniem i wyborem repliki. W zamian Perplexity samo utrzymuje magazyn danych i infrastrukturę potrzebną do jego działania.
CobbleDB nie wymaga transakcji ani zsynchronizowanych replik dla opisanego zadania obsługi odczytów. System dopuszcza krótkie opóźnienie między zapisem dokumentu a dostępnością nowej wersji podczas odczytu. Taki model pasuje do konkretnej ścieżki wyszukiwania Perplexity, ale nie zastępuje automatycznie rozwiązań potrzebnych aplikacjom wymagającym złożonych transakcji lub silnej spójności.
Perplexity planuje udostępnić CobbleDB jako open source
Perplexity zapowiedziało plan udostępnienia CobbleDB jako oprogramowania open source, aby inne zespoły budujące systemy wyszukiwania wykorzystujące AI mogły korzystać z podobnej warstwy przechowywania. Firma przedstawiła to jako kolejny krok projektu po wdrożeniu własnego magazynu w części produkcyjnej infrastruktury wyszukiwania.
