16.Milvus的CollectionPartition向量字段分别是什么

Milvus 的 Collection、Partition、向量字段分别是什么？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 16 篇

刚接触 Milvus 时，最容易混淆的三个概念是 Collection、Partition 和向量字段。它们分别对应“数据集合”“集合内部的组织方式”和“用于相似度计算的字段”。如果概念没有分清，后续的插入、加载、检索和扩容都会变得混乱。

在实际部署中，还要把“数据模型”和“运行依赖”分开理解：Collection、Partition、Field 是 Milvus 面向开发者的数据抽象；etcd、MinIO、Standalone 是 Milvus 的运行架构。前者决定数据怎么组织，后者决定这些数据的元信息、文件和服务如何运行。

数据模型：Collection → Partition → Entity → Field 运行依赖：Standalone / Milvus 服务 ├── etcd：元数据、服务注册与健康检查 └── MinIO / S3：数据文件、索引文件等对象

一、先用关系型数据库类比

可以先做一个不完全等价但很有帮助的类比：

Milvus Collection ≈ 一张结构化数据表 Milvus Entity ≈ 一行记录 Milvus Field ≈ 一列 Milvus Partition ≈ 表内部的一组逻辑分区

但 Collection 不是简单的 SQL 表。它的核心任务是组织向量实体，并为向量字段建立索引。

二、Collection：一类数据的容器

在知识库中，可以把一个 Collection 设计成“知识片段集合”：

knowledge_chunks ├── chunk_id ├── document_id ├── tenant_id ├── text ├── status └── embedding

Collection 创建时需要定义 Schema。Schema 至少要明确主键和向量字段的类型、维度；其他字段用于过滤、回填和关联业务数据。

Collection 的 Schema 和元数据由 Milvus 管理，并由其元数据存储维护；应用不应该直接操作 etcd 中的键值。etcd 是 Milvus 的内部依赖，不是给业务代码查询 Collection 的管理数据库。需要查看集合、索引和加载状态时，应使用 Milvus SDK、CLI 或管理 API。

一个简化示例：

frompymilvusimportDataType,MilvusClient client=MilvusClient(uri="http://localhost:19530")schema=client.create_schema(auto_id=False,enable_dynamic_field=False)schema.add_field("chunk_id",DataType.VARCHAR,max_length=64,is_primary=True)schema.add_field("document_id",DataType.VARCHAR,max_length=64)schema.add_field("tenant_id",DataType.VARCHAR,max_length=64)schema.add_field("text",DataType.VARCHAR,max_length=8192)schema.add_field("embedding",DataType.FLOAT_VECTOR,dim=768)index_params=client.prepare_index_params()index_params.add_index(field_name="embedding",index_type="HNSW",metric_type="COSINE",params={"M":16,"efConstruction":200},)client.create_collection(collection_name="knowledge_chunks",schema=schema,index_params=index_params,)

示例中的dim=768只是占位值，必须替换成实际 Embedding 模型的输出维度。

三、Field：向量字段和标量字段

1. 向量字段

向量字段保存 Embedding 结果，是相似度检索的输入。常见的稠密浮点向量字段类型是FLOAT_VECTOR。向量维度固定后，写入和查询都必须遵守同一个维度。

2. 标量字段

字符串、数字、布尔值等字段属于标量字段，可用于：

• 过滤租户和部门；
• 区分文档版本和发布状态；
• 返回引用所需的业务 ID；
• 关联 PostgreSQL 中的完整元数据。

不要把所有业务字段都无选择地复制到 Milvus。只把检索过滤和结果回填真正需要的字段放进去，其余数据由业务数据库负责。

3. 动态字段要谨慎使用

动态字段可以让数据结构更灵活，但也会降低 Schema 的可见性和约束能力。企业知识库通常更适合显式定义核心字段，把可选属性放入受控的 JSON 或业务数据库中。

四、Partition：集合内部的逻辑分组

Partition 用于把一个 Collection 中的数据按逻辑划分。检索时可以指定某些 Partition，从而缩小搜索范围。

例如：

knowledge_chunks ├── tenant_a ├── tenant_b └── tenant_c

不过，不能简单地把每个租户、每个用户都创建成一个 Partition。租户数量不断增长时，Partition 数量也会膨胀，管理、加载和查询都会变复杂。

更常见的设计是：

• Partition 数量有限且稳定：按业务域、数据冷热或时间范围划分；
• 租户数量很多：使用tenant_id标量字段过滤；
• 数据量特别大：结合分片和查询节点设计，而不是只依赖 Partition。

五、Partition Key 与手工 Partition 有什么不同？

手工 Partition 需要应用自己决定数据写入哪个分区；Partition Key 则可以让系统根据字段值将数据路由到对应分区。二者适合的场景不同，不能只因为“分区看起来更快”就盲目使用。

如果业务过滤条件始终包含租户编号，租户字段可能适合作为分区键；如果查询经常跨租户，强行按租户划分反而可能造成大量分区访问。

六、如何设计一条知识库记录？

推荐把 Milvus 记录设计成“检索索引”，而不是完整业务主表：

{"chunk_id":"doc-001:chunk-0007","document_id":"doc-001","tenant_id":"tenant-a","status":"published","embedding":[0.012,-0.084,0.221]}

检索命中后，再由document_id、chunk_id查询 PostgreSQL 中的标题、版本、权限和来源信息。这样可以避免在向量库中复制大量易变业务字段。

MinIO 中应该放什么？

Milvus 会把持久化数据、索引文件以及部分中间结果写入对象存储。这里的对象存储可以是官方示例中的 MinIO，也可以是兼容 S3 的云存储。它和 PostgreSQL 中的业务记录、RAG 应用保存原始 PDF 的对象存储不是同一层职责：

原始文件：应用对象存储 / MinIO / OSS 业务元数据：PostgreSQL 向量与索引：Milvus 管理，底层持久化到 Milvus 配置的 MinIO / S3

如果把 Milvus 的对象存储目录误删，etcd 中可能仍然保留集合和索引元信息，但底层文件已经不可读。因此，备份 Milvus 时不能只备份 PostgreSQL，也不能只导出业务表，还要按照部署方案备份对象存储、元数据和配置，并在测试环境验证恢复流程。

七、常见设计错误

错误一：不同模型的向量放在同一个字段

不同 Embedding 模型的维度、语义空间和归一化方式可能不同。模型升级时应新建向量字段或新 Collection，并进行对照评测。

错误二：把权限判断交给 Partition

Partition 是数据组织和检索范围机制，不是完整的授权系统。权限变化后，必须由业务服务重新计算用户可访问范围。

错误三：把文本全文都当成向量库主数据

文本回填、版本管理和审计通常由 PostgreSQL 或对象存储负责。Milvus 中的文本字段只保留满足检索结果回填需要的内容。

错误四：一开始创建大量分区

先根据查询模式和数据规模设计，必要时用标量过滤替代分区。分区不是越多越好。

八、设计检查清单

• Collection 是否只承载一种明确的向量检索任务；
• 主键是否稳定且能关联业务记录；
• 向量维度是否与模型固定对应；
• 标量字段是否覆盖必要的租户、版本和状态过滤；
• 是否真的需要手工 Partition；
• 权限判断是否仍由业务服务负责；
• 模型升级是否有重建和灰度方案。
• 是否区分了 Milvus 的内部对象存储与应用原始文件存储；
• 是否通过 Milvus API 管理集合，而不是直接修改 etcd；
• 是否为 etcd、MinIO 和 Milvus 数据卷设计了备份与恢复方案。

结语

Collection 负责组织一类向量实体，Field 负责描述记录结构，Partition 负责在集合内部进行逻辑划分。理解三者关系后，Milvus 的建模就不再是“照着示例复制 Schema”，而是可以从检索模式、权限边界和数据生命周期反推设计。

下一篇将沿着一次真实查询，解释 Milvus 如何从查询向量走到 Top K 结果。

参考资料

1. Milvus 官方文档：Schema
2. Milvus 官方文档：Manage Collections
3. Milvus 官方文档：Architecture Overview
4. Milvus 官方文档：Partitions

本文为“码海寻道”原创技术文章。Schema API 和字段类型请结合目标 Milvus 版本进行验证。