Агентам дали писать базу Perplexity, но не запускать её

Perplexity перевела часть боевого поискового трафика с DynamoDB на собственное хранилище ключ-значение CobbleDB. Это около 40 000 строк на Rust. Написали его за два месяца два инженера с помощью сотен кодовых агентов, которые работали постоянно. Как рассказала The New Stack 16 сентября, медианное пакетное чтение после переезда стало быстрее примерно в пять раз: 5,6 мс против 31,4 мс на DynamoDB.

Новая база стоит не одна. Perplexity разнесла долговременное хранение документов и обслуживание живых запросов по разным системам, убрала поток записи с узлов, которые отвечают пользователям, и научила роутер не ждать отстающую реплику.

Почему DynamoDB перестала устраивать

Каждый поисковый запрос порождает 100-120 ключей страниц, и сервис выборки разбивает их на параллельные пакеты по 10-20 ключей. Под ключом лежит заранее нарезанный на фрагменты текст страницы вместе с векторными эмбеддингами, в среднем около 50 КБ на запись.

DynamoDB почти не давала управлять чтением. Размещение партиций, кэширование в памяти и выбор реплики скрыты от пользователя, поэтому инженеры не могли убрать всплески задержки на хвосте распределения: чтение мимо кэша, лишний сетевой переход между зонами доступности или отстающая реплика тормозили весь пакет. К этому добавлялись деньги. AWS тарифицирует каждый переданный байт, а поиск, краулинг и переобработка генерируют постоянный поток крупных чтений и записей. При трафике больше 200 000 запросов в секунду такой счёт стало трудно оправдывать, тем более что трафик и корпус продолжали расти.

Отдельной проблемой была переобработка. Когда менялся алгоритм нарезки текста или выходила новая модель эмбеддингов, задания пересчёта отправляли большие объёмы записи прямо в DynamoDB и мешали живым пользовательским запросам.

Pillar, Lorry и CobbleDB

Хранение в Perplexity теперь разделено на три системы. Pillar держит долговременное состояние документов: версионированные метаданные, фрагменты и эмбеддинги. Он работает на YTsaurus поверх ёмких HDD.

Lorry связывает Pillar с CobbleDB. Это потребитель очереди без собственного состояния: он собирает выгрузки из Pillar в пакетные файлы, разложенные по партициям CobbleDB, кладёт их в Amazon S3 и отправляет в CobbleDB уведомление с метаданными. Рабочие узлы CobbleDB сами забирают пакеты из S3 и применяют их независимо друг от друга. Тяжёлый поток записи от краулера так отделён от узлов, которые отвечают на запросы, а реплика может отстать и потом догнать остальные, никого не блокируя.

Сам CobbleDB - распределённое хранилище, заточенное только под пакетные выборки. На каждую партицию приходится три реплики, синхронизация между ними асинхронная, поэтому согласованность итоговая: свежая запись становится видна на всех репликах не сразу. Ключами служат хэши URL страниц. Внутри узла данные хранит встроенный движок RocksDB: часто запрашиваемое держится в памяти, остальное лежит на локальных NVMe-дисках, а ключи пакета достаются за один вызов через интерфейс MultiGet.

Перед узлами стоит роутер без состояния. Он сопоставляет хэш страницы с партицией и по возможности отправляет запрос в реплику из той же зоны доступности. Если реплика начинает отвечать медленнее обычного, роутер параллельно шлёт тот же запрос в другую реплику на другом узле, и пакет не стоит в ожидании отстающей.

Задержки и деньги

Задержки CobbleDB сняты при нагрузке примерно 200 000 запросов в секунду: медиана пакетного чтения снизилась с 31,4 до 5,6 мс, p90 с 56,7 до 9,77 мс, p99 со 123 до 24,2 мс. Цифры DynamoDB при этом записаны до переезда, а CobbleDB после, бок о бок на одинаковом трафике системы не сравнивали. Отдельно Perplexity гоняла синтетические бенчмарки на пакетах по 10-15 ключей со значениями от 100 байт до 100 КиБ. В более поздних нагрузочных тестах CobbleDB дошла до 500 000 запросов в секунду, после чего производительность начала падать.

По модели затрат Perplexity, CobbleDB обходится минимум на 20% дешевле DynamoDB при всех рассмотренных вариантах обязательств по объёму. В эту оценку не входят расходы на инженеров, которые будут поддерживать базу и чинить её, когда что-то сломается. Исходный код компания собирается открыть, сроки не названы.

Что досталось агентам

Профессор Университета Карнеги-Меллон Энди Павло ранее в этом году на конференции Percona Live называл базы данных самой трудной и самой важной задачей для ИИ-агентов, в частности потому, что ошибку с боевыми данными бывает сложно или невозможно откатить.

Агенты Perplexity переносили контекст из сессии в сессию. Они находили проблемы в допущениях о восстановлении данных и в конфигурации среды выполнения, писали исправления и тесты. Ключей от продакшена им не дали: архитектура и боевая система оставались под контролем двух инженеров.