Milvus 学习笔记

Milvus 数据结构存储 & 与 MySQL 异同

一、Milvus 的数据结构：层级关系

核心观点：Milvus 的数据组织逻辑和 MySQL 很像，但物理存储和索引机制完全不同。

Milvus                         MySQL 类比
─────────────────────────────────────────
Collection（集合）           ≈   Table（表）
  ├── Field（字段）          ≈   Column（列）
  ├── Entity（实体）         ≈   Row（行）
  ├── Partition（分区）      ≈   分区表（可选）
  ├── Shard（分片）          ≈   分表
  └── Segment（段）          ≈   "数据文件"（无直接对应）

例：ai_diary 集合含 id、vector、content、date、mood、tags 共 6 个字段，插入 5 条日记 = 5 个 Entity。这部分和 MySQL 建表、插行几乎一一对应。

二、Milvus 特有核心：Segment（数据段）

这是 Milvus 和 MySQL 最大的结构差异。

• MySQL：数据是一个大表文件（按 B+Tree 组织），表是存储的物理单位。
• Milvus：一个 Collection 的数据会被自动切成多个 Segment，每个 Segment 是独立的存储 + 索引单元。
• Segment 两种状态：
  • Growing Segment：数据刚写入，在内存里，可写但不能建索引；
  • Sealed Segment：数据攒够（默认 512MB 或一定行数）"封口"，落盘，异步建索引，之后才高效搜索。

这就是"近实时"概念——刚插入的数据在 Growing 阶段可查，但搜索性能不如 Sealed 阶段。

三、物理存储与写入路径

Milvus 写入一条数据的完整链路：

客户端 → 写入日志（消息队列，如 Pulsar/Kafka）
       → 内存缓冲（Growing Segment）
       → 攒够阈值 → flush 落盘成 Sealed Segment
       → 构建向量索引（HNSW/IVF 等）→ 可被快速检索

MySQL 则是就地更新 B+Tree 页，每次写入直接改磁盘页（配合 redo log 保证崩溃恢复）。

四、索引方式不同（本质区别）

IVF_FLAT + COSINE：把向量空间聚类成 nlist=1024 个桶，查询时先找相近的桶，再在桶内精确算余弦距离。

五、异同总结

相同点

1. 都是数据库，都有"库表/集合、字段/列、行/实体"的概念
2. 都支持增删改查、主键、索引、数据持久化
3. 都有配套客户端 SDK（如 @zilliz/milvus2-sdk-node 类似 MySQL 驱动）

不同点

一句话总结：MySQL 用 B+Tree 索引回答"哪些行符合条件"，Milvus 用向量索引回答"哪几条和我最像"。实际系统里两者经常配合使用——MySQL 存业务主数据，Milvus 存 embedding 做语义检索，用 id 关联。