Qdrant на VDS: високопродуктивна векторна БД

Що таке Qdrant?

Qdrant — високопродуктивна open-source векторна база даних, написана на Rust. Підтримує мільярди векторів, гнучку фільтрацію за метаданими і працює як окремий сервіс з REST та gRPC API.

Встановлення через Docker

docker run -d \
  --name qdrant \
  -p 6333:6333 \
  -p 6334:6334 \
  -v qdrant_storage:/qdrant/storage \
  --restart always \
  qdrant/qdrant

Робота з Qdrant із Python

>pip install qdrant-client

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(host="localhost", port=6333)

# Створення колекції
client.create_collection(
    collection_name="kb_articles",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE)
)

# Додавання векторів
client.upsert(
    collection_name="kb_articles",
    points=[
        PointStruct(id=1, vector=[0.1]*768, payload={"text": "Установка VDS"}),
    ]
)

# Пошук
results = client.search(
    collection_name="kb_articles",
    query_vector=[0.1]*768,
    limit=5
)
for r in results:
    print(r.payload["text"], r.score)

Інтеграція з LangChain

from langchain_community.vectorstores import Qdrant
from langchain_community.embeddings import OllamaEmbeddings

embeddings = OllamaEmbeddings(model="nomic-embed-text")
db = Qdrant.from_documents(
    docs,
    embeddings,
    url="http://localhost:6333",
    collection_name="my_docs"
)
retriever = db.as_retriever(search_kwargs={"k": 4})

Часті помилки під час роботи з Qdrant

«Wrong input: Vector dimension error»

Bad request: Wrong input: Vector dimension error: expected dim: 768, got 1536

Розмірність вектора в колекції жорстко задається під час її створення через VectorParams(size=...) і не може відрізнятися від розмірності ембеддингів, які ви реально надсилаєте. Помилка виникає, якщо змінили модель ембеддингів (наприклад, з 768-вимірної на 1536-вимірну), але не перестворили колекцію.

Контейнер стартує, але порт 6333 недоступний ззовні

curl: (7) Failed to connect to IP port 6333: Connection refused

Перевірте, що порт дійсно прокинуто в команді запуску (-p 6333:6333), а не лише оголошено в конфігу, і що firewall на VDS не блокує зовнішні підключення до цього порту.

Дані зникли після перестворення контейнера

Якщо контейнер запущено без volume для /qdrant/storage, усі колекції живуть лише всередині контейнера і втрачаються при його видаленні. Перевіряйте прапор -v qdrant_storage:/qdrant/storage у команді запуску перед тим, як завантажувати в базу продакшн-дані.

gRPC-клієнт не може підключитися, хоча REST працює

grpc._channel._InactiveRpcError: failed to connect to all addresses

У Qdrant два незалежні порти: 6333 для REST і 6334 для gRPC. Якщо клієнтську бібліотеку налаштовано на gRPC-режим, а прокинуто і відкрито лише порт 6333, зʼєднання падає саме так. Перевірте, який протокол реально використовує ваш клієнт, і відкрийте обидва порти, якщо потрібен gRPC.

Qdrant, Chroma і pgvector: що обрати

Усі три сховища розвʼязують завдання пошуку за векторами, але розраховані на різний обсяг даних і різний ступінь інтеграції з наявною базою.

Коли Qdrant надлишковий

Потужність продакшн-орієнтованої бази на Rust стає накладними витратами там, де вистачило б значно простішого рішення.

• Прототип або пет-проєкт з парою тисяч документів — тримати окремий сервіс заради такого обсягу нераціонально, вистачить embedded-режиму Chroma
• Дані вже живуть у PostgreSQL, і векторний пошук потрібен як доповнення — логічніше взяти pgvector і не плодити зайву інфраструктуру
• На VDS і так впритул з ресурсами — Qdrant як окремий процес вимагає додаткової памʼяті понад застосунок
• Немає завдання з фільтрацією за складними метаданими під час пошуку — простого векторного індексу в наявній базі достатньо
• Команда не готова адмініструвати ще один окремий сервіс з власним життєвим циклом і резервними копіями

Перевірка результату

Перед підключенням продакшн-навантаження варто перевірити не лише сам пошук, а й стійкість даних до перезапуску.

1. Створіть колекцію і додайте тестовий набір векторів
2. Виконайте пошук і переконайтеся, що повертаються очікувані найближчі сусіди з розумним score
3. Відкрийте дашборд /dashboard і перевірте, що колекція і кількість точок у ній відображаються вірно
4. Перезапустіть контейнер і переконайтеся, що дані нікуди не поділися
5. Перевірте обидва порти — 6333 і 6334 — якщо застосунок використовує і REST, і gRPC

За темою: простіша база для старту — Chroma DB на VDS, повне порівняння варіантів — векторні бази даних, пошук просто в PostgreSQL — pgvector.