Google запускает предварительную версию AlloyDB HNSW, увеличивая пропускную способность поиска в 4 раза

Репортаж от Wedoany，Google запускает в предварительной версии функцию HNSW с ускорением на колоночном движке для AlloyDB, заявляя о повышении пропускной способности векторного поиска до четырех раз.

AlloyDB — это управляемая служба баз данных Google, совместимая с PostgreSQL. Новая опция предназначена для пользователей pgvector — расширения PostgreSQL для хранения, индексации и запросов векторных эмбеддингов для приложений искусственного интеллекта, особенно для команд, использующих HNSW (Hierarchical Navigable Small World, иерархический навигационный малый мир) для выполнения поиска приблизительных ближайших соседей на сверхбольших наборах данных.

Новая опция использует колоночный движок AlloyDB — кэш в памяти, хранящий часто запрашиваемые данные в колоночном формате, — чтобы удерживать индекс HNSW в памяти, избегая некоторых накладных расходов стандартного управления буферами PostgreSQL. Google заявляет, что это повышает пропускную способность и полноту (метрику, измеряющую количество релевантных совпадений в результатах поиска). В тестах на наборе данных GloVe 100 Angular, содержащем более 1 миллиона записей, при ограничении поиска до 100 и целевой полноте 0,95 количество запросов в секунду увеличилось примерно в 4,2–4,9 раза. При одинаковом уровне пропускной способности полнота также улучшилась: при примерно 350 запросах в секунду после включения колоночного движка полнота выросла с примерно 0,78 до более чем 0,94, увеличившись на 0,163.

Что касается принципа работы, стандартный PostgreSQL полагается на общий буферный кэш для операций с индексами, даже если данные уже находятся в памяти. Этот процесс все еще включает фиксацию и открепление страниц, обработку блокировок, поиск в таблице буферов и управление по алгоритму LRU (наименее недавно использовавшийся), что может увеличить задержку и снизить эффективность во время обхода графа. AlloyDB изменяет этот путь, фиксируя индекс pgvector HNSW непосредственно в пространстве памяти колоночного движка и используя макет памяти, специально разработанный для шаблонов обхода с интенсивным использованием указателей, необходимых для HNSW, обходя обычные узкие места менеджера буферов. Google отмечает, что это улучшение связано не просто с перемещением данных с диска в ОЗУ; базовое сравнение уже предполагало, что стандартный индекс PostgreSQL полностью кэширован в общем буфере, что означает, что заявленный прирост производительности обусловлен другой архитектурой памяти, а не базовым кэшированием.

Этот релиз отражает растущее давление на поставщиков баз данных по поддержке генерации с расширенным поиском (RAG) и других рабочих нагрузок ИИ, зависящих от векторного поиска. В таких системах операторам часто приходится балансировать между скоростью и точностью при поиске по миллионам или миллиардам векторов, особенно под производственной нагрузкой. Для пользователей PostgreSQL pgvector стал одним из наиболее широко используемых инструментов в этой области, поскольку он позволяет выполнять векторные функции в рамках существующего стека реляционных баз данных. HNSW — популярный метод индексации в pgvector, поскольку он обеспечивает приблизительный поиск с меньшей задержкой, чем точный метод k-ближайших соседей, хотя операторы обычно идут на некоторые компромиссы по полноте.

Google позиционирует AlloyDB как базу данных, способную обрабатывать реляционные транзакции, аналитику и векторный поиск в одной системе. Помимо HNSW, служба также поддерживает ScaNN (другой вариант векторного индекса), в то время как стандартный поиск k-ближайших соседей остается доступным для пользователей, которым требуется полная полнота.

Что касается эксплуатационных компромиссов, колоночный движок использует память, что остается практическим соображением для операторов баз данных, управляющих затратами и размерами экземпляров. Google заявляет, что благодаря хранению векторных данных в сжатом колоночном формате занимаемая память ограничена. Google считает, что этот компромисс позволяет достичь заданного уровня производительности векторного поиска с использованием меньших вычислительных ресурсов, тем самым снижая потребности в инфраструктуре. Эта функция не требует изменения кода приложения, поскольку пользователи могут продолжать использовать стандартный синтаксис SQL pgvector. Чтобы воспользоваться этой функцией, пользователи AlloyDB должны включить колоночный движок и флаг кэширования индексов на своем экземпляре, а после создания индекса HNSW через pgvector добавить этот индекс в кэш колоночного движка с помощью команды SQL.

Этот релиз предоставляет Google еще один способ дифференцировать AlloyDB на растущем рынке баз данных, адаптированных для рабочих нагрузок ИИ, где облачные провайдеры и специализированные команды баз данных конкурируют по пропускной способности, задержке и качеству поиска. Эталонные тесты, на которые ссылается Google, проводились на машине AlloyDB C4A с 16 виртуальными процессорами.