企业官网建设流程全解析

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/（实际执行）三个模块。核心动作可以浓缩成三步：

1. 按聚类键重排：以你指定的标量字段（如user_id）或向量本身为键，把数据全局重排。KMeans 训练会做降采样与簇大小校验，参数受maxTrainSizeRatio、maxCentroidsNum等约束（见 compaction_policy_clustering.go）。
2. 合并小 segment：把散碎的小文件合并成接近maxSegmentSize的大 segment，减少元数据与索引碎片。
3. 生成 partitionStats：为每个 segment 记录键值范围和行数。查询下推时，shard delegator 用这份统计信息做segment prune，整段跳过不相关的数据。

也就是说，收益来自两处：存储端减少了碎片和重复元数据；查询端把"全量扫描"变成了"按范围取数"。

15 分钟上手：两份配置加一个 SDK 调用

功能需要Milvus 2.4.7+（仓库主干支持分区键/向量聚类键等更多模式）。

第一步，打开 DataCoord 侧开关，编辑 configs/milvus.yaml：

dataCoord: compaction: clustering: enable: true # 允许执行聚类压缩任务 autoEnable: true # 新数据达标后自动触发 triggerInterval: 600 # 检查周期（秒） newDataSizeThreshold: 512m # 未压缩新数据超过该值才触发 queryNode: enableSegmentPrune: true # 关键：默认是 false，不开则裁剪不生效

第二步，建集合时声明聚类键，选查询里高频过滤的字段：

from pymilvus import FieldSchema, CollectionSchema, DataType, Collection fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True), FieldSchema(name="user_id", dtype=DataType.INT64, is_clustering_key=True), # 支持 Int/Float/Double/VarChar FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=768), ] collection = Collection("user_behavior", CollectionSchema(fields), shards_num=4)

第三步，手动触发并等待完成（自动模式可跳过）：

state = collection.compact(is_clustering=True) collection.wait_for_compaction_completed( compaction_id=state.compaction_id, timeout=3600)

进度日志在logs/data_coord.log中搜clustering compaction。若你已用分区键做过水平拆分，也可以直接在配置里设common.usePartitionKeyAsClusteringKey: true，让分区键自动充当聚类键，省去改 Schema。

🎯 最佳实践：聚类键基数建议落在100~10000区间。太低（如性别）切不出裁剪空间，太高（如订单号）会把 segment 切碎、放大元数据开销。

2000 万向量实测：收益与过滤精度成正比

测试集是 LAION-400M 子集，2000 万条 768 维向量，环境为4 节点 CPU 集群（Intel Xeon 8375C，256GB 内存）。关键结论：查询条件越能"卡准"聚类键范围，收益越大。

注意第一行：即使不做过滤，仅合并小 segment 就能省约三分之一的存储——碎片化严重的老集合光开自动压缩就有收益。复现脚本见 tests/integration/compaction/。

调优 3 个关键参数与最常踩的 3 个坑

参数都在dataCoord.compaction.clustering与dataNode.clusteringCompaction下（详见 configs/milvus.yaml）：

三个高频问题：

• 任务长时间不结束：先看 DataCoord 日志是否资源槽不足（clusteringCompactionUsage控制任务占用 slot），再考虑调大maxInterval之外的超时类参数。
• 存储没降：压缩是排序重写，如果源数据本身压缩率高，收益有限；检查是否混入了未压缩的历史大 segment。
• 查询没变快：90% 的情况是queryNode.enableSegmentPrune仍是默认false，或过滤字段根本不是聚类键。先查这两处，再看milvus_query_prune_ratio。

⚠️ 注意：压缩任务会重写 segment，执行期间 DataNode 有 IO 与内存压力（memoryBufferRatio默认 0.3 控制内存缓冲占比）。建议把大集合的压缩安排在业务低峰。

行动清单

1. 今天：给核心集合的查询打点，统计 Top 10 过滤字段的频率，选一个设为聚类键。
2. 本周：测试环境按上文三步配置，用真实查询回归验证延迟与milvus_query_prune_ratio。
3. 上线后：接 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