Qdrant - Vector Database
ACORN, Inline Storage и Gridstore
Qdrant v1.16-17 - не просто новые фичи API. Это фундаментальные изменения в том, как данные хранятся и как граф обходится. Понимание этих изменений позволяет выжать максимум из hardware.
- Multi-tenant RAG: 10M документов, 100K пользователей — ACORN держит recall на уровне
- On-disk коллекция на NVMe: Inline Storage снижает disk reads в 16 раз
- Real-time индексация: Gridstore убирает latency spikes от RocksDB compaction
Предварительные знания
ACORN: восстановление recall при жёстких фильтрах
Классическая проблема HNSW с фильтрами: если фильтр очень restrictive (например, `user_id = 'alice'`), большинство соседей в графе будут отфильтрованы. HNSW начинает «буксовать» - у него нет переходов к нужным точкам, и recall резко падает до 60-70%.
**ACORN** (Approximate Closest-to-Object Reachability Navigation), добавленный в Qdrant v1.17, решает эту проблему. Идея: когда прямой сосед в графе отфильтрован, ACORN проверяет **2-hop соседей** - соседей соседей. Это значительно расширяет множество доступных точек при той же структуре HNSW графа.
| Сценарий | Без ACORN | С ACORN | Overhead |
|---|---|---|---|
| Нет фильтра | ~99% recall | ~99% recall | 0% |
| Мягкий фильтр (50% точек) | ~95% recall | ~98% recall | +10-20% |
| Жёсткий фильтр (1% точек) | ~60% recall | ~95% recall | +2-10x |
| Очень жёсткий (0.1% точек) | ~30% recall | ~90% recall | +5-20x |
ACORN значительно медленнее при очень restrictive фильтрах - в 5-20 раз по сравнению с поиском без фильтра. Это компромисс: recall vs latency. Для критически latency-sensitive случаев рассмотрите **tenant-based** архитектуру с отдельными коллекциями на пользователя.
Как ACORN восстанавливает recall при restrictive фильтрах в HNSW?
Inline Storage: векторы прямо в узлах графа
До Qdrant v1.16 при поиске с on-disk коллекциями каждое посещение узла HNSW графа требовало **двух операций**: 1. Чтение структуры графа (ссылки на соседей) - один random I/O 2. Чтение вектора точки из отдельного файла - ещё один random I/O Для глубокого HNSW поиска (ef=128) это означает ~256 random disk reads. На HDD - катастрофа. На NVMe SSD - всё равно медленно.
**Inline Storage** (v1.16+): квантизованные векторы хранятся непосредственно в узлах HNSW графа, в том же блоке данных. Чтение узла = чтение и структуры графа, и вектора за одну операцию. Для поиска с memmap (on-disk): было 32 random reads → стало 2 page reads.
**Когда Inline Storage даёт максимальный выигрыш:** - on_disk коллекции (vectors on disk + graph on disk) - Коллекции крупнее RAM сервера - NVMe SSD (не HDD - там latency слишком высок даже с Inline) - Квантизация включена (int8 или binary)
В каком сценарии Inline Storage даёт наибольший прирост производительности?
Gridstore: замена RocksDB для payload и sparse
До v1.16 Qdrant использовал **RocksDB** для хранения payload и sparse векторов. RocksDB - LSM-tree: отличен для read-heavy workloads, но имеет write amplification (каждый байт записывается несколько раз при compaction) и unpredictable latency spikes во время compaction.
**Gridstore** (v1.16+) - custom storage engine от команды Qdrant, заменяющий RocksDB. Ключевые преимущества: - **Меньше write amplification**: нет LSM compaction - **Стабильная latency**: нет latency spikes от фоновых задач - **Лучший scan**: sequential access при scroll/filter быстрее - **Меньше CPU**: нет background compaction threads
**Когда использовать все три вместе** (ACORN + Inline Storage + Gridstore): Это рекомендуемая конфигурация для **production large-scale deployment** в Qdrant v1.17+: - Большая коллекция (>10M точек), не помещается в RAM - Многопользовательская архитектура с tenant фильтрами - Write-heavy: постоянный upsert новых документов - Требования к recall ≥95% даже при restrictive фильтрах
Какую главную проблему RocksDB решает Gridstore?
Итоги
- ACORN (v1.17+): 2-hop навигация в HNSW восстанавливает recall с ~60% до ~95% при restrictive фильтрах
- Inline Storage (v1.16+): квантизованный вектор хранится в узле графа — disk reads при on-disk поиске снижаются в 16 раз
- Gridstore (v1.16+): замена RocksDB без LSM compaction — стабильная latency, меньше write amplification
- Большой m в HNSW (32 вместо 16) улучшает ACORN — больше 2-hop путей через граф
- Все три вместе — рекомендуемая конфигурация для large-scale on-disk multi-tenant коллекций
Что дальше
Вы прошли весь advanced курс по Qdrant. Возможные направления для углублённого изучения.
- Performance Tuning — Практические параметры для настройки Qdrant под нагрузку
- Quantization — Детальное понимание квантизации - основа для Inline Storage
- HNSW — Детали алгоритма HNSW - основа для понимания ACORN
Вопросы для размышления
- При каком размере коллекции вы бы включили on_disk для векторов? Какой порог memmap_threshold выбрать?
- Как бы вы измерили реальный прирост производительности от Inline Storage в вашей системе? Какие метрики смотреть?
- Если ваш сервис резко вырос с 1M до 50M документов — в каком порядке вы бы применили ACORN, Inline и Gridstore?