延迟从 1685ms 压到 68msMilvus 聚类压缩背后的 25 倍加速【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus当查询条件精确命中user_id 1000时2000 万向量集群的平均延迟从 1685ms 降到 68ms存储占用同步缩减 45%——干这件事的是 Milvus 的聚类压缩Clustering Compaction。它面向 768 维这类高维特征向量把存储和查询速度一起优化且不需要改变向量检索精度。Milvus 聚类压缩是怎么快的数据进来后的三次重排新数据写入后DataCoord 先判断增量是否超过newDataSizeThreshold达标才拉起压缩任务。接下来 DataNode 按聚类键Clustering Key对记录做全局重排让相同键值的行落到同一段随后把分散的小数据段Segment合并成大文件压低元数据开销并在落盘过程中生成分区统计信息partitionStats记下每个段覆盖的键值区间。查询进来时QueryNode 拿过滤条件去比对这些统计信息整段不命中的数据段直接跳过、不参与扫描——扫描范围变短就是延迟数字变小的全部原因。5 分钟上手启用 Milvus 聚类压缩功能需要 Milvus 2.4.7 版本。改完 configs/milvus.yaml 后执行./scripts/stop.sh ./scripts/start_standalone.sh重启即可。dataCoord: compaction: clustering: enable: true autoEnable: true triggerInterval: 600 newDataSizeThreshold: 512m queryNode: enableSegmentPrune: trueenableSegmentPrune是查询侧开关漏掉它裁剪不生效。建集合时把查询里高频过滤的标量字段标为聚类键支持的类型有 Int8/16/32/64、Float、Double、VarChar基数控制在 10010000 比较合适from pymilvus import FieldSchema, CollectionSchema, DataType, Collection fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue), FieldSchema(nameuser_id, dtypeDataType.INT64, is_clustering_keyTrue), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim768), ] collection Collection(user_behavior, CollectionSchema(fields), shards_num4) collection.compact(is_clusteringTrue) collection.wait_for_compaction_completed(is_clusteringTrue, timeout3600)任务日志在logs/data_coord.log里搜 clustering compaction 可跟进进度。四组数据说清楚聚类压缩实测对比测试集为 LAION-400M 子集2000 万条 768 维向量4 节点 CPU 集群Intel Xeon 8375C、256GB RAM查询条件数据裁剪率平均延迟(ms)QPS 提升存储减少无过滤条件0%16851x32%user_id 200 AND 80040.2%10451.6x38%user_id 200 AND 40079.5%5503.1x42%user_id 100099%6825x45%快的关键在 partitionStats查询的过滤条件与聚类键区间对得越准能被整体跳过的数据段就越多条件精确命中时 99% 的段不用碰。所以提升幅度与过滤精度正相关——即便不加任何过滤条件合并小段本身也带来了 32% 的存储缩减。坑与旋钮Milvus 压缩参数怎么调⚙️ 五项高频场景按「场景 → 症状 → 解法」对照查询性能未提升→ 裁剪率指标为零 → 确认queryNode.enableSegmentPrune: true再看milvus_query_prune_ratio是否生效。压缩任务卡住→ data_coord.log 出现资源竞争 → 用dataCoord.compaction.clustering.timeout延长超时。存储未见缩减→ 向量本身已高度压缩 → 调dataNode.clusteringCompaction.memoryBufferRatio默认 0.3改变内存缓冲策略。压缩触发太频繁→ 写入密集导致反复重排 → 调大newDataSizeThreshold默认 512m并拉长triggerInterval默认 600s。已有分区键不想重复指定→ 手动维护聚类键繁琐 → 设置common.usePartitionKeyAsClusteringKey: true自动以分区键作为聚类键。接下来roadmap 与行动清单按 roadmap下一版本会引入自适应压缩算法依据向量分布自动选择压缩策略和增量聚类减少重复计算细节可看 20230511-collection_level_autocompaction_switch.md。配合 TTL 自动清理过期数据存储优化可以闭环collection.set_properties(properties{collection.ttl.seconds: 2592000}) 落地三步先在测试集群验证裁剪率跑上文四种查询条件确认 QPS 提升与裁剪率匹配。接入 Prometheus 盯指标跟踪milvus_compaction_clustering_total与milvus_query_prune_ratio长期观察压缩成功率与裁剪生效情况。回查聚类键选择核对线上过滤条件是否命中聚类键区间基数是否落在 10010000。 更多场景参考 tests/integration/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），仅供参考 延迟从 1685ms 压到 68ms：Milvus 聚类压缩背后的 25 倍加速
延迟从 1685ms 压到 68msMilvus 聚类压缩背后的 25 倍加速【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus当查询条件精确命中user_id 1000时2000 万向量集群的平均延迟从 1685ms 降到 68ms存储占用同步缩减 45%——干这件事的是 Milvus 的聚类压缩Clustering Compaction。它面向 768 维这类高维特征向量把存储和查询速度一起优化且不需要改变向量检索精度。Milvus 聚类压缩是怎么快的数据进来后的三次重排新数据写入后DataCoord 先判断增量是否超过newDataSizeThreshold达标才拉起压缩任务。接下来 DataNode 按聚类键Clustering Key对记录做全局重排让相同键值的行落到同一段随后把分散的小数据段Segment合并成大文件压低元数据开销并在落盘过程中生成分区统计信息partitionStats记下每个段覆盖的键值区间。查询进来时QueryNode 拿过滤条件去比对这些统计信息整段不命中的数据段直接跳过、不参与扫描——扫描范围变短就是延迟数字变小的全部原因。5 分钟上手启用 Milvus 聚类压缩功能需要 Milvus 2.4.7 版本。改完 configs/milvus.yaml 后执行./scripts/stop.sh ./scripts/start_standalone.sh重启即可。dataCoord: compaction: clustering: enable: true autoEnable: true triggerInterval: 600 newDataSizeThreshold: 512m queryNode: enableSegmentPrune: trueenableSegmentPrune是查询侧开关漏掉它裁剪不生效。建集合时把查询里高频过滤的标量字段标为聚类键支持的类型有 Int8/16/32/64、Float、Double、VarChar基数控制在 10010000 比较合适from pymilvus import FieldSchema, CollectionSchema, DataType, Collection fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue), FieldSchema(nameuser_id, dtypeDataType.INT64, is_clustering_keyTrue), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim768), ] collection Collection(user_behavior, CollectionSchema(fields), shards_num4) collection.compact(is_clusteringTrue) collection.wait_for_compaction_completed(is_clusteringTrue, timeout3600)任务日志在logs/data_coord.log里搜 clustering compaction 可跟进进度。四组数据说清楚聚类压缩实测对比测试集为 LAION-400M 子集2000 万条 768 维向量4 节点 CPU 集群Intel Xeon 8375C、256GB RAM查询条件数据裁剪率平均延迟(ms)QPS 提升存储减少无过滤条件0%16851x32%user_id 200 AND 80040.2%10451.6x38%user_id 200 AND 40079.5%5503.1x42%user_id 100099%6825x45%快的关键在 partitionStats查询的过滤条件与聚类键区间对得越准能被整体跳过的数据段就越多条件精确命中时 99% 的段不用碰。所以提升幅度与过滤精度正相关——即便不加任何过滤条件合并小段本身也带来了 32% 的存储缩减。坑与旋钮Milvus 压缩参数怎么调⚙️ 五项高频场景按「场景 → 症状 → 解法」对照查询性能未提升→ 裁剪率指标为零 → 确认queryNode.enableSegmentPrune: true再看milvus_query_prune_ratio是否生效。压缩任务卡住→ data_coord.log 出现资源竞争 → 用dataCoord.compaction.clustering.timeout延长超时。存储未见缩减→ 向量本身已高度压缩 → 调dataNode.clusteringCompaction.memoryBufferRatio默认 0.3改变内存缓冲策略。压缩触发太频繁→ 写入密集导致反复重排 → 调大newDataSizeThreshold默认 512m并拉长triggerInterval默认 600s。已有分区键不想重复指定→ 手动维护聚类键繁琐 → 设置common.usePartitionKeyAsClusteringKey: true自动以分区键作为聚类键。接下来roadmap 与行动清单按 roadmap下一版本会引入自适应压缩算法依据向量分布自动选择压缩策略和增量聚类减少重复计算细节可看 20230511-collection_level_autocompaction_switch.md。配合 TTL 自动清理过期数据存储优化可以闭环collection.set_properties(properties{collection.ttl.seconds: 2592000}) 落地三步先在测试集群验证裁剪率跑上文四种查询条件确认 QPS 提升与裁剪率匹配。接入 Prometheus 盯指标跟踪milvus_compaction_clustering_total与milvus_query_prune_ratio长期观察压缩成功率与裁剪生效情况。回查聚类键选择核对线上过滤条件是否命中聚类键区间基数是否落在 10010000。 更多场景参考 tests/integration/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），仅供参考