Qdrant - Vector Database
Репликация и Отказоустойчивость
Нода ушла в 3 часа ночи. Ваши пользователи видят ошибки или нет? Ответ определяется не реакцией дежурного, а тем как был настроен replication_factor при создании коллекции. В распределённых системах отказоустойчивость - это архитектурное решение, принятое заранее.
- **Production readiness:** replication_factor: 2, write_consistency: 1 - базовый минимум. Выдерживает одновременный отказ 1 ноды без потери доступности
- **E-commerce с транзакциями:** write_consistency: quorum гарантирует что добавленный в корзину товар не пропадёт при перезагрузке страницы
- **Multi-region HA:** replication_factor: 3 по 3 датацентрам - переживёт отказ целого датацентра
Предварительные знания
Replication Factor: копии шардов на нескольких нодах
**Репликация** в Qdrant - это копирование каждого шарда на несколько нод. `replication_factor: 2` означает: каждый шард существует на 2 нодах. Если одна нода падает - данные доступны на второй.
**Сценарии с разными replication_factor:**
| replication_factor | Нод в кластере | Выживает при отказе | Накладные расходы на запись |
|---|---|---|---|
| 1 | 1+ | 0 нод (нет отказоустойчивости) | Минимальные |
| 2 | 2+ | 1 ноды из 2 | ×2 на записи |
| 3 | 3+ | 1 ноды из 3 (или 2 при strong consistency) | ×3 на записи |
| 3 + write_consistency: 2 | 3+ | 1 ноды, запись подтверждается 2 репликами | ×3 запись, кворум |
Кластер: 3 ноды, shard_number: 3, replication_factor: 2. Одна нода (node2) упала. Сколько шардов теперь имеют только 1 реплику?
Raft: консенсус для метаданных кластера
**Raft** - алгоритм консенсуса, используемый Qdrant для синхронизации метаданных кластера: список нод, коллекции, конфигурация шардов. Raft гарантирует что все ноды видят одинаковое состояние.
**Quorum и доступность:** при потере кворума (> N/2 нод) Qdrant не может изменять метаданные (создавать коллекции, менять конфигурацию). Но **чтение и запись данных** продолжают работать на оставшихся нодах - в зависимости от `write_consistency_factor`.
**Число нод и отказоустойчивость по Raft:** 2 ноды - кворум 2, если 1 упала - cluster без лидера (нет изменений схемы). 3 ноды - выдерживает отказ 1 ноды. 5 нод - выдерживает 2 ноды. Нечётное число нод всегда лучше чётного для Raft: 4 ноды выдерживают только 1 отказ, как 3 ноды - зачем платить за 4-ю?
Кластер из 4 нод. Вышли из строя 2 ноды. Что происходит с Qdrant?
Консистентность vs Доступность: CAP в Qdrant
**CAP-теорема** применима к распределённому Qdrant: нельзя одновременно гарантировать Consistency и Availability при сетевом разделении. Qdrant даёт вам выбор через `write_consistency_factor` и `read_consistency`.
| Сценарий | write_consistency_factor | read consistency | Компромисс |
|---|---|---|---|
| Кэш похожих изображений | 1 | weak | Максимальная скорость, возможны мелкие расхождения |
| Поисковый движок документов | 1 | medium | Хороший баланс для большинства задач |
| Read-after-write гарантии | 2 | strong | Latency выше, но нет stale reads |
| Финансовые/медицинские данные | quorum | quorum | Максимальная консистентность, меньшая доступность |
**Сценарий потери данных:** replication_factor: 2, write_consistency_factor: 1. Запись подтверждена replica-A. Replica-B ещё не получила данные. Replica-A падает. Данные потеряны - replica-B не знает об этой записи. Если это критично - используйте write_consistency_factor: 2 (или 'quorum').
«replication_factor защищает от потери данных»
replication_factor защищает от потери доступности (нода упала - другие ноды отвечают). Но с write_consistency_factor: 1 возможна потеря данных при падении ноды ДО завершения репликации. Для защиты данных нужно write_consistency_factor: quorum.
Репликация и durability - разные гарантии. Репликация: «данные на нескольких нодах». Durability: «данные сохранены надёжно». С write_consistency: 1 запись может подтвердиться до распространения на все реплики - это асинхронная репликация.
Пользователь добавляет документ, затем сразу делает поиск. С настройками write_consistency: 1, read consistency: 'weak' - пользователь может не найти только что добавленный документ. Как это исправить наименее затратным способом?
Ключевые идеи
- **replication_factor** - сколько копий каждого шарда. 2+ = отказоустойчивость. Устанавливается при создании коллекции
- **Raft** управляет метаданными кластера через консенсус. Нечётное число нод (3, 5) лучше чётного
- **write_consistency_factor:** 1 = высокая доступность, quorum = надёжность данных. Выбирайте под требования
- **read consistency:** weak (быстро) / strong (гарантия актуальности). Можно задавать на уровне запроса
- **Потеря данных** возможна при write_consistency: 1 + нода падает до репликации. Для критических данных - quorum
Что дальше
Репликация настроена - теперь нужно видеть что происходит внутри кластера. Мониторинг метрик и алерты.
- Мониторинг и Prometheus — Следить за здоровьем реплик и шардов через метрики
- Distributed Mode — Шардирование - основа для репликации
- Настройка производительности — Репликация влияет на write-latency - учитывать при оптимизации
Вопросы для размышления
- Объясните разницу между replication_factor и write_consistency_factor. Можно ли иметь write_consistency_factor > replication_factor? Что произойдёт?
- В CAP-теореме Qdrant с write_consistency: quorum - это CP или AP система? Обоснуйте. Как меняется ответ при write_consistency: 1?
- Как убедиться что репликация работает корректно? Опишите тест: что нужно проверить, как симулировать отказ ноды, как проверить целостность данных после восстановления.