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 └── embeddingCollection 创建时需要定义 Schema。Schema 至少要明确主键和向量字段的类型、维度其他字段用于过滤、回填和关联业务数据。Collection 的 Schema 和元数据由 Milvus 管理并由其元数据存储维护应用不应该直接操作 etcd 中的键值。etcd 是 Milvus 的内部依赖不是给业务代码查询 Collection 的管理数据库。需要查看集合、索引和加载状态时应使用 Milvus SDK、CLI 或管理 API。一个简化示例frompymilvusimportDataType,MilvusClient clientMilvusClient(urihttp://localhost:19530)schemaclient.create_schema(auto_idFalse,enable_dynamic_fieldFalse)schema.add_field(chunk_id,DataType.VARCHAR,max_length64,is_primaryTrue)schema.add_field(document_id,DataType.VARCHAR,max_length64)schema.add_field(tenant_id,DataType.VARCHAR,max_length64)schema.add_field(text,DataType.VARCHAR,max_length8192)schema.add_field(embedding,DataType.FLOAT_VECTOR,dim768)index_paramsclient.prepare_index_params()index_params.add_index(field_nameembedding,index_typeHNSW,metric_typeCOSINE,params{M:16,efConstruction:200},)client.create_collection(collection_nameknowledge_chunks,schemaschema,index_paramsindex_params,)示例中的dim768只是占位值必须替换成实际 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并进行对照评测。错误二把权限判断交给 PartitionPartition 是数据组织和检索范围机制不是完整的授权系统。权限变化后必须由业务服务重新计算用户可访问范围。错误三把文本全文都当成向量库主数据文本回填、版本管理和审计通常由 PostgreSQL 或对象存储负责。Milvus 中的文本字段只保留满足检索结果回填需要的内容。错误四一开始创建大量分区先根据查询模式和数据规模设计必要时用标量过滤替代分区。分区不是越多越好。八、设计检查清单Collection 是否只承载一种明确的向量检索任务主键是否稳定且能关联业务记录向量维度是否与模型固定对应标量字段是否覆盖必要的租户、版本和状态过滤是否真的需要手工 Partition权限判断是否仍由业务服务负责模型升级是否有重建和灰度方案。是否区分了 Milvus 的内部对象存储与应用原始文件存储是否通过 Milvus API 管理集合而不是直接修改 etcd是否为 etcd、MinIO 和 Milvus 数据卷设计了备份与恢复方案。结语Collection 负责组织一类向量实体Field 负责描述记录结构Partition 负责在集合内部进行逻辑划分。理解三者关系后Milvus 的建模就不再是“照着示例复制 Schema”而是可以从检索模式、权限边界和数据生命周期反推设计。下一篇将沿着一次真实查询解释 Milvus 如何从查询向量走到 Top K 结果。参考资料Milvus 官方文档SchemaMilvus 官方文档Manage CollectionsMilvus 官方文档Architecture OverviewMilvus 官方文档Partitions本文为“码海寻道”原创技术文章。Schema API 和字段类型请结合目标 Milvus 版本进行验证。