企业官网建设流程全解析

Milvus 聚类压缩实践：向量数据库如何降本存储并加速过滤查询

【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus

Milvus 是一款云原生向量数据库，聚类压缩（Clustering Compaction）是它的后台整理能力：按你指定的某个字段把数据重新排序、重写数据段，并生成统计信息。本文覆盖在生产环境启用、验证和调优的完整路径，帮你理解这项特性如何同时带来存储开销下降与过滤查询提速。

动手之前，工程师通常关心三个问题：

1. 为什么向量数据要单独做"聚类"这种压缩？和普通 compaction 有什么区别？
2. 生产环境怎么启用？配置项和集合定义上各要改什么？
3. 怎么确认它真的生效了？有哪些参数可调、哪些坑要避开？

下面逐个回答。

问题一：过滤查询为什么需要专门的压缩？

Milvus 的数据是追加式写入的，落盘后按段（segment）组织。如果集合里没有任何顺序，一条带user_id > 200这类标量过滤的查询，理论上要逐个扫描所有数据段才能确认哪些行命中。

聚类压缩解决的就是这件事。用一句通俗的话解释：先按某个字段把数据排好序，让查询能整段跳过无关数据。它做三件事：

• 按聚类键（Clustering Key）对数据全局排序；
• 把小段合并重写为大段，减少文件与元数据开销；
• 生成分区级统计信息（partition stats），记录每个新段上聚类键的取值范围。

查询阶段，QueryNode 依据这些统计做段级裁剪（segment prune）：过滤条件与某段的键范围完全不相交时，该段直接不参与扫描。存储侧的收益则来自合并与重写本身——重复、碎片和 delta 日志被消除，同样的数据占用更少的空间。

谁负责触发，谁负责执行

触发逻辑在 DataCoord 中：compaction_policy_clustering.go 会周期性检查每个集合，判断是否满足触发条件；实际的重写工作派发给 DataNode 执行，核心实现在 clustering_compactor.go，公共数据结构在 internal/compaction/。

自动触发的判定条件（来自 compaction_policy_clustering.go）：

• 从未压缩过、且该 channel 上新写入数据超过newDataSizeThreshold（默认 512m）→ 触发；
• 距上次压缩超过maxInterval（默认 259200s，即 3 天）→ 强制触发；
• 距上次压缩不足minInterval（默认 3600s）→ 跳过，避免高频重复压缩。

问题二：三步在生产环境启用

第一步：打开后台自动触发

编辑 configs/milvus.yaml，dataCoord.compaction.clustering段落默认enable: true但autoEnable: false，也就是只允许手动触发。要后台自动跑，把 autoEnable 打开：

dataCoord: compaction: clustering: enable: true # 功能总开关 autoEnable: true # 改为 true 才会后台自动执行 triggerInterval: 600 # 检查间隔（秒） newDataSizeThreshold: 512m # 新数据量超过该值才值得压缩

DataNode 侧还有两个执行参数（同一文件dataNode.clusteringCompaction段）：memoryBufferRatio: 0.3控制排序缓冲占可用内存的比例，超出即溢写到存储；workPoolSize: 8是单个压缩作业的并发 worker 数。注意dataNode.slot.clusteringCompactionUsage默认为 65535，意味着一个聚类压缩作业会占满一个 DataNode worker，压缩窗口内的其他任务（索引构建等）并发度会下降，写入高峰期建议错峰。

第二步：集合定义时指定聚类键

启用功能的另一半在集合 Schema 上：必须有一个字段被标记为聚类键。用官方 Go 客户端（client/entity/field.go）：

fields := []entity.Field{ {Name: "id", DataType: entity.FieldTypeInt64, IsPrimary: true}, // 标记聚类键：建议选查询中高频过滤的标量字段 {Name: "user_id", DataType: entity.FieldTypeInt64, IsClusteringKey: true}, {Name: "embedding", DataType: entity.FieldTypeFloatVector, TypeParams: map[string]string{"dim": "768"}}, }

两点提醒：

• 已有集合事后无法补标聚类键，需要在建模阶段就想好；如果字段定不了，可评估common.usePartitionKeyAsClusteringKey（默认 false），直接复用分区键做聚类，免去额外字段。
• 触发器会先检查 Schema，没有聚类键的集合会被直接跳过，日志里会有 "the collection has no clustering key, skip" 字样，这是正常行为而非故障。

第三步：手动触发与进度观察

不想等自动窗口时，可通过 SDK 的 compact 接口（clustering 模式）手动触发，同一接口族下还有查询压缩状态的 API。执行过程中 DataCoord 会记录任务触发、调度、完成日志，按集合 ID 检索 "clustering" 相关关键字即可跟踪状态；任务元数据与状态机的处理在 compaction_task_clustering.go。

问题三：怎么验证生效、怎么调参

验证路径

1. 延迟：压缩完成并重新加载后，对比同一过滤查询的前后 P99 延迟。过滤条件越贴近聚类键、命中行占比越小，差距越明显；不带过滤的纯向量检索不会有变化——裁剪只对过滤条件起作用。
2. 存储：对比压缩前后集合的数据量（Object Storage 用量），合并与去碎片带来的节省体现在这里，而非"向量本身被压缩"。
3. 指标：接入 Prometheus 后观察 compaction 相关计数与裁剪比例类指标，确认任务在成功完成而非反复失败。

调优参数速查

常见坑

• 外部集合（external collection）不参与聚类压缩，触发器会显式跳过；
• L0 段被排除在压缩输入之外；若同 channel 下还有 L2 段正在被其他压缩任务占用，本轮也会跳过（源码中有 "compacting" 检查），属于保护性行为；
• 压缩期间有额外的存储读写与 worker 占用，别把它当成零成本操作，评估写入高峰再排期；
• 查询没变快先确认两件事：QueryNode 侧段裁剪是否对该集合生效、过滤条件是否真的落在聚类键上。过滤一个与聚类键无关的字段，裁剪无从发生。

选型对比：什么时候值得开

写在最后

聚类压缩的价值可以用一句话概括：把"查询时逐段找"变成"查询时整段跳"，代价是一次后台的数据重写窗口。启用前想清楚三个输入——用哪个字段当聚类键、什么时候触发、压缩窗口与写入高峰如何错开——后面的收益（更少的存储空间、更快的过滤查询）是水到渠成的。想深入实现细节，可以从 internal/datacoord/ 的触发策略和 internal/datanode/compactor/ 的执行器读起。

【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus