Почему DynamoDB стала «узким местом»
Search API компании Perplexity обрабатывает высокую нагрузку: каждый запрос извлекает примерно от 100 до 120 ключей страниц, обычно пакетами по 10–20 штук. Каждая запись весит в среднем около 50 КБ, что приводит к значительному объему данных на один запрос. Этот шаблон доступа в сочетании с быстро расширяющимся веб-индексом быстро выявил ограничения модели оплаты за использование.
Структура затрат DynamoDB предполагает оплату за каждый прочитанный или записанный байт. По мере роста индекса данных Perplexity и увеличения производственного трафика эти расходы на чтение байтов росли линейно, делая управляемую базу данных все более дорогой. Это экономическое давление стало важным стимулом для Perplexity пересмотреть свою стратегию работы с базами данных.
Помимо стоимости, управляемый характер DynamoDB накладывал критические ограничения на контроль. Perplexity не могла настраивать фундаментальные параметры базы данных для оптимизации под свои специфические шаблоны доступа. Инженеры не имели возможности определять:
- Размещение разделов на конкретных машинах
- Локальную память, выделенную для кэширования
- То, какая реплика отвечает на запрос на чтение
Отсутствие детального контроля, особенно над выбором реплик, означало, что одна медленная реплика могла заблокировать чтение всего пакета, существенно влияя на «хвостовую задержку» (tail latency) для пользователей. Perplexity потребовалось более гибкое и производительное решение.
Самая медленная реплика задавала темп
Пакетное чтение в DynamoDB увеличивало задержку. Один поисковый запрос, извлекающий от 100 до 120 ключей страниц пакетами по 10–20 штук, означал, что одна медленная реплика могла задержать весь запрос, даже если остальные записи приходили быстро. Это явление, при котором самая медленная операция определяет общую производительность, известно как хвостовая задержка.
Perplexity решила эту проблему, создав CobbleDB, специализированное хранилище типа «ключ-значение» для горячих данных. Разработанная на Rust, CobbleDB работает поверх RocksDB, предоставляя данные напрямую из локального NVMe-хранилища. Ключи логически сгруппированы по разделам, что обеспечивает эффективную локальность данных. Эта архитектура предоставила Perplexity детальный контроль над кэшированием и размещением данных — возможности, отсутствующие в управляемых сервисах.
Маршрутизатор без сохранения состояния (stateless router) управляет чтением в CobbleDB. Он отправляет параллельные запросы к нескольким репликам и использует hedged reads (дублирующие запросы): если одна реплика отстает, маршрутизатор немедленно отправляет тот же запрос на другую реплику. Эта агрессивная стратегия минимизирует влияние медленных узлов, значительно снижая хвостовую задержку для пакетных операций. Такой подход позволил сократить медианную задержку пакетного чтения с 31,4 мс до 5,6 мс, а задержку P99 — со 123 мс до всего 24 мс, что является почти пятикратным улучшением.
Пятикратный выигрыш — и что означают эти цифры
Переход Perplexity на CobbleDB значительно улучшил задержку пакетного чтения в рабочей среде. Медианное время отклика упало с 31,4 мс в DynamoDB до всего 5,6 мс. Еще более впечатляет то, что хвостовая задержка P99, которая ранее тормозила целые поисковые запросы, снизилась со 123 мс примерно до 24 мс, что означает примерно пятикратное ускорение.
Этот прирост производительности сопровождался значительным экономическим преимуществом. Внутренняя модель затрат Perplexity показала, что CobbleDB будет как минимум на 20% дешевле, чем DynamoDB на всех уровнях обязательств. Синтетические тесты дополнительно подтвердили надежность CobbleDB, продемонстрировав стабильную пропускную способность до 500 000 запросов в секунду без снижения производительности.
Хотя эти результаты впечатляют, они отражают специфическую рабочую нагрузку и операционную модель Perplexity. Их уникальный поисковый API, характеризующийся пакетным чтением 100-120 ключей страниц, каждый из которых в среднем составляет 50 КБ, получил прямую выгоду от специализированной архитектуры CobbleDB, включая использование hedged reads для снижения задержек в «хвосте» распределения (tail latency).
Этот успех не гарантирует универсально, что специально разработанная база данных будет работать лучше управляемых сервисов для каждой команды или случая использования. Индивидуальное решение Perplexity было оптимизировано под их конкретные нужды с привлечением двух инженеров и AI-агентов для создания системы, уникально подходящей для их масштаба и факторов стоимости. Подробнее об архитектуре читайте в статье CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Два инженера, AI-агенты и скрытый компромисс
Быстрая разработка CobbleDB открывает новые горизонты в инженерии. Около 40 000 строк кода на Rust были написаны примерно за два месяца двумя инженерами, работавшими в тандеме с AI-агентами для программирования. Такая скорость выполнения подчеркивает потенциал разработки с использованием AI.
Разделение труда имело решающее значение. AI-агенты выполняли повторяющиеся задачи, такие как написание тестов, исправление ошибок, создание хуков для наблюдаемости, подготовка документации и отслеживание CI/CD. В то же время инженеры-люди сохранили за собой контроль над стратегическими элементами:
- Проектирование архитектуры
- Ревью кода
- Шлюзы развертывания
- Решения, касающиеся продакшена
Это сотрудничество позволило небольшой команде двигаться с необычайной скоростью, сосредоточив человеческий опыт на задачах с высокой отдачей.
Однако замена управляемого сервиса, такого как DynamoDB, влечет за собой значительный операционный компромисс. Теперь Perplexity берет на себя прямую ответственность за аппаратные сбои, резервное копирование данных и обеспечение непрерывной надежности. Хотя эта модель предлагает непревзойденный контроль и производительность для специализированных гипермасштабируемых рабочих нагрузок, она требует уровня операционной зрелости и ресурсных затрат, которые большинство стартапов не могут себе позволить. Успех CobbleDB — это свидетельство эффективности индивидуальной инженерии, но он сопровождается скрытыми издержками в виде возросшей операционной нагрузки.
Часто задаваемые вопросы
Что такое CobbleDB?
CobbleDB — это собственное хранилище типа «ключ-значение» от Perplexity, созданное для обслуживания поисковых данных с меньшими задержками и затратами, чем их предыдущая конфигурация на базе DynamoDB.
Как CobbleDB удалось снизить задержки?
Она использует RocksDB на локальных NVMe-накопителях и параллельное чтение реплик, а также hedged reads, которые повторяют медленный запрос к другой реплике.
Насколько быстрее CobbleDB по сравнению с DynamoDB?
Сообщается, что медианная задержка пакетного чтения снизилась с 31,4 мс до 5,6 мс, а задержка P99 — со 123 мс до примерно 24 мс.
Создали ли AI-агенты CobbleDB автономно?
Нет. Агенты помогали с такими задачами, как тесты, исправления, мониторинг и документация, в то время как инженеры проектировали систему, проверяли изменения и контролировали релизы в продакшене.