Milvus 聚类压缩实战指南存储直降 45%单点查询最快提速 25 倍【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus凌晨两点成本告警跳进值班群这个月对象存储账单比上月涨了40%S3 流量费同步翻倍。你翻了下监控问题很清楚——线上那个 768 维向量的用户行为集合每次检索都在扫全量 segment。Milvus 的**聚类压缩Clustering Compaction**就是为这种场景设计的它把数据按聚类键重新排序、合并成更大的 segment再为每个 segment 生成统计信息。检索时命中统计信息的查询可以直接跳过无关 segment——实测存储占用最多降45%精确点查最高提速25 倍。下文从一条账单讲起给出完整落地步骤和调优参数。那张账单背后的根因数据没有聚簇先定位问题。Milvus 的写入是流式的新数据先进消息流再由 DataNode 刷成 segment。频繁写入会让一个集合堆出大量小 segment同一个用户的向量被打散在几十个 segment 里。此时一条user_id 1000的过滤检索会发生什么查询计划里没有任何线索可以裁剪数据QueryNode 只能把每个 segment 都扫一遍。数据量越大延迟越高、IO 越贵账单就是这么涨上来的。 判断是否中招看 Prometheus 里milvus_query_prune_ratio。如果长期是 0说明裁剪完全没生效聚类压缩值得排期。原理速览排序、合并、统计三步走聚类压缩的完整实现分散在 internal/compaction/、internal/datacoord/策略与任务编排和 internal/datanode/compactor/实际执行三个模块。核心动作可以浓缩成三步按聚类键重排以你指定的标量字段如user_id或向量本身为键把数据全局重排。KMeans 训练会做降采样与簇大小校验参数受maxTrainSizeRatio、maxCentroidsNum等约束见 compaction_policy_clustering.go。合并小 segment把散碎的小文件合并成接近maxSegmentSize的大 segment减少元数据与索引碎片。生成 partitionStats为每个 segment 记录键值范围和行数。查询下推时shard delegator 用这份统计信息做segment prune整段跳过不相关的数据。也就是说收益来自两处存储端减少了碎片和重复元数据查询端把全量扫描变成了按范围取数。15 分钟上手两份配置加一个 SDK 调用功能需要Milvus 2.4.7仓库主干支持分区键/向量聚类键等更多模式。第一步打开 DataCoord 侧开关编辑 configs/milvus.yamldataCoord: compaction: clustering: enable: true # 允许执行聚类压缩任务 autoEnable: true # 新数据达标后自动触发 triggerInterval: 600 # 检查周期秒 newDataSizeThreshold: 512m # 未压缩新数据超过该值才触发 queryNode: enableSegmentPrune: true # 关键默认是 false不开则裁剪不生效第二步建集合时声明聚类键选查询里高频过滤的字段from pymilvus import FieldSchema, CollectionSchema, DataType, Collection fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue), FieldSchema(nameuser_id, dtypeDataType.INT64, is_clustering_keyTrue), # 支持 Int/Float/Double/VarChar FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim768), ] collection Collection(user_behavior, CollectionSchema(fields), shards_num4)第三步手动触发并等待完成自动模式可跳过state collection.compact(is_clusteringTrue) collection.wait_for_compaction_completed( compaction_idstate.compaction_id, timeout3600)进度日志在logs/data_coord.log中搜clustering compaction。若你已用分区键做过水平拆分也可以直接在配置里设common.usePartitionKeyAsClusteringKey: true让分区键自动充当聚类键省去改 Schema。 最佳实践聚类键基数建议落在100~10000区间。太低如性别切不出裁剪空间太高如订单号会把 segment 切碎、放大元数据开销。2000 万向量实测收益与过滤精度成正比测试集是 LAION-400M 子集2000 万条 768 维向量环境为4 节点 CPU 集群Intel Xeon 8375C256GB 内存。关键结论查询条件越能卡准聚类键范围收益越大。查询条件裁剪率平均延迟相对基线无过滤条件0%1685 ms1×存储仍省 32%user_id ∈ (200, 800)40.2%1045 ms1.6×user_id ∈ (200, 400)79.5%550 ms3.1×user_id 100099%68 ms25×注意第一行即使不做过滤仅合并小 segment 就能省约三分之一的存储——碎片化严重的老集合光开自动压缩就有收益。复现脚本见 tests/integration/compaction/。调优 3 个关键参数与最常踩的 3 个坑参数都在dataCoord.compaction.clustering与dataNode.clusteringCompaction下详见 configs/milvus.yaml参数推荐值调整场景newDataSizeThreshold512m写入频繁的集合调大降低压缩频率minInterval3600秒同一集合两次压缩的保底间隔防抖dataNode.clusteringCompaction.workPoolSize8DataNode CPU 核数多时调大缩短任务时长三个高频问题任务长时间不结束先看 DataCoord 日志是否资源槽不足clusteringCompactionUsage控制任务占用 slot再考虑调大maxInterval之外的超时类参数。存储没降压缩是排序重写如果源数据本身压缩率高收益有限检查是否混入了未压缩的历史大 segment。查询没变快90% 的情况是queryNode.enableSegmentPrune仍是默认false或过滤字段根本不是聚类键。先查这两处再看milvus_query_prune_ratio。⚠️ 注意压缩任务会重写 segment执行期间 DataNode 有 IO 与内存压力memoryBufferRatio默认 0.3 控制内存缓冲占比。建议把大集合的压缩安排在业务低峰。行动清单今天给核心集合的查询打点统计 Top 10 过滤字段的频率选一个设为聚类键。本周测试环境按上文三步配置用真实查询回归验证延迟与milvus_query_prune_ratio。上线后接 Prometheus 监控压缩任务成功率与裁剪率按周回顾newDataSizeThreshold与实际写入速率的匹配度。 延伸阅读压缩策略源码 internal/datacoord/compaction_policy_clustering.go、执行器 internal/datanode/compactor/clustering_compactor.go、集成测试 tests/integration/compaction/clustering_compaction_test.go自动压缩的整体设计可查 docs/design-docs/ 下相关设计文档。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考