尧图网页设计 
存储账单降四成、点查只要 68 毫秒Milvus 聚类压缩踩坑实录【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus上个月向量库的磁盘再次摸到 80% 告警线。对那个装着 2000 万条 768 维图像向量的集合把 Milvus 的聚类压缩Clustering Compaction打开后磁盘占用降了 40%点查延迟从 1.7 秒掉到 68 毫秒。以下是全过程数据取自 4 节点 CPU 集群的实测。聚类压缩到底动了你哪些数据写入阶段集合由一批按插入顺序生成的小 segment 组成每段里聚类键的取值范围是散的查询只能逐段查。聚类压缩重写这些小 segment压缩任务读走数据按聚类键K-means 聚类重新排布行写出约 512MB 的大 segment并为每段生成一份 partition stats。排布之后聚类键相近的数据落在同一 segment查询时查一眼 stats 就能判断这一段里有没有 user_id1000没有就整段跳过。向量内容本身一个字节没压缩赚的是能跳过的空间。机制在 compaction 模块DataCoord 负责派发任务DataNode 执行排序与写盘。版本上需要 2.4.7 及以上。5 分钟跑通聚类压缩两处配置 10 行代码配置只动两处完整参数见 configs/milvus.yaml。注意autoEnable默认是 false不打开它后台永远不会自动触发dataCoord: compaction: clustering: enable: true # 开启聚类压缩 autoEnable: true # 后台自动触发 triggerInterval: 600 # 检查间隔秒 newDataSizeThreshold: 512m # 触发所需的最小新增数据量 queryNode: enableSegmentPrune: true # 必须配否则查询侧不裁剪建集合时声明聚类键即可。支持 Int8~Int64、Float、Double、VarChar直接选查询里过滤频率最高的那个标量字段。基数控制在 100~10000 之间合适太高会切出过多 segment裁剪收益反而小from pymilvus import Collection, FieldSchema, CollectionSchema, DataType fields [ FieldSchema(id, DataType.INT64, is_primaryTrue), FieldSchema(user_id, DataType.INT64, is_clustering_keyTrue), # 聚类键 FieldSchema(embedding, DataType.FLOAT_VECTOR, dim768), ] coll Collection(user_behavior, CollectionSchema(fields)) coll.compact(is_clusteringTrue) # 手动触发一次聚类压缩 如果集合用了分区键配common.usePartitionKeyAsClusteringKey: true分区键直接当聚类键用不用额外声明字段。数字对一下25 倍加速从哪来数字来自 LAION-400M 子集2000 万条 768 维向量4 节点 CPU 集群。收益与查询条件对聚类键的裁剪率强相关查询条件平均延迟数据裁剪率无过滤条件1685ms0%user_id ∈ (200, 400)550ms约 80%user_id 100068ms约 99%存储侧压缩后占用比压缩前低 32%~45%。关键结论是裁剪只在查询条件命中聚类键时生效。裁剪率可以直接抓 Prometheus 的milvus_query_prune_ratio看如果一直是 0说明裁剪根本没跑起来。踩坑记录裁剪不生效的三个症状症状配置全开了查询延迟却纹丝不动。原因queryNode.enableSegmentPrune默认 false查询侧裁剪从未启用。解法改成true并重启服务。症状等了好久压缩任务一直没触发。原因新增数据没到newDataSizeThreshold默认 512MB或还在 1 小时minInterval保护窗内。解法手动调compact()写入频繁的集合把阈值调大反而更省。症状任务卡在 inProgress 状态很久。原因memoryBufferRatio默认 0.3大数据量频繁落盘workPoolSize默认 8。解法按 CPU 核数调dataNode.clusteringCompaction.workPoolSize内存有余量时调大memoryBufferRatio。还能接什么TTL 可以叠集合设collection.ttl.seconds过期数据定时清掉和聚类压缩的大 segment 正好配套。roadmap 里还有按数据分布自动选压缩策略、增量聚类的计划参数别写死。机制就是重排 统计 裁剪。想抠细节去读设计文档 collection_level_autocompaction_switch。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 存储账单降四成、点查只要 68 毫秒：Milvus 聚类压缩踩坑实录
存储账单降四成、点查只要 68 毫秒Milvus 聚类压缩踩坑实录【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus上个月向量库的磁盘再次摸到 80% 告警线。对那个装着 2000 万条 768 维图像向量的集合把 Milvus 的聚类压缩Clustering Compaction打开后磁盘占用降了 40%点查延迟从 1.7 秒掉到 68 毫秒。以下是全过程数据取自 4 节点 CPU 集群的实测。聚类压缩到底动了你哪些数据写入阶段集合由一批按插入顺序生成的小 segment 组成每段里聚类键的取值范围是散的查询只能逐段查。聚类压缩重写这些小 segment压缩任务读走数据按聚类键K-means 聚类重新排布行写出约 512MB 的大 segment并为每段生成一份 partition stats。排布之后聚类键相近的数据落在同一 segment查询时查一眼 stats 就能判断这一段里有没有 user_id1000没有就整段跳过。向量内容本身一个字节没压缩赚的是能跳过的空间。机制在 compaction 模块DataCoord 负责派发任务DataNode 执行排序与写盘。版本上需要 2.4.7 及以上。5 分钟跑通聚类压缩两处配置 10 行代码配置只动两处完整参数见 configs/milvus.yaml。注意autoEnable默认是 false不打开它后台永远不会自动触发dataCoord: compaction: clustering: enable: true # 开启聚类压缩 autoEnable: true # 后台自动触发 triggerInterval: 600 # 检查间隔秒 newDataSizeThreshold: 512m # 触发所需的最小新增数据量 queryNode: enableSegmentPrune: true # 必须配否则查询侧不裁剪建集合时声明聚类键即可。支持 Int8~Int64、Float、Double、VarChar直接选查询里过滤频率最高的那个标量字段。基数控制在 100~10000 之间合适太高会切出过多 segment裁剪收益反而小from pymilvus import Collection, FieldSchema, CollectionSchema, DataType fields [ FieldSchema(id, DataType.INT64, is_primaryTrue), FieldSchema(user_id, DataType.INT64, is_clustering_keyTrue), # 聚类键 FieldSchema(embedding, DataType.FLOAT_VECTOR, dim768), ] coll Collection(user_behavior, CollectionSchema(fields)) coll.compact(is_clusteringTrue) # 手动触发一次聚类压缩 如果集合用了分区键配common.usePartitionKeyAsClusteringKey: true分区键直接当聚类键用不用额外声明字段。数字对一下25 倍加速从哪来数字来自 LAION-400M 子集2000 万条 768 维向量4 节点 CPU 集群。收益与查询条件对聚类键的裁剪率强相关查询条件平均延迟数据裁剪率无过滤条件1685ms0%user_id ∈ (200, 400)550ms约 80%user_id 100068ms约 99%存储侧压缩后占用比压缩前低 32%~45%。关键结论是裁剪只在查询条件命中聚类键时生效。裁剪率可以直接抓 Prometheus 的milvus_query_prune_ratio看如果一直是 0说明裁剪根本没跑起来。踩坑记录裁剪不生效的三个症状症状配置全开了查询延迟却纹丝不动。原因queryNode.enableSegmentPrune默认 false查询侧裁剪从未启用。解法改成true并重启服务。症状等了好久压缩任务一直没触发。原因新增数据没到newDataSizeThreshold默认 512MB或还在 1 小时minInterval保护窗内。解法手动调compact()写入频繁的集合把阈值调大反而更省。症状任务卡在 inProgress 状态很久。原因memoryBufferRatio默认 0.3大数据量频繁落盘workPoolSize默认 8。解法按 CPU 核数调dataNode.clusteringCompaction.workPoolSize内存有余量时调大memoryBufferRatio。还能接什么TTL 可以叠集合设collection.ttl.seconds过期数据定时清掉和聚类压缩的大 segment 正好配套。roadmap 里还有按数据分布自动选压缩策略、增量聚类的计划参数别写死。机制就是重排 统计 裁剪。想抠细节去读设计文档 collection_level_autocompaction_switch。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考