Qdrant - Vector Database
Distributed Mode и Шардирование
Ваша коллекция выросла до 50M векторов - один сервер не справляется. Distributed mode позволяет разбить данные по нодам и масштабироваться горизонтально. Но главный вопрос не технический - правильно ли настроены шарды? Один неверный выбор при создании коллекции - и придётся пересоздавать всё с нуля.
- **Документальный поиск на 100M документов:** 10 нод × 10 шардов, поиск параллельно - latency как у single-node с 10M
- **SaaS с 500 клиентами:** Custom sharding по tenant_id - изоляция данных, поиск только по шардам нужного клиента
- **Горячая замена оборудования:** move_shard переносит данные с умирающего диска на новую ноду без downtime
Предварительные знания
Шардирование: как Qdrant распределяет данные
**Distributed mode** позволяет Qdrant работать как кластер нескольких нод. Каждая коллекция разбивается на **шарды** (shards) - независимые части данных. Каждый шард живёт на одной ноде (или реплицируется на несколько).
**Количество шардов** определяется при создании коллекции и не меняется (без ребалансировки). По умолчанию - 1 шард. Правило: создавайте столько шардов, сколько нод планируется в кластере, или кратно числу нод.
**Выбор числа шардов:** `shard_number = number_of_nodes` - простое правило для старта. Если планируете масштабировать до 6 нод - создайте 6 шардов сразу. Изменить шарды без пересоздания коллекции нельзя.
У вас кластер из 4 нод. Коллекция создана с shard_number: 2. Как распределятся шарды?
Custom Sharding для мультитенантности
**Custom Sharding (shard_key)** позволяет явно контролировать в каком шарде хранятся точки. Главное применение - **мультитенантность**: изолировать данные разных клиентов по шардам для производительности и простоты управления.
**Custom Sharding vs Payload-фильтрация для мультитенантности:** Payload-фильтр (`must: [{key: 'tenant_id', match: {value: 'alpha'}}]`) работает, но фильтрует ПОСЛЕ загрузки всех кандидатов - шарды alpha и beta читаются оба. Custom Sharding изолирует на уровне хранилища - beta-шарды не трогаются вообще. При 100+ тенантах custom sharding в разы эффективнее.
SaaS-платформа: 50 клиентов, каждый с ~100k документов. Итого 5M документов. Как лучше организовать мультитенантность?
Управление кластером: ноды, ребалансировка шардов
**Управление кластером** включает: добавление нод, перемещение шардов между нодами, вывод ноды из эксплуатации. Qdrant предоставляет REST API для всех операций - можно автоматизировать через Kubernetes operators или свои скрипты.
**Нельзя уменьшить shard_number** для существующей коллекции. Если хотите объединить шарды - нужно создать новую коллекцию с меньшим shard_number и перенести данные через snapshot. Планируйте число шардов с запасом при создании коллекции.
Вы добавили 4-ю ноду в кластер (было 3 ноды, 3 шарда). Как получить равномерное распределение шардов?
Ключевые идеи
- **Шарды** - части коллекции, распределённые по нодам. По умолчанию: consistent hashing по point_id
- **shard_number** задаётся при создании коллекции и не меняется без пересоздания. Планируйте с запасом
- **Custom Sharding** (shard_key) - явный контроль: идеально для мультитенантности, изоляция на уровне хранилища
- **move_shard** - горячее перемещение шардов между нодами без downtime. Методы: stream_records (live), snapshot
- **Raft consensus** управляет метаданными кластера. Добавление нод - через bootstrap URI
Что дальше
Данные распределены по шардам - теперь нужно обеспечить отказоустойчивость через репликацию.
- Репликация и Raft — Шарды без репликации - single point of failure. Replication factor защищает от потери ноды
- Cloud vs Self-Hosted — Distributed mode - это self-hosted. Cloud автоматически управляет шардами
- Мониторинг кластера — В distributed mode нужно мониторить каждую ноду и состояние шардов
Вопросы для размышления
- У вас коллекция с shard_number: 3 и кластер из 6 нод. Каждый шард реплицирован дважды (replication_factor: 2). Сколько физических копий каждого шарда существует? На скольких нодах может работать коллекция при выходе 2 нод?
- Custom sharding vs отдельные коллекции для мультитенантности: когда каждый подход предпочтительнее? Какие операционные компромиссы?
- Почему нельзя изменить shard_number без пересоздания коллекции? Что технически мешает Qdrant делать ребалансировку автоматически как в Elasticsearch?