Milvus is an open-source, cloud-native vector database built by Zilliz that stores, indexes, and searches high-dimensional embedding vectors at billion-scale. It powers AI applications — RAG pipelines, semantic search, recommendation systems, and multimodal retrieval — by turning similarity search into a first-class database operation. Unlike bolted-on vector extensions, Milvus separates compute from storage and uses a message-queue-backed write path (Pulsar/Kafka) so search nodes scale independently of data nodes. The key mental model: everything flows through collections → shards → segments, and the right index type plus the right consistency level unlock both accuracy and throughput simultaneously.
What This Cheat Sheet Covers
This topic spans 17 focused tables and 112 indexed concepts, 104 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core Data Model — Collections, Partitions, Shards, and Segments
A Milvus collection is the top-level container for vectors and their associated scalar fields — analogous to a table in a relational database. Understanding how collections subdivide into partitions, shards, and segments is essential before tuning performance or planning capacity.
| Concept | Example | Description | |
|---|---|---|---|
client.create_collection(collection_name="docs", dimension=768) | Top-level data container holding a schema (fields + vector field), up to 65,535 collections per instance. | ||
num_shards=2 in create_collection() | • Horizontal unit for write scaling • primary key is hashed to route inserts across shards • 1–2 shards per 50–200M entities is the recommended range • immutable after creation. | ||
client.create_partition(collection_name="docs", partition_name="2024") | • Logical read-time subdivision within a collection • queries can skip irrelevant partitions entirely to reduce search footprint • up to 1,024 partitions per collection | ||
schema.add_field("tenant_id", DataType.VARCHAR, is_partition_key=True) | • Designates a scalar field so Milvus auto-manages partitions by hashing field values • ideal for multi-tenancy with millions of tenants • eliminates manual partition management | ||
(internal — not user-created) | • Smallest execution unit • intersection of shard and partition • Growing (buffering writes, unindexed) or Sealed (immutable, indexed) • default max size ~122 MB before sealing | ||
(triggered automatically at maxSize × sealProportion) | • Transition from growing → sealed • seals flush segment to object storage and trigger index building on the data node • sealed segments can be merged up to 1 GB | ||
(triggered when deletions exceed 20% of segment) | • Merges small sealed segments and removes deletion-flagged rows • keeps search performance healthy • runs on data nodes periodically | ||
client.trigger_compaction(collection_name="docs", clusteringKey="category") | • Redistributes entities by a scalar clustering key so search can prune irrelevant segments • can deliver up to 25× speedup on large collections (≥1M rows). | ||
schema = MilvusClient.create_schema(enable_dynamic_field=True) | • Stores ad-hoc key-value pairs outside the fixed schema in a hidden $meta JSON column• queryable and filterable without schema changes | ||
client.create_database(db_name="tenant_a") | • Logical namespace above collections • supports up to 64 databases per instance • used for database-level multi-tenancy with strict data isolation |