ИИтог

turbopuffer строит v3: ANN-индекс перестанет быть основным

инфраструктураРедакция ИИтогHacker News🔥74Рейтинг ИИтог74Влияние65Новизна70Релевантность88Неожиданность60Участники45Достоверность87

turbopuffer рассказал в блоге, что меняет архитектуру хранения данных. Версия v3 меняет то, как документы и индексы раскладываются, записываются, уплотняются (compaction) и опрашиваются. Цель: ускорить все виды поиска (текстовый, по регулярным выражениям, векторный) и заложить основу, чтобы переносить в turbopuffer и ускорять больше SQL-запросов.

История такая. Первая версия (v1) была серверной векторной базой, заточенной под дешёвый и достаточно быстрый векторный поиск: источником истины служило объектное хранилище, а скорость давали многоуровневые кэши на NVMe SSD и в памяти. Эти компромиссы подтвердили самые первые клиенты, среди них Cursor и Notion. Во второй версии (v2) появился сильный текстовый поиск и поиск по регулярным выражениям, а сервис стали использовать и не для поиска, например в движке синхронизации Linear. Но хранилище почти не менялось: векторный индекс ANN был и остаётся основным индексом, вокруг которого строятся все остальные индексы и планы запросов. Из-за этого, как пишут авторы, ограничены некоторые планы запросов, например GROUP BY и агрегации.

Устройство v1: использовался иерархический кластерный индекс (сначала SPANN, затем SPFresh для инкрементальной индексации), потому что он лучше подходит объектному хранилищу, чем графовые индексы. Векторы собираются в кластеры, центроиды кластеров кластеризуются снова, и так до единственного корня. Всё хранится в key-value-слое с ключами по ClusterId и LocalId, вместе их называют ANN-адресом. На этот адрес ссылаются инвертированные индексы по атрибутам и полнотекстовый индекс BM25, там же лежит содержимое документа. Позже добавились агрегации, поиск по регулярным выражениям, нечёткий поиск, разреженные векторы и сортировка по атрибутам, и всё это построено на той же векторной раскладке.

Почему основной индекс не трогали: он очень хорошо работает для ANN-поиска в объектном хранилище. На нём turbopuffer довёл векторный поиск до отдельных индексов в 100 млрд и более векторов с задержкой чтения 200 мс (p99) при 1 тыс. и более запросов в секунду. Любое серьёзное изменение грозит регрессиями.

Но у раскладки три проблемы для невекторных запросов. Первая: избыточное хранение. Если у документа несколько векторов (вложенные документы, late interaction), содержимое приходится дублировать для каждого вектора, отсюда часть неприятных лимитов продукта. Вторая: избыточная запись. Любая вставка, обновление или удаление может запустить перебалансировку SPFresh, а так как всё ключуется по ANN-адресу, перемещается и документ целиком, и ссылающиеся на него инвертированные индексы: обновление одного вектора может сдвинуть сотни атрибутов и их индексов. Усилия по настройке пропускной способности индексации уже дают убывающую отдачу. Третья: ограниченная векторизация. Современные движки обрабатывают блоки значений (DuckDB пакетами по 2048 строк, ClickHouse до ~65 тыс., блоки списков вхождений в Lucene по 256 документов), а ANN-индекс лучше всего работает с кластерами в 100, 200 документов, и все планы запросов привязаны к этому размеру. Пример выигрыша от отвязки: первая версия полнотекстового поиска делила списки вхождений по границам ANN-кластеров, и медианный блок содержал лишь ~1,5 вхождения. FTS v2 перешёл на фиксированные блоки ~256, индекс стал в 10 раз меньше, а запросы до 20 раз быстрее. Агрегации и другие сканирования читают сами документы, которые лежат по одному блоку на кластер, поэтому им такое ускорение пока недоступно.

Решение, по словам авторов, простое: не ключевать данные по ANN-адресу. Именно это делает v3, и это нетривиальное изменение. По их словам, v3 даст заметный прирост скорости на всех планах запросов. Недавний рубеж: 100% тестов CI проходят на v3 (месяц в тексте не назван, сказано «ранее в этом месяце»). Пока команда занималась корректностью, теперь будет заниматься скоростью. Бенчмарки обещают опубликовать в ближайшие недели, а в продакшен v3 выведут после достижения паритета по производительности. Конкретной даты и описания нового основного индекса в тексте нет: это первое сообщение серии.

В целом turbopuffer сообщает, что хранит более 1 трлн документов, обрабатывает более 10 млн записей в секунду и более 25 тыс. запросов в секунду.

Ключевые факты

  • В turbopuffer v3 ANN-индекс перестаёт быть основным и становится «просто ещё одним» вторичным индексом; данные больше не ключуются по ANN-адресу.
  • Причины: дублирование содержимого при нескольких векторах у документа, усиление записи (обновление одного вектора может сдвинуть сотни атрибутов и их индексов) и размер блоков, привязанный к кластерам в 100, 200 документов.
  • Прецедент: FTS v2 с фиксированными блоками ~256 сделал индекс в 10 раз меньше, а запросы до 20 раз быстрее.
  • На v3 проходят 100% тестов CI, но это показатель корректности, а не скорости; бенчмарки обещаны в ближайшие недели, в продакшене v3 пока нет.
  • Текущая архитектура обслуживает отдельные индексы в 100 млрд и более векторов с задержкой 200 мс (p99) при 1 тыс. и более запросов в секунду; задача v3 не ухудшить эти показатели.

Почему это важно

turbopuffer называет себя быстрым поисковым движком, а векторные базы данных часто начинали как узкоспециализированные системы. Здесь компания открыто говорит, что архитектура, выстроенная вокруг векторного индекса, исчерпала себя для невекторных запросов, и переходит к универсальному хранилищу, где векторный поиск лишь один из индексов. Это показательный пример того, как специализированная векторная база эволюционирует в более общую систему поиска и аналитики: цель авторов, в том числе перенести в turbopuffer больше SQL-запросов и сделать их быстрыми.

Кому это важно

Инженерам, которые строят поиск и ретривал для ИИ-приложений на объектном хранилище, и тем, кто выбирает или эксплуатирует векторные базы. Особенно тем, кто упирается в лимиты на документы с несколькими векторами, медленные агрегации или GROUP BY. Также будет полезно тем, кто интересуется устройством индексов (кластерные векторные индексы, инвертированные индексы, BM25, векторизованные движки).

Как это применить

Прямо сейчас применять нечего: v3 ещё не в продакшене, и в тексте не названо, использует ли её кто-то из клиентов. Практический вывод для пользователей turbopuffer: следить за обещанными бенчмарками и за сроками вывода v3. Для всех остальных пост даёт ориентир, как рассуждать о раскладке данных: если все индексы привязаны к адресу вектора, любые перебалансировки индекса порождают лишние записи, а размеры блоков диктует векторный индекс.

Можно ли доверять

Это блог самого turbopuffer, то есть заявления разработчиков о своём продукте; независимых измерений нет. Имя автора и дата публикации в тексте не указаны. Цифры про 100 млрд векторов и 200 мс относятся к текущей архитектуре, а не к v3. Показатель 100% CI говорит только о корректности. Прирост «до 20 раз» для FTS v2 максимальный, а не типичный. Обещание значительного прироста скорости на v3 пока ничем не подтверждено: бенчмарков нет.

Риски и подводные камни

Сами авторы называют переход нетривиальным и признают риск: любое существенное изменение основного индекса может привести к регрессиям в ANN-производительности, поэтому до вывода в продакшен они ставят цель достичь паритета. Пока неизвестны ни сроки, ни устройство нового основного индекса, ни реальные цифры производительности. Выводить v3 в продакшен без публичных бенчмарков и сравнения с v2 пока рано; описание в посте это только заявка на то, что получится.

«Мы довели архитектуру с векторным индексом в основе до предела, и пора двигаться дальше.»

— turbopuffer, запись в блоге