Векторная база данных нужна там, где обычный WHERE title LIKE '%...%' не находит смысл, а находит только точное совпадение букв. Эмбеддинг превращает текст, картинку или аудио в вектор чисел, а векторная БД быстро ищет соседние по смыслу записи среди миллионов. Три самых частых кандидата на VDS — Qdrant, Weaviate и Milvus. Разберём, чем они отличаются на практике и что поставить в вашем случае.
Что такое векторная база данных и зачем она нужна
Классический индекс ищет точное вхождение строки. Векторный индекс ищет ближайшие точки в многомерном пространстве по метрике расстояния — косинусной близости или евклидовой. Запрос тоже превращается в вектор той же модели эмбеддингов, а база возвращает top-k ближайших записей за миллисекунды даже на десятках миллионов векторов.
Такой поиск лежит в основе RAG-систем, рекомендаций, дедупликации и поиска похожих изображений. Выбор конкретной базы влияет на потребление RAM, скорость записи и сложность эксплуатации на своём сервере.
Qdrant: простота и низкий порог входа
Qdrant написан на Rust, ставится одним бинарником или Docker-контейнером и не требует внешних зависимостей вроде ZooKeeper или etcd. Хранит векторы вместе с payload-полями и поддерживает фильтрацию по метаданным прямо во время поиска, а не после него.
docker run -d --name qdrant \
-p 6333:6333 -p 6334:6334 \
-v /opt/qdrant/storage:/qdrant/storage \
qdrant/qdrant:latestНа VDS с 4 ГБ RAM Qdrant спокойно держит коллекцию на пару миллионов векторов размерности 768. Подробная установка описана в статье про настройку Qdrant на VPS.
Weaviate: модули и встроенная векторизация
Weaviate написан на Go и добавляет слой модулей: можно подключить векторизацию текста через внешний API прямо внутри базы, не гоняя данные через отдельный сервис эмбеддингов. Схема данных строится через классы с типизированными свойствами, что удобно, если у записи много атрибутов помимо вектора.
Из минусов — Weaviate требовательнее к памяти при большом числе классов и активнее использует GraphQL-интерфейс, который придётся освоить отдельно от привычного REST.
Milvus: масштабирование для больших нагрузок
Milvus рассчитан на десятки и сотни миллионов векторов и распределённую архитектуру: отдельные узлы для приёма записи, индексации и запросов. Такая схема оправдана на кластере из нескольких серверов, но на одном VDS добавляет накладные расходы — Milvus в docker-compose поднимает etcd и MinIO как обязательные зависимости.
wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -dStandalone-режим Milvus снимает часть сложности, но всё равно потребляет больше RAM в простое, чем Qdrant или Weaviate на той же задаче.
Сравнение по ключевым параметрам
| Параметр | Qdrant | Weaviate | Milvus |
|---|---|---|---|
| Язык реализации | Rust | Go | Go + C++ |
| Зависимости для старта | нет | нет | etcd, MinIO |
| RAM в простое | от 200 МБ | от 400 МБ | от 1.5 ГБ |
| Фильтрация по payload | да, встроена | да, через классы | да, через схему |
| Лучше всего подходит | один сервер, RAG | сложная схема данных | кластер, сотни млн векторов |
Что поставить на свой VDS
Для чат-бота с базой знаний, поиска по каталогу товаров или личного проекта на VDS с 4-8 ГБ RAM разумный выбор — Qdrant: минимум движущихся частей, один процесс, понятный REST API. Если данные уже структурированы как объекты со множеством связанных свойств и хочется встроенную векторизацию — берите Weaviate. Milvus имеет смысл только при явном плане роста до кластера и десятков миллионов записей, иначе его etcd и MinIO будут просто съедать ресурсы впустую.
Как альтернативу без отдельного сервиса стоит рассмотреть pgvector в PostgreSQL, если у проекта уже есть эта СУБД и нагрузка не превышает пары миллионов записей.
- До 2-5 млн векторов, один сервер — Qdrant.
- Сложная схема объектов, нужна встроенная векторизация — Weaviate.
- Кластер, десятки-сотни миллионов векторов — Milvus.
- Проект уже на PostgreSQL, нагрузка небольшая — pgvector вместо отдельной БД.
Чек-лист перед выбором
Прежде чем разворачивать любую из баз, оцените три вещи: сколько векторов будет через год, сколько свободной RAM есть на сервере и нужна ли фильтрация по метаданным на каждом запросе. Ошибка на этом шаге стоит дороже, чем миграция данных между базами — формат векторов у всех разный, и придётся заново гонять эмбеддинги.
- Посчитайте прогнозируемое число векторов и их размерность.
- Проверьте свободную RAM: Milvus без запаса памяти будет падать по OOM.
- Решите, нужна ли фильтрация по полям вместе с векторным поиском.
- Начните с Qdrant, если сомневаетесь — миграция на более тяжёлое решение проще, чем откат с него.
Частые вопросы
Можно ли мигрировать данные между Qdrant, Weaviate и Milvus позже, если выбор окажется неверным?
Прямой перенос данных между этими базами не предусмотрен штатными средствами, поскольку внутренний формат хранения векторов и индексов у каждой реализации свой. Миграция фактически означает заново прогнать все объекты через ту же модель эмбеддингов и загрузить получившиеся векторы в новую базу через её API, а не скопировать файлы — это нужно закладывать в оценку рисков при выборе.
Как векторный поиск соотносится с полнотекстовым — нужно выбирать между ними?
Полнотекстовый поиск и векторный решают разные задачи и чаще дополняют друг друга, а не заменяют: полнотекстовый находит точные слова и фразы, векторный — записи, близкие по смыслу, даже при другой формулировке. Многие проекты комбинируют оба подхода — сначала сужают выборку текстовым фильтром, затем ранжируют оставшееся векторным сходством, получая и точность, и гибкость одновременно.
Что произойдёт, если модель эмбеддингов сменится позже — придётся переделывать всю базу?
Смена модели эмбеддингов требует пересчитать векторы для всех существующих записей — старые и новые векторы несовместимы между собой, даже если размерность совпадает случайно, потому что числа кодируют смысл по-разному. На практике это означает прогнать весь корпус данных через новую модель заново и либо перезаписать коллекцию, либо создать её рядом и переключиться после полного пересчёта.
Нужна ли отдельная векторная база, или достаточно расширения для уже имеющейся реляционной СУБД?
Отдельная векторная база оправдана, когда нагрузка на поиск становится основной частью системы или данных становится по-настоящему много: специализированное хранилище эффективнее использует память и быстрее отвечает именно на такие запросы. Пока проект уже работает на реляционной СУБД и объём записей умеренный, расширение существующей базы векторным расширением избавляет от лишнего сервиса и его администрирования.