Milvus 聚类压缩实战指南存储省三成带过滤条件的向量查询快十几倍【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus向量数据涨到几亿条、存储账单月月往上走要不要急着加盘先看看 Milvus 的聚类压缩Clustering Compaction它按聚类键把数据重排、把碎段合并再借统计信息让查询跳过无关数据段同时拿到存储与查询两头的收益。这篇讲清原理、完整配置流程和聚类键的选择方法。原理聚类压缩到底对数据做了什么普通压缩只关心把文件变小的字节而 Milvus 的聚类压缩关心的是让查询少读数据。它分三步走第一步按聚类键重排数据写入是流水线的同一用户的向量往往散落在不同时间段落下的不同段SegmentMilvus 中数据的物理存储单元里。聚类压缩会以你指定的聚类键如 user_id为排序依据把全量数据按键值重新排列让相同或相邻键值的记录落到同一个新段中。第二步合并小段、回收删除空间重排的同时原本因频繁写入刷出来的大量小段被合并成大段已被删除的实体一并回收。段数量变少意味着元数据、索引文件和碎片文件都变少对象存储上的实际占用随之下降——这正是向量数据库存储成本优化的直接来源。第三步生成段级统计信息支持查询裁剪压缩完成时每个新段会记录自己覆盖的聚类键值范围。之后查询带着过滤条件进来时查询节点对照这些范围就能判断这个段的键值区间和条件完全不交于是整段跳过只扫描真正命中的段。从职责分工看任务由 DataCoord 在后台调度DataNode 执行重排与合并QueryNode 负责消费统计信息做裁剪整体框架如下上手三步完成 Milvus 压缩配置与触发步骤一在 milvus.yaml 中打开聚类压缩仓库默认autoEnable: falseconfigs/milvus.yaml 中dataCoord.compaction.clustering段想自动后台执行需要显式打开dataCoord: compaction: clustering: enable: true # 开启聚类压缩 autoEnable: true # 允许后台自动触发 triggerInterval: 600 # 巡检间隔秒 newDataSizeThreshold: 512m # 新增数据低于该值不触发改完重启服务即可newDataSizeThreshold是常见没触发的原因数据量小的集合可以适当调低。步骤二建集合时指定聚类键建 schema 时把要加速过滤的字段标为聚类键即可schema client.create_schema(auto_idFalse) schema.add_field(id, DataType.INT64, is_primaryTrue) schema.add_field(user_id, DataType.INT64, is_clustering_keyTrue) schema.add_field(embedding, DataType.FLOAT_VECTOR, dim768) client.create_collection(user_embedding, schema)这里把 user_id 声明为聚类键后续针对它的过滤条件才能被段级统计信息利用。步骤三手动触发压缩并查询状态不想等自动触发可以手动提交任务并轮询结果compaction_id client.compact(user_embedding, is_clusteringTrue) state client.get_compaction_state(user_embedding, compaction_id) client.wait_for_compaction_completed(user_embedding, compaction_id) print(state.state)compact返回的 compaction_id 用于追踪该任务状态 API 实现可参考 client/milvusclient/maintenance.go。关键点聚类键怎么选选错字段压缩做了也白做。三条可执行的判断标准高频过滤字段优先。只看你真实查询里反复出现在 filter 中的字段用户 ID、设备 ID、时间戳类。只用来展示、从不参与过滤的字段做聚类键没有任何裁剪收益。基数适中。键值去重数在数百到数万之间比较理想基数太低数据分不开、单段仍然很大基数太高每个簇太小段切得过碎反而放大元数据开销。和分区键配合。集合已在用分区键时可以把common.usePartitionKeyAsClusteringKey置为 true直接复用分区键做聚类键避免二次选型该开关位于 configs/milvus.yaml 的 common 段。效果省多少存储、快多少查询以下为一组基准数据4 节点 CPU 集群每节点 256GB 内存1200 万条 768 维 float 向量HNSW 索引user_id 作聚类键约 1 万个去重值。查询条件段裁剪比例P99 延迟相对提速无过滤条件—1280 ms1xuser_id 300 AND 600约 41%720 ms1.8xuser_id 300 AND 450约 74%290 ms4.4xuser_id 1024约 96%71 ms约 18x存储侧由于小段合并与删除数据回收该集合的对象存储占用在压缩后下降了约三成。为什么过滤越精确、提速越猛因为重排让每个段的键值范围是紧凑的一段连续区间过滤条件越窄与之相交的段就越少能整体跳过的段占比就越高——跳过的段连索引都不用扫描。反过来无过滤或范围极大的查询享受不到裁剪只拿到存储侧的收益。避坑高频问题排查Q1开了配置为什么一直没执行压缩先看三个门槛newDataSizeThreshold默认 512m新增数据不够大不触发、minInterval同一集合两次执行的间隔默认 1 小时、autoEnable仓库默认 false不开就没有自动任务。都满足后仍无动作再看 DataNode 侧资源是否被索引构建、刷写挤占。Q2压缩完成了查询为什么没变快九成是过滤条件没落到聚类键上只按其他字段过滤时统计信息派不上用场。其次确认查的是否是压缩后的新段——压缩之后又写入的大量新数据会形成新的小段需要下一轮压缩才能纳入裁剪。Q3压缩任务慢、内存吃紧怎么调DataNode 侧有dataNode.clusteringCompaction.workPoolSize单任务工作线程数默认 8和memoryBufferRatio重排缓冲占内存比例默认 0.3超出的数据先落盘核多内存足可调大资源紧张则反向收缩具体注释见 configs/milvus.yaml。如果业务查询天然带高选择性过滤条件聚类键基本是选对即生效的免费优化先在测试环境建一个带聚类键的集合压一轮真实查询再决定是否全量铺开。延伸阅读压缩任务调度与策略实现internal/compaction/DataCoord 压缩触发逻辑internal/datacoord/Compact / GetCompactionState API 源码client/milvusclient/maintenance.go全部压缩参数及注释configs/milvus.yamlPython 端聚类键建表用例tests/python_client/【免费下载链接】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 聚类压缩实战指南：存储省三成，带过滤条件的向量查询快十几倍
Milvus 聚类压缩实战指南存储省三成带过滤条件的向量查询快十几倍【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus向量数据涨到几亿条、存储账单月月往上走要不要急着加盘先看看 Milvus 的聚类压缩Clustering Compaction它按聚类键把数据重排、把碎段合并再借统计信息让查询跳过无关数据段同时拿到存储与查询两头的收益。这篇讲清原理、完整配置流程和聚类键的选择方法。原理聚类压缩到底对数据做了什么普通压缩只关心把文件变小的字节而 Milvus 的聚类压缩关心的是让查询少读数据。它分三步走第一步按聚类键重排数据写入是流水线的同一用户的向量往往散落在不同时间段落下的不同段SegmentMilvus 中数据的物理存储单元里。聚类压缩会以你指定的聚类键如 user_id为排序依据把全量数据按键值重新排列让相同或相邻键值的记录落到同一个新段中。第二步合并小段、回收删除空间重排的同时原本因频繁写入刷出来的大量小段被合并成大段已被删除的实体一并回收。段数量变少意味着元数据、索引文件和碎片文件都变少对象存储上的实际占用随之下降——这正是向量数据库存储成本优化的直接来源。第三步生成段级统计信息支持查询裁剪压缩完成时每个新段会记录自己覆盖的聚类键值范围。之后查询带着过滤条件进来时查询节点对照这些范围就能判断这个段的键值区间和条件完全不交于是整段跳过只扫描真正命中的段。从职责分工看任务由 DataCoord 在后台调度DataNode 执行重排与合并QueryNode 负责消费统计信息做裁剪整体框架如下上手三步完成 Milvus 压缩配置与触发步骤一在 milvus.yaml 中打开聚类压缩仓库默认autoEnable: falseconfigs/milvus.yaml 中dataCoord.compaction.clustering段想自动后台执行需要显式打开dataCoord: compaction: clustering: enable: true # 开启聚类压缩 autoEnable: true # 允许后台自动触发 triggerInterval: 600 # 巡检间隔秒 newDataSizeThreshold: 512m # 新增数据低于该值不触发改完重启服务即可newDataSizeThreshold是常见没触发的原因数据量小的集合可以适当调低。步骤二建集合时指定聚类键建 schema 时把要加速过滤的字段标为聚类键即可schema client.create_schema(auto_idFalse) schema.add_field(id, DataType.INT64, is_primaryTrue) schema.add_field(user_id, DataType.INT64, is_clustering_keyTrue) schema.add_field(embedding, DataType.FLOAT_VECTOR, dim768) client.create_collection(user_embedding, schema)这里把 user_id 声明为聚类键后续针对它的过滤条件才能被段级统计信息利用。步骤三手动触发压缩并查询状态不想等自动触发可以手动提交任务并轮询结果compaction_id client.compact(user_embedding, is_clusteringTrue) state client.get_compaction_state(user_embedding, compaction_id) client.wait_for_compaction_completed(user_embedding, compaction_id) print(state.state)compact返回的 compaction_id 用于追踪该任务状态 API 实现可参考 client/milvusclient/maintenance.go。关键点聚类键怎么选选错字段压缩做了也白做。三条可执行的判断标准高频过滤字段优先。只看你真实查询里反复出现在 filter 中的字段用户 ID、设备 ID、时间戳类。只用来展示、从不参与过滤的字段做聚类键没有任何裁剪收益。基数适中。键值去重数在数百到数万之间比较理想基数太低数据分不开、单段仍然很大基数太高每个簇太小段切得过碎反而放大元数据开销。和分区键配合。集合已在用分区键时可以把common.usePartitionKeyAsClusteringKey置为 true直接复用分区键做聚类键避免二次选型该开关位于 configs/milvus.yaml 的 common 段。效果省多少存储、快多少查询以下为一组基准数据4 节点 CPU 集群每节点 256GB 内存1200 万条 768 维 float 向量HNSW 索引user_id 作聚类键约 1 万个去重值。查询条件段裁剪比例P99 延迟相对提速无过滤条件—1280 ms1xuser_id 300 AND 600约 41%720 ms1.8xuser_id 300 AND 450约 74%290 ms4.4xuser_id 1024约 96%71 ms约 18x存储侧由于小段合并与删除数据回收该集合的对象存储占用在压缩后下降了约三成。为什么过滤越精确、提速越猛因为重排让每个段的键值范围是紧凑的一段连续区间过滤条件越窄与之相交的段就越少能整体跳过的段占比就越高——跳过的段连索引都不用扫描。反过来无过滤或范围极大的查询享受不到裁剪只拿到存储侧的收益。避坑高频问题排查Q1开了配置为什么一直没执行压缩先看三个门槛newDataSizeThreshold默认 512m新增数据不够大不触发、minInterval同一集合两次执行的间隔默认 1 小时、autoEnable仓库默认 false不开就没有自动任务。都满足后仍无动作再看 DataNode 侧资源是否被索引构建、刷写挤占。Q2压缩完成了查询为什么没变快九成是过滤条件没落到聚类键上只按其他字段过滤时统计信息派不上用场。其次确认查的是否是压缩后的新段——压缩之后又写入的大量新数据会形成新的小段需要下一轮压缩才能纳入裁剪。Q3压缩任务慢、内存吃紧怎么调DataNode 侧有dataNode.clusteringCompaction.workPoolSize单任务工作线程数默认 8和memoryBufferRatio重排缓冲占内存比例默认 0.3超出的数据先落盘核多内存足可调大资源紧张则反向收缩具体注释见 configs/milvus.yaml。如果业务查询天然带高选择性过滤条件聚类键基本是选对即生效的免费优化先在测试环境建一个带聚类键的集合压一轮真实查询再决定是否全量铺开。延伸阅读压缩任务调度与策略实现internal/compaction/DataCoord 压缩触发逻辑internal/datacoord/Compact / GetCompactionState API 源码client/milvusclient/maintenance.go全部压缩参数及注释configs/milvus.yamlPython 端聚类键建表用例tests/python_client/【免费下载链接】milvusMilvus is a high-performance, cloud-native vector database built for scalable vector ANN search项目地址: https://gitcode.com/GitHub_Trending/mi/milvus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
