Milvus 聚类压缩带过滤条件的向量查询从 1685ms 到 68ms存储再省四成【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus如果你的 Milvus 集合动辄上亿条 768 维向量而查询里几乎总带着user_id这类标量过滤条件那么全量扫描的延迟和存储账单都会很难看。本文给出聚类压缩Clustering Compaction的最小落地路径过滤命中越精确延迟可从 1685ms 降到 68ms同时存储占用减少约 30%-45%。原理按聚类键重排数据让过滤条件跳过整段 segment输入是写入产生的大量碎片化 L2 segment。DataCoord 按triggerInterval周期性检查各集合当新数据量超过阈值后触发任务DataNode 先对聚类键字段做 K-Means 训练中心点数量在minCentroidsNum16 与maxCentroidsNum10240 之间自适应再按聚类结果把同一簇的数据重写进更大的 segment同时生成 partition stats 统计信息。输出就是一组按簇排布的大 segment 加一份可供查询裁剪的统计文件。和普通的 mix compaction 差在哪mix 只做小段合并和删除回收不改变数据在 segment 内的排列顺序聚类压缩会全局重排数据这是查询侧能做 segment 级裁剪的前提。上图是 Milvus 检索链路的时序查询模块先从文件系统集成加载索引序列化数据再经 Knowhere 执行Query()。聚类压缩生成的 stats 让这一步可以先按过滤条件排除整段 segment而不是逐条过滤。最小可运行路径改配置、建集合、触发验证该功能自 Milvus 2.4.7 引入具体发行版以官方 release 为准需确认依赖对象存储与 DataCoord/DataNode/QueryNode 完整部署。第一步改配置。编辑configs/milvus.yaml# configs/milvus.yaml dataCoord: compaction: clustering: enable: true # 总开关默认已是 true autoEnable: true # 默认 false打开后后台自动执行 triggerInterval: 600 # 检查间隔秒 newDataSizeThreshold: 512m # 新数据超过此值才触发 queryNode: enableSegmentPrune: true # 默认 false查询侧裁剪必须打开第二步建集合时指定聚类键。推荐选查询中高频过滤的标量字段Int8/16/32/64、Float、Double、VarChar 均可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), ] schema CollectionSchema(fields) col Collection(nameuser_behavior, schemaschema, shards_num4)Go SDK 同样支持仓库内client/entity/field.go提供了WithIsClusteringKey(true)构造方法。第三步触发压缩并验证。from pymilvus import utility cid utility.compact(col.name) # 触发压缩任务 utility.wait_for_compaction_completed(col.name, cid) # 阻塞等待完成 print(utility.get_compaction_state(col.name, cid)) # 查看任务状态注意 SDK 暴露的触发参数是否区分is_clustering需按所用版本确认需确认。压缩完成后跑一条带过滤的检索对比开启enableSegmentPrune前后的延迟即可验证。效果与数据过滤越精确收益越大以下数据来自对 LAION-400M 子集2000 万条 768 维向量的测试环境为 4 节点 CPU 集群Intel Xeon 8375C单节点 256GB 内存结果复现以实测为准需确认查询条件数据裁剪率平均延迟(ms)QPS 提升无过滤条件0%16851xuser_id 200 AND 80040.2%10451.6xuser_id 200 AND 40079.5%5503.1xuser_id 100099%6825x梯度来自裁剪的粒度裁剪发生在 segment 级过滤条件命中的簇越少、能整体跳过的 segment 越多省下的就是整段向量的加载与距离计算等值查询把候选压到单一簇附近所以拿到 25 倍。无过滤条件时裁剪率为 0延迟基本不变但存储占用仍因小段合并与去重而下降。调优参数与踩坑清单以下默认值取自configs/milvus.yaml参数默认值什么时候该动它dataCoord.compaction.clustering.autoEnablefalse想让后台自动压缩时必须打开...clustering.newDataSizeThreshold512m写入频繁时调大减少压缩频率...clustering.minInterval/maxInterval3600 / 259200 秒控制同一集合两次压缩的最小/最大间隔queryNode.enableSegmentPrunefalse查询侧要生效必须设为 truedataNode.clusteringCompaction.workPoolSize8CPU 多核节点可增大dataNode.clusteringCompaction.memoryBufferRatio0.3压缩期间内存吃紧时调小common.usePartitionKeyAsClusteringKeyfalse已有分区键、想复用其做裁剪时打开dataCoord.slot.clusteringCompactionUsage65535默认独占一个 worker与其他任务冲突时下调踩坑清单压缩任务长时间不结束其他任务排队→ 默认clusteringCompactionUsage: 65535占满整个 worker压缩期间 mix/L0 压缩被阻塞 → 接受独占或调小该 slot 值并观察资源。查询延迟没变化→queryNode.enableSegmentPrune默认 false裁剪根本没生效 → 改为 true 后重载 QueryNode再用查询日志确认裁剪是否命中。存储没有明显下降→ 向量本身未膨胀或簇数过多导致小 segment 依然多 → 收紧maxCentroidsNum默认 10240或确认集合规模是否足够大。小集合永远不触发压缩→ 新数据量未达newDataSizeThreshold512m且未超maxInterval→ 等待数据积累或手动触发。组合用法两个常见搭配其一集合已用分区键时打开common.usePartitionKeyAsClusteringKey: true直接把分区键当聚类键免去重复指定其二与集合 TTL 配合定期清理过期数据再叠加聚类压缩先删后压存储账单降得更干净TTL 属性名collection.ttl.seconds以所用版本为准需确认。# 分区键复用作聚类键改配置即可无需改代码 # common.usePartitionKeyAsClusteringKey true col.set_properties({collection.ttl.seconds: 2592000}) # TTL 30 天需确认一句话结论聚类压缩把过滤 向量检索从全量扫描变成按簇裁剪过滤精度决定收益上限。下一步建议在你自己的过滤型查询上复跑一遍上文对照实验并把压缩任务成功率、裁剪率纳入监控。实现细节可读仓库内的设计文档 20230511-collection_level_autocompaction_switch.md触发策略源码见 internal/datacoord/compaction_policy_clustering.go。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Milvus 聚类压缩：带过滤条件的向量查询从 1685ms 到 68ms，存储再省四成
Milvus 聚类压缩带过滤条件的向量查询从 1685ms 到 68ms存储再省四成【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus如果你的 Milvus 集合动辄上亿条 768 维向量而查询里几乎总带着user_id这类标量过滤条件那么全量扫描的延迟和存储账单都会很难看。本文给出聚类压缩Clustering Compaction的最小落地路径过滤命中越精确延迟可从 1685ms 降到 68ms同时存储占用减少约 30%-45%。原理按聚类键重排数据让过滤条件跳过整段 segment输入是写入产生的大量碎片化 L2 segment。DataCoord 按triggerInterval周期性检查各集合当新数据量超过阈值后触发任务DataNode 先对聚类键字段做 K-Means 训练中心点数量在minCentroidsNum16 与maxCentroidsNum10240 之间自适应再按聚类结果把同一簇的数据重写进更大的 segment同时生成 partition stats 统计信息。输出就是一组按簇排布的大 segment 加一份可供查询裁剪的统计文件。和普通的 mix compaction 差在哪mix 只做小段合并和删除回收不改变数据在 segment 内的排列顺序聚类压缩会全局重排数据这是查询侧能做 segment 级裁剪的前提。上图是 Milvus 检索链路的时序查询模块先从文件系统集成加载索引序列化数据再经 Knowhere 执行Query()。聚类压缩生成的 stats 让这一步可以先按过滤条件排除整段 segment而不是逐条过滤。最小可运行路径改配置、建集合、触发验证该功能自 Milvus 2.4.7 引入具体发行版以官方 release 为准需确认依赖对象存储与 DataCoord/DataNode/QueryNode 完整部署。第一步改配置。编辑configs/milvus.yaml# configs/milvus.yaml dataCoord: compaction: clustering: enable: true # 总开关默认已是 true autoEnable: true # 默认 false打开后后台自动执行 triggerInterval: 600 # 检查间隔秒 newDataSizeThreshold: 512m # 新数据超过此值才触发 queryNode: enableSegmentPrune: true # 默认 false查询侧裁剪必须打开第二步建集合时指定聚类键。推荐选查询中高频过滤的标量字段Int8/16/32/64、Float、Double、VarChar 均可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), ] schema CollectionSchema(fields) col Collection(nameuser_behavior, schemaschema, shards_num4)Go SDK 同样支持仓库内client/entity/field.go提供了WithIsClusteringKey(true)构造方法。第三步触发压缩并验证。from pymilvus import utility cid utility.compact(col.name) # 触发压缩任务 utility.wait_for_compaction_completed(col.name, cid) # 阻塞等待完成 print(utility.get_compaction_state(col.name, cid)) # 查看任务状态注意 SDK 暴露的触发参数是否区分is_clustering需按所用版本确认需确认。压缩完成后跑一条带过滤的检索对比开启enableSegmentPrune前后的延迟即可验证。效果与数据过滤越精确收益越大以下数据来自对 LAION-400M 子集2000 万条 768 维向量的测试环境为 4 节点 CPU 集群Intel Xeon 8375C单节点 256GB 内存结果复现以实测为准需确认查询条件数据裁剪率平均延迟(ms)QPS 提升无过滤条件0%16851xuser_id 200 AND 80040.2%10451.6xuser_id 200 AND 40079.5%5503.1xuser_id 100099%6825x梯度来自裁剪的粒度裁剪发生在 segment 级过滤条件命中的簇越少、能整体跳过的 segment 越多省下的就是整段向量的加载与距离计算等值查询把候选压到单一簇附近所以拿到 25 倍。无过滤条件时裁剪率为 0延迟基本不变但存储占用仍因小段合并与去重而下降。调优参数与踩坑清单以下默认值取自configs/milvus.yaml参数默认值什么时候该动它dataCoord.compaction.clustering.autoEnablefalse想让后台自动压缩时必须打开...clustering.newDataSizeThreshold512m写入频繁时调大减少压缩频率...clustering.minInterval/maxInterval3600 / 259200 秒控制同一集合两次压缩的最小/最大间隔queryNode.enableSegmentPrunefalse查询侧要生效必须设为 truedataNode.clusteringCompaction.workPoolSize8CPU 多核节点可增大dataNode.clusteringCompaction.memoryBufferRatio0.3压缩期间内存吃紧时调小common.usePartitionKeyAsClusteringKeyfalse已有分区键、想复用其做裁剪时打开dataCoord.slot.clusteringCompactionUsage65535默认独占一个 worker与其他任务冲突时下调踩坑清单压缩任务长时间不结束其他任务排队→ 默认clusteringCompactionUsage: 65535占满整个 worker压缩期间 mix/L0 压缩被阻塞 → 接受独占或调小该 slot 值并观察资源。查询延迟没变化→queryNode.enableSegmentPrune默认 false裁剪根本没生效 → 改为 true 后重载 QueryNode再用查询日志确认裁剪是否命中。存储没有明显下降→ 向量本身未膨胀或簇数过多导致小 segment 依然多 → 收紧maxCentroidsNum默认 10240或确认集合规模是否足够大。小集合永远不触发压缩→ 新数据量未达newDataSizeThreshold512m且未超maxInterval→ 等待数据积累或手动触发。组合用法两个常见搭配其一集合已用分区键时打开common.usePartitionKeyAsClusteringKey: true直接把分区键当聚类键免去重复指定其二与集合 TTL 配合定期清理过期数据再叠加聚类压缩先删后压存储账单降得更干净TTL 属性名collection.ttl.seconds以所用版本为准需确认。# 分区键复用作聚类键改配置即可无需改代码 # common.usePartitionKeyAsClusteringKey true col.set_properties({collection.ttl.seconds: 2592000}) # TTL 30 天需确认一句话结论聚类压缩把过滤 向量检索从全量扫描变成按簇裁剪过滤精度决定收益上限。下一步建议在你自己的过滤型查询上复跑一遍上文对照实验并把压缩任务成功率、裁剪率纳入监控。实现细节可读仓库内的设计文档 20230511-collection_level_autocompaction_switch.md触发策略源码见 internal/datacoord/compaction_policy_clustering.go。【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考