turbopuffer переходить на v3: векторний індекс стає індексом другого рівня

У блозі серверної пошукової системи turbopuffer 30 вересня було опубліковано пост із заголовком „RIP, vector database". У ньому інженер компанії Ден Гаррісон описав нову архітектуру зберігання, turbopuffer v3: документи та індекси ANN більше не будуть прив'язані до векторної адреси, векторний індекс перейде на роль другорядного, а функція головного індексу перейде до нової структури.

За заявою компанії, зміна прискорить усі види пошуку, зокрема текстовий, regex та векторний, і створить основу для того, щоб значно більше SQL-запитів виконувалося швидко на turbopuffer.

Від v1 до v2

turbopuffer почав як серверна векторна база: документ складався лише з ID та вектора, оригінал даних зберігався в об'єктному сховищі, а швидкість забезпечували диски NVMe та кеші пам'яті. Вектори групувалися в ієрархічні кластери: спочатку за допомогою SPANN, пізніше — SPFresh, який компанія обрала для інкрементального індексування. Серед перших клієнтів були Cursor та Notion. Друге покоління додало фільтрацію за атрибутами та текстовий пошук BM25, потім — regex-пошук, нечіткі збіги, розріджені вектори та агрегації. Рушій також використовують для непошукових завдань, наприклад, у системі синхронізації Linear. Можливості пошуку розширювалися, але організація зберігання залишалася заснована на векторному індексі, що обмежувало плани з GROUP BY та агрегаціями.

Три проблеми

У пості названо три недоліки організації зберігання на основі векторного індексу. Перший — дублювання даних у сховищі: повний вміст документа зберігається за векторною адресою, тому багатовекторні представлення, наприклад вкладення документів або late interaction, дублюють одні й ті самі дані на кожному векторі. Другий — дублювання запису: SPFresh перебудовує кластери при кожному записі, оновленні чи видаленні, і, оскільки атрибути та інверсні індекси також прив'язані до тієї ж адреси, оновлення одного вектора може перемістити сотні атрибутів та їхні індекси. Третій — обмеження векторизації: сучасні рушії обробляють значення блоками (DuckDB використовує 2 048 рядків, ClickHouse — приблизно 65 тисяч, у блоках Lucene 256 документів), а кластери ANN turbopuffer найкраще працюють з 100-200 документами, тому бажаючі використовувати більші блоки не можуть подолати цей поріг.

Як приклад компанія наводить власний текстовий пошук: розбиття постінгів на фіксовані блоки (приблизно 256) зменшило індекс у 10 разів і прискорило запити у 20 разів.

Що далі

v3 ще не запущено в продакшені. У вересні компанія досягла важливого етапу: 100% CI-тестів успішно проходять на v3. Команда тепер переходить від коректності до швидкості та протягом наступних тижнів опублікує бенчмарки на turbopuffer.com/v3, щоб v3 досяг і перевищив продуктивність попередньої архітектури до запуску в продакшені.

За словами turbopuffer, система обслуговує понад 1 трильйон документів, обробляє понад 10 мільйонів записів за секунду та обслуговує понад 25 тисяч запитів за секунду. Для попередньої архітектури компанія довела векторний пошук до окремих індексів з понад 100 мільярдів векторів: час читання p99 становив 200 мілісекунд, а частота — понад 1000 за секунду.