1 个聚类键换 25 倍加速Milvus 聚类压缩完整落地指南【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus过滤查询被全量扫描拖到秒级账单跟着一起涨Milvus 集合里 768 维向量单条约 3 KB1 亿条光原始数据就是 300 GB 起步。如果查询还总带着user_id 123这类过滤条件每次都在扫描所有用户的数据段P99 会从几十毫秒滑到 1.6 s 以上。此时扩容 QueryNode 只是把账单再翻一倍因为多出来的节点依然在扫同样的段。Milvus 的聚类压缩Clustering Compaction要解决的就是这件事让数据按高频过滤字段重新落盘让查询只碰得到该碰的段。数据按键重排之后查询为什么能跳段机制是一条因果链。DataCoord 先对集合做 K-Means 聚类训练算出质心再把数据按**聚类键Clustering Key**所在的质心分区重排、落盘使每个数据段Segment内的键值范围尽量连续。键值连续之后带过滤条件的查询到达 QueryNode 时会先查 DataCoord 维护的分区统计信息Partition Stats每个段的键值 min/max 都记录在里面。过滤范围与某个段的区间不相交这个段就不进扫描计划QueryNode 直接跳过。最终效果是过滤条件越精确被跳过的段越多小段在重排过程中被合并成大段对象存储的文件数和元数据开销也随之下降。压缩任务的调度复用图中这条 Proxy → DataCoord → DataNode 通道DataCoord 判定触发条件后把任务拆成子任务下发DataNode 并行执行。触发策略在 internal/datacoord/ 的 compaction_trigger 与 compaction_task_clustering 里公共类型定义在 internal/compaction/。动手落地3 行 yaml 打开自动聚类压缩在 configs/milvus.yaml 里改 dataCoord 段dataCoord: compaction: clustering: enable: true autoEnable: true triggerInterval: 600 newDataSizeThreshold: 512m预期看到累计写入超过 512 MB 新数据后logs/data_coord.log出现clustering compaction触发日志之后无需手动调 API。参数默认值何时需要调dataCoord.compaction.clustering.enabletrue先确认它没被覆盖dataCoord.compaction.clustering.autoEnablefalse需要后台自动执行时改 truedataCoord.compaction.clustering.triggerInterval600写入稀疏、可容忍更晚压缩时调大dataCoord.compaction.clustering.newDataSizeThreshold512m写入密集时调大减少压缩频率dataNode.clusteringCompaction.workPoolSize8压缩排队而节点 CPU 空闲时调大建集合时把高频过滤字段标为聚类键fields [ FieldSchema(id, DataType.INT64, is_primaryTrue), FieldSchema(user_id, DataType.INT64, is_clustering_keyTrue), FieldSchema(embedding, DataType.FLOAT_VECTOR, dim768), ] collection Collection(user_behavior, CollectionSchema(fields))预期看到collection.schema中 user_id 的 is_clustering_key 为 True。已有集合无法事后补聚类键需要重建或迁移所以这个字段要在建表时定下来。选字段的原则查询里真正高频过滤、基数适中的标量字段用户 ID、租户 ID、时间桶Int8–Int64、Float、Double、VarChar 都支持。手动触发一次压缩并确认完成compaction_id collection.compact(is_clusteringTrue) state collection.get_compaction_state(compaction_id) print(state.state) # 轮询直至 Completed预期看到state 从 InProgress 变为 Completed完成后新查询开始走裁剪路径旧段由 GC 逐步回收存储占用随之下降。效果实录场景指标对比基准无过滤全量查询平均延迟 1685 ms压缩前基线 1xuser_id ∈ (200, 800)平均延迟 1045 ms快 1.6x裁掉 40.2% 的段user_id ∈ (200, 400)平均延迟 550 ms快 3.1x裁掉 79.5% 的段user_id 1000平均延迟 68 ms快 25x裁掉 99% 的段对象存储占用下降 32%–45%压缩前原始账单最值得记的是最后一行等值过滤只命中一个质心分区99% 的段被跳过后延迟约为全量扫描的 1/25。裁剪率取决于过滤条件与聚类键范围的对齐程度所以这份收益只对带键过滤的查询成立无过滤的全量查询不吃这部分红利。测试环境4 节点 CPU 集群Intel Xeon 8375C256 GB 内存LAION-400M 子集 2000 万条 768 维向量。避坑与调优压缩一直没触发newDataSizeThreshold默认 512 MB小集合写不满或autoEnable仍是 false → 先查这两项再手动compact(is_clusteringTrue)验证链路是否通。开了压缩但延迟没降查询过滤条件没落在聚类键上或还在扫旧段 → 确认过滤字段就是聚类键本身且等 Completed、旧段卸载后再测。压缩任务长时间占满 DataNode单个 clustering 任务默认占满一个 workerdataNode.slot.clusteringCompactionUsage: 65535期间其他压缩和索引任务排队 → 调大triggerInterval错开写入高峰。K-Means 训练阶段内存吃紧高基数字段的质心数默认上限 10240 → 调低maxCentroidsNum或调大memoryBufferRatio让中间数据先落盘。参数默认值调整建议dataNode.clusteringCompaction.workPoolSize816 核以上节点调到 16dataNode.clusteringCompaction.memoryBufferRatio0.3OOM 时调大到 0.5dataCoord.compaction.clustering.maxCentroidsNum10240高基数字段降到 4096dataCoord.compaction.clustering.minInterval3600防止同一集合反复压缩别调太小延伸collection 级 autocompaction 开关的设计细节见 20230511-collection_level_autocompaction_switch.md再配合集合 TTL 自动清理过期数据能把存储曲线压得更平。先挑一个过滤查询占流量大头的集合开 autoEnable三天后对比 P99再决定要不要全量推广。完整配置configs/milvus.yaml压缩策略与任务源码internal/datacoord/压缩公共类型internal/compaction/【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
