## Зачем Embedding-модели (text-embedding-3, CLIP, BERT) превращают текст/картинку в **вектор float[384..1536]**, где «семантически близкое» = «близкое по cosine». Хранить эти вектора в Postgres и делать `ORDER BY cos_dist LIMIT 10` — это O(N×D): на 10M документах × 1536 измерений = брут-форс на каждый запрос, секунды латенси. Vector DB — это **ANN-индекс (HNSW / IVF / ScaNN) + payload-фильтр + scalar storage**, оптимизированный под высокую размерность. Foundation для RAG, semantic search, рекомендаций, image similarity, дедупликации, anomaly detection. ## Mental model > «Vector DB — это **approximate nearest neighbor с трейд-оффом recall vs latency vs RAM**; > точный kNN в high-dim — brute force, поэтому всё про graph traversal (HNSW) или partitioning (IVF) с настраиваемой точностью.» Три ручки крутятся всегда: - **recall** — сколько из истинных top-K мы нашли (95-99% обычно «ок для RAG»); - **latency** — `ef_search` / `nprobe` напрямую её регулируют; - **RAM/disk** — float32 vs scalar int8 vs binary quantization, 1× → 4× → 32× компрессия. Payload (метаданные: tenant, year, topic) живёт рядом с вектором, и важно, **как** фильтр применяется относительно ANN: pre-filter, post-filter или filterable HNSW. Это решает, работает ли «найди ML-статьи за 2024 от tenant X» за 5 мс или сваливается в brute force. ## Что на диаграмме - **RAG application** — клиентский chat-app и embedder (OpenAI text-embedding-3-small, 1536-dim). - **Qdrant cluster** — три ноды, каждая — leader одного шарда (A/B/C); метаданные коллекций реплицируются через Raft, данные шардируются по `hash(doc_id) % N`. - **Postgres** — source of truth для полного текста документов. Vector DB хранит только вектор + payload + ID; полный документ достаётся из Postgres по ID после ANN-поиска. Edges: клиент ходит к embedder за вектором, ко всем шардам Qdrant (любой шард может быть coordinator с fan-out на остальные), и в Postgres по итоговым ID. Между нодами Qdrant — Raft для consistency коллекций и репликации шардов. ## Сценарии ::scenario{key="ingestion"} Документ превращается в вектор и записывается на нужный шард. HNSW-insert — это не «append в B-tree», а **встраивание точки в граф**: для нового point выбирается случайный уровень L, на каждом уровне ищутся `ef_construction` ближайших соседей и проставляются edges. Payload (tenant, year, topic) кладётся в RocksDB рядом, шард реплицируется на 2 другие ноды через Raft. Память: 10M × 1536-dim float32 ≈ 60 GB RAM без quantization. ::scenario{key="ann-query-with-filter"} Запрос «ML papers from 2024 about transformers». Embedder делает query vector, coordinator (любая нода Qdrant) делает **fan-out на все шарды**. На каждом шарде — **filterable HNSW**: payload-condition проверяется прямо во время graph traversal, а не pre/post-filter. Scatter-gather собирает top-K=10 с каждого шарда, мержит top-30, возвращает top-10 финальных по cosine. Полный текст докачивается из Postgres по ID. Latency ~10 ms p99 на shard в RAM. ::scenario{key="update-vector"} Re-embedding после смены модели (или просто правка документа) **не мутирует узел графа** — HNSW immutable on insert. Старая точка помечается tombstone в bitmap, новая вставляется как обычный insert с новым `point_id`. Граф загрязняется, RAM/disk растут линейно с upsert-трафиком. Background `optimize` периодически перестраивает segment без deleted points и делает atomic swap — это IO-heavy, регулируется `indexing_threshold`. **Gotcha:** смена embedding model (ada → 3-small) делает все вектора несравнимыми по distance — нужен full re-import dual-write, не upsert. ::scenario{key="quantization"} 100M × 1536-dim float32 = 614 GB raw vectors + ~40 GB HNSW graph = ~650 GB RAM. На одной ноде обычно 256-512 GB — не помещаемся, swap = death. Scalar int8 даёт 4× компрессию (614 → 154 GB), recall 99% → 97%. Binary quantization — 32× (614 → 19 GB), recall ~75%, **обязательно с rerank**: HNSW traversal на binary даёт top-100 кандидатов, потом rescore на оригинальных float32 → top-10. Product Quantization (PQ) — 16-32×, используется в FAISS/Milvus для billion-scale. ::scenario{key="vendor-compare"} Decision tree: - managed + cost ok + zero ops → **Pinecone** ($70+/pod/month, vendor lock-in); - уже Postgres + <10M векторов + простые фильтры → **pgvector** (один store, один backup); - 10M-1B + serious payload-фильтры → **Qdrant** (filterable HNSW first-class); - hybrid (vector + BM25 + reranker) + GraphQL → **Weaviate**; - billions + GPU acceleration → **Milvus** / **Vespa**; - prototyping / edge → **Chroma** / **sqlite-vec**. ## Trade-offs (ADR-стиль) **Контекст.** Vector store выбирается под четыре оси: (1) шкала векторов, (2) сложность payload-фильтров и hybrid search, (3) operational model, (4) quantization needs. **Шкала.** pgvector ломается на ~10M-100M в одной таблице: recall падает, latency растёт, IVFFlat-reindex блокирует writes. Qdrant/Weaviate комфортно держат 100M-1B на single cluster. Milvus и Vespa — billions с GPU FAISS. **Payload-фильтры.** Qdrant сделал **filterable HNSW** first-class — фильтр encoded в graph traversal, не pre/post. pgvector делает фильтр через `WHERE` поверх ANN-кандидатов: при sparse-фильтре (year=2024 AND tenant=X) top-K часто пуст, и IVFFlat сваливается в brute force. Weaviate тащит хороший hybrid через GraphQL. **Ops.** Pinecone полностью managed, нулевая SRE-нагрузка, цена и lock-in. Qdrant/Weaviate/Milvus — self-host либо managed cloud SKU. pgvector живёт внутри существующей Postgres: один store, один backup, transactional consistency с бизнес-данными. **Quantization.** Scalar int8 — safe default (4× RAM, 1-3% recall loss). Binary — для CLIP/BERT после rerank (32×, ~75% recall). PQ — для billion-scale. **Решение.** pgvector если уже Postgres И <10M И простые фильтры. Pinecone если managed без вопросов. **Qdrant — production sweet spot 1M-1B с сложными payload-фильтрами.** Weaviate — если приоритет hybrid. Milvus/Vespa — billions + GPU. **Последствия.** HNSW не shrinkable (delete = tombstone, periodic optimize обязателен). Backup = десятки GB снепшот index + payload. Embedding model upgrade = full re-import dual-write. Multi-tenancy — обычно лучше отдельные коллекции, чем filter by tenant_id. ## Реальные системы - **OpenAI ChatGPT plugins / Assistants** — Pinecone partner, vector store за RAG. - **Anthropic Claude Projects** — RAG patterns в Workbench (vendor не публичный). - **Notion AI** — vector search над user content (custom стек). - **Spotify** — рекомендации через Annoy (random projection forest, оптимизирован под read-only после build). - **Pinterest** — PinSage, visual search через image embeddings. - **Shopify** — semantic product search на Vespa. - **Cohere, You.com, Perplexity** — RAG-продукты поверх вектор-стора (часто Qdrant/Weaviate/managed). - **Salesforce Einstein** — semantic search через FAISS. ## Anti-patterns - **Vector DB как primary store.** Нет ACID, индексы лениво обновляются, восстановление = full rebuild. Postgres / S3 = source of truth. - **Pure vector search для коротких запросов (1-2 слова).** BM25 и hybrid (RRF) работают лучше — короткие query плохо embedded, лексический матч важнее. - **Re-compute embeddings на каждый search.** Кэшируйте `embedding(query)` хотя бы в Memcached/Redis — это $0.02/1M токенов × QPS = заметные деньги. - **Vectors без payload.** Не сможете restrict by tenant/permission/date — критично для multi-tenant SaaS. - **Brute-force kNN на 10M+ векторах каждый запрос.** HNSW/IVF обязательны. - **Mixing embedding моделей в одной коллекции.** Distance несравнимы между ada-002 и 3-small. Версионируйте. - **pgvector с >10M rows без partitioning.** Recall падает, latency растёт, reindex блокирует writes. - **Dot product без нормализации векторов.** Это уже не cosine, и top-K будет смещён к векторам с большой нормой. - **In-place update вектора (`UPDATE vec = ...`).** HNSW не мутируется — это tombstone + insert + загрязнение графа. Bulk re-embedding делайте dual-write в новую коллекцию + cutover. ## Когда НЕ использовать - **Точный поиск по структурированным полям** (`WHERE email = ...`, `WHERE order_id = ...`) — Postgres B-tree быстрее и проще. - **Full-text search с операторами AND/OR/NOT, phrase match, stemming** — Elasticsearch / Postgres tsvector. Vector search не понимает «NOT containing X». - **Геопоиск** — PostGIS / S2 / H3 индексы строго лучше: метрика честная, а не «приблизительная». - **Транзакционные данные** (orders, payments, inventory) — нужны ACID и foreign keys. - **<100K векторов.** Brute force в numpy/FAISS-flat в RAM проще и без ops-cost. - **Не нужен semantic / similarity.** Если задача — exact match, LIKE, full-text — vector store оверкилл и хуже. ## Применяется в кейсах - :case{slug="twitter-system-design"} — semantic search над твитами / рекомендации (типичный AP-юзкейс поверх вектор-индекса). - :case{slug="instagram-system-design"} — visual similarity для рекомендаций и duplicate detection через CLIP-embeddings. ## Связанные концепты - :concept{slug="rag-architecture"} — как vector DB встраивается в полный RAG-pipeline (chunking, retrieval, reranking, prompt assembly). - :concept{slug="caching-patterns"} — кэширование `embedding(query)` и top-K результатов снимает большую часть нагрузки. ## Дальше читать - **Papers:** - Malkov & Yashunin, «Efficient and robust approximate nearest neighbor search using HNSW graphs» (2016): — фундаментальный HNSW. - Johnson et al., «Billion-scale similarity search with GPUs» (FAISS, 2017): . - Guo et al., «Accelerating Large-Scale Inference with Anisotropic Vector Quantization» (ScaNN, 2020). - Subramanya et al., «DiskANN: Billion-point Nearest Neighbor Search on a Single Node» (2019). - «PinSage: Graph Convolutional Networks for Web-Scale Recommender Systems» (Pinterest, 2018). - **Docs:** - Qdrant: - Weaviate: - pgvector: - Milvus: - Pinecone: - **Benchmarks:** - ANN-Benchmarks: — recall vs QPS по всем популярным движкам. - VectorDBBench (Zilliz): — production-style workloads. - **Engineering:** - Spotify Annoy: . - Cohere / LangChain / LlamaIndex docs про vector store integrations.