Стоит ли хранить векторы эмбеддингов в базе PostgreSQL с помощью расширения pgvector или поручить эту задачу специализированной векторной базе данных? Техническое руководство предлагает ответить на этот вопрос с помощью измерений производительности, а не принципиальных аргументов, сравнивая pgvector с Qdrant.
Две архитектуры, одна цель
pgvector — это расширение с открытым исходным кодом для PostgreSQL версии 0.8.6, совместимое с PostgreSQL 13 и более поздними версиями, согласно его официальному репозиторию на GitHub. Оно добавляет в базу специальный тип столбца для векторов, а также функции точного и приближенного поиска ближайших соседей. Конкретно, эмбеддинг, то есть числовое представление контента в виде вектора, может храниться в той же таблице, что и связанные с ним данные, и запрашиваться с помощью обычного языка SQL. Предлагается пять функций расстояния, включая косинусное расстояние и скалярное произведение.
Специализированная векторная база данных, напротив, представляет собой отдельный сервис со своим собственным механизмом хранения, разработанный вокруг векторного поиска. В руководстве упоминаются Pinecone, Qdrant, Weaviate, Milvus и ChromaDB. Такой архитектурный выбор подразумевает развертывание, мониторинг и резервное копирование дополнительной системы, а также поддержание ее синхронизации с базой, содержащей исходные данные.
Измерения на локальной машине, затем в крупном масштабе
Руководство предлагает воспроизводимый тест на ноутбуке с использованием Docker, Python 3.10 или более поздней версии и примерно 8 ГБ свободной оперативной памяти. Набор данных синтетический: 100 000 векторов размерностью 1536, что соответствует размеру распространенной модели эмбеддингов, загруженных в обе системы с одинаковыми параметрами индекса HNSW. На таком оборудовании задержки, по словам автора, составляют от нескольких миллисекунд до нескольких десятков миллисекунд, с большими вариациями в зависимости от доступных процессора и памяти. Этот объем все еще слишком мал, чтобы сделать выводы для производственной среды.
Для ответа на этот вопрос руководство опирается на исследование, опубликованное Tiger Data. В нем рассматриваются 50 миллионов эмбеддингов Cohere размерностью 768, протестированных на машинах AWS r6id.4xlarge (16 vCPU, 128 ГБ ОЗУ) с использованием модифицированной версии инструмента ANN-Benchmarks. Руководство подчеркивает важный момент: тест проводился с pgvector в связке с pgvectorscale, расширением от Timescale, которое добавляет другой тип индекса, StreamingDiskANN, а не с одним только pgvector.
Согласно этим результатам, при полноте (recall) 99% PostgreSQL с pgvectorscale достигает 471,57 запросов в секунду против 41,47 у Qdrant. Медианная задержка почти идентична: 31,07 мс против 30,75 мс. Однако Qdrant выделяется по экстремальным задержкам: его p99 составляет 38,71 мс против 74,60 мс, а его индекс был построен за 3,3 часа против 11,1 часа. По мнению автора руководства, обе системы остаются ниже 100 мс на всех измеренных перцентилях.
Какой выбор сделать в зависимости от рабочей нагрузки
Автор руководства считает, что pgvector подходит для объемов до примерно 5–10 миллионов векторов, при умеренной конкурентной нагрузке запросов и когда команда уже хорошо знакома с PostgreSQL. Он также подчеркивает транзакционную согласованность между реляционными данными и векторами, которая позволяет обновлять документ и его вектор в рамках одной транзакции.
Напротив, специализированная база данных оправдана, согласно статье, для объемов в сотни миллионов или миллиарды векторов или при строгих требованиях к экстремальной задержке при интенсивных фильтрованных поисковых запросах, где Qdrant демонстрирует измеренное преимущество. Milvus упоминается для ускоренной индексации на GPU, а Pinecone — как полностью управляемый сервис без необходимости внутреннего администрирования.
