★ FEATURED ARTICLE 这篇值得聊聊。一个向量数据库发新版本标题里有三个信号很扎眼存储成本降85%、比ES快4-7倍、多数据类型支持。每个单独拎出来都有水分可挤但Milvus 2.6这次把三条线收到同一个版本里背后的设计逻辑其实是一体的。我在几个项目里从Milvus 2.2一路用过来也在ES和向量库之间反复横跳过这版GA值得记录的东西不少。如果你正在做RAG应用、多模态检索或者大规模日志/指标分析这篇文章会把数字背后的机制、迁移实测和踩坑点一次讲透。1. 三个核心卖点背后的同一套逻辑存储分层不是省钱的附赠品而是性能和类型的底座很多人看到“降本85%”就以为是存储供应商换了、单价便宜了其实Milvus 2.6云上GA这次推的三层存储架构动的是整个数据链路的组织方式。它把数据拆成原始数据、日志数据和索引数据三套体系再配上“热数据走本地SSD缓存、温数据走普通磁盘、冷数据落到对象存储”的调度策略。这个改法不只是为了省钱——数据分层的直接收益是内存和SSD资源不再被全量冷数据白白占着缓存命中率上去了查询路径短了多出来的性能余量又能支撑更复杂的标量过滤和更多数据类型。三个卖点其实是一条设计主线。1.1 三层存储到底分了什么层先说最容易被误解的概念。Milvus 2.6里的“三层”不是简单的“多级缓存”而是按数据角色切分原始数据Raw Data插入的向量和标量字段的原始值这是数据的源头不可丢。日志数据Log Data写入操作的增量日志用来做故障恢复和流式消费。早期版本依赖外部消息队列2.6云上GA里这部分和存储引擎做了更紧的耦合。索引数据Index Data经过索引构建后的结构直接服务查询可以随时从原始数据重建。这三层在物理上可以落在不同类型的存储上。比如原始数据和日志数据放对象存储索引数据按访问热度放在本地缓存和对象存储之间动态迁移。你可以把索引当作一个“可以随时从源头重算的中间产物”那么它放本地、放远端、换机器重建都不影响数据安全。这是2.6敢于把大量数据沉到对象存储的底气。1.2 降本85%是怎么算出来的我在某家云厂商的公开刊例价基础上按项目真实负载做过一个测算不同云报价有差异量级作为参考。假设我们要管理10TB向量加标量的全量数据其中热数据大概只有1.5TB剩下的8.5TB是低访问频次的归档数据全量放SSD按主流云盘大约0.0007元/GB/时计算单月存储费用大致在5000元量级。分层存储热数据1.5TB继续用SSD冷数据8.5TB放到对象存储对象存储月费大约是0.12元/GB再加上少量温数据使用普通云盘月费总的算下来大约700-800元。这确实能省到80%以上不同省份云资源价格有波动85%是官方给的典型值。这里必须强调一个容易误导的点降本85%不是说你的存储预算只剩15%而是说“冷热不分家”的大存储池子会小很多。如果你的数据体量只有几十GB、而且天天被全量扫描那分层带来的收益很有限甚至因为要维护缓存调度反而多了复杂度。我自己的判断标准是数据量超过2TB、冷数据占比超过60%才值得投入精力做分层策略。1.3 这套架构对查询时延的隐性影响对象存储虽然便宜但访问时延比本地盘高一个数量级。很多人担心这会让查询变慢实际2.6的处理策略是“索引和热数据优先驻留本地缓存冷数据按需加载并自动预热”。也就是说查询路径上首先打的是内存索引和本地SSD缓存碰不到的对象存储数据才走远端。从我们的压测结果看只要缓存命中率保持在90%以上P99时延和纯SSD方案差距能控制在10%以内。一旦缓存命中率掉到70%以下时延就会明显抬升。所以2.6的调参与以前很不一样现在最重要的监控指标不是CPU或内存而是缓存命中率。这个我在后面的上线检查清单里会展开说。2. 说比ES快4-7倍之前得先搞清楚ES和Milvus在解决两个不同的问题拿Milvus和Elasticsearch做性能对比是我一直觉得又合理又别扭的事。合理是因为在RAG应用里不少人确实在用ES的向量插件做混合检索别扭是因为两者架构设计的目标函数差异很大。ES本质是一个分布式全文检索引擎它的向量检索是在倒排索引体系上外挂的能力Milvus整个内核从数据模型到分段扫描机制都是为向量近邻搜索设计的。二者各有使用场景但一旦进入大规模向量并发检索领域差距就会显现。2.1 快4-7倍到底是怎么测出来的官方给的这个数字我理解对应的是一组特定条件数据量在百万到千万级向量、维度通常是768或1024、召回率阈值设定在90%以上、并发查询数上百、过滤条件同时加载。在这种条件下Milvus的分布式多分段并行扫描高效ANN索引的架构优势会发挥出来吞吐量和时延表现都明显优于ES。注意这里的“快”主要指的是QPS和P99时延不是单次检索的绝对速度。我从实践中的感受是这4-7倍不是在所有情况下都成立场景ES表现Milvus表现差距百万级向量、高并发、强过滤时延偏高CPU消耗大稳定QPS高明显6-7倍十万级向量、低并发、无过滤都很快都很快基本无感全文检索向量混合打分ES更有优势Milvus只做向量部分ES更合适千亿级向量、稀疏访问ES基本扛不住分层存储后仍可控Milvus强得多2.2 为什么架构差异决定了性能差异ES做向量检索时得先把向量字段当作一种特殊字段类型去建立专门的索引结构然后通过查询DSL把向量相似度计算嵌入到整个搜索流程里。它要同时处理倒排链合并、算分、过滤、聚合向量计算只是其中一环。Milvus则把数据切成按段segment管理的集合每个段内部有独立的索引结构查询时query node会把请求并行分发到多个段上再将结果做归并。这种设计能把CPU的SIMD指令效率拉满也能更好地利用多核并行。简单类比一下ES像是一个什么都卖的百货商场向量检索是其中一个柜台你逛商场时还得走过其他区域Milvus则像是一个专做一类产品的垂直仓库货物按区码放工人路线最短。你问一个百货商场的柜台效率和垂直仓库比谁出货快答案当然是看具体品类和流量。2.3 一个很容易被忽视的指标召回率和ES比的时候如果只比“谁返回的结果更像”不把召回率阈值设在同一水平线上对比就没有意义。ANN检索本质是在速度和精度之间取平衡把Milvus的召回率调到85%和调到95%时延能差出一倍多。我建议所有做选型对比的朋友都要在相同召回率的前提下做压测否则某一个“快5倍”的结论可能只是因为它牺牲了精度。2.6版本对HNSW索引参数做了不少底层优化在这个版本里把召回率拉到95%以上还能保持相对高的性能这在2.3版本里是很难做到的。2.4 混合搜索的正确打开方式这里得给ES说句公道话如果你需要的是“关键词全文检索向量相关性”这样的混合搜索比如搜索一个词组又希望语义相近的结果排前面那么ES仍然是更顺手的选择因为它的BM25和向量评分可以做线性融合。而Milvus在2.6里解决的是另一类问题向量主检索结构化字段过滤比如“找和这张图片最像的、同时必须属于某个用户分组且创建时间在一个时间范围内的结果”。这跟全文检索场景不是一个赛道。我们在实际项目中做了这样的切分全文检索保留ES向量召回和多路过滤给Milvus两者通过业务层做结果融合。这样各干各的强项比硬用一个引擎包打天下靠谱得多。3. 多数据类型支持索引体系和过滤表达式的整体升级标题里说的“多数据类型支持”如果只是理解成“可以存更多类型了”那会低估这个版本的变化。2.6 GA在标量字段的支持上往前迈了一大步新增了BOOL、INT8、INT16、VARCHAR、ARRAY、JSON的更多操作能力更重要的是这些字段可以与向量检索条件共同参与索引和过滤执行计划。这意味着很多原先要在业务代码里做后置过滤的场景现在可以直接下推到数据库内部完成这才是性能提升的真正来源之一。3.1 支持的数据类型和实用操作我从2.5到2.6的使用感受里最有用的是这几个更新ARRAY字段可以存标签列表、特征集合这类多值数据配合ARRAY_CONTAINS操作符做列表过滤。比如一条新闻可能属于多个栏目就能用ARRAY存储并直接过滤。JSON增强支持了更丰富的嵌套访问路径像json_extract(doc, $.author.id)这类操作可以直接在过滤条件里用。更多数值精度INT8和INT16在存储标签、分类ID、状态码这种有限取值的数据时可以大大节省内存尤其配合倒排索引做过滤内存占用和高并发表现都更好。3.2 过滤下推为什么说它比“能存”重要得多过去遇到“先按向量召回1000条再在应用层按条件过滤”的需求时整个链路的瓶颈往往不在这1000条的相似度计算上而在后续那层过滤。假设你有标签过滤能筛掉95%的结果这意味着一大半查询计算都在做无用功。2.6的多类型支持让标量字段进入存储引擎的索引体系——它会为这些字段单独建立标量索引查询时标量条件和向量检索条件共同参与执行计划生成先把不满足条件的分段整个跳过去再在剩余分段里做向量计算。这种方式将过滤从“召回后处理”变成了“检索前裁剪”效果立竿见影。3.3 一个实际场景多模态检索里的元数据过滤我去年做一个图片检索项目库里几百万张图每张图有向量、也有格式、大小、来源站点、授权类型、上架时间这些结构化信息。业务上经常要问“找相似图但只限某个来源、上架一周内、允许商用的”。2.6之前我得把图全部捞出来再过滤接口时延随候选集大小线性增长涨到平均400ms已经很难受了。2.6之后这些条件直接作为过滤表达式下推同样的查询时延掉到了70ms上下翻了近6倍。这就是“多数据类型支持”的价值——不是能存多种类型字段而是这些字段真正进入了检索优化链路。4. 从旧版本和ES迁移到2.6的实操路径无论你之前用的是Milvus旧版本还是起步就在ES上搭向量检索迁移到2.6都是个值得认真规划的事。我两条路都走过把关键步骤和坑拎出来讲讲。4.1 从Milvus旧版本升级的重点检查项如果你是从2.2或2.3升上来比较理想的路径是用官方提供的工具链做整体迁移。实际操作中有几个点特别容易翻车索引参数默认值变了2.6对新索引的构建参数要求更严格比如HNSW的efConstruction、M在旧版本里大家习惯了默认值跑到底2.6里这些参数的默认值有调整如果沿用旧配置可能导致构建时间成倍增加。建议逐参数确认不是升完就完事。元数据兼容性新旧版本的元数据存储结构有差异务必先在测试环境完整跑一遍升级脚本确认所有collection的schema、索引和分片信息正确映射再动生产。存量数据重做索引有的索引类型升级后需要重建才能发挥新版本性能优势我建议安排窗口期统一重建而不是边跑边建不然会看到部分查询性能很怪。升级的整体步骤先备份元数据和数据文件然后在测试集群验证兼容性跑完回归用例之后对生产集群做灰度切换。别跳步别信“就地平滑升级”的承诺数据库升级永远先假设会出事。4.2 从ES迁到Milvus的数据模型转换思路如果你现在ES里的向量字段用的是dense_vector迁到Milvus有几个思路性的差异要先理清向量的字段类型和维度声明方式不同ES的dense_vector声明在mapping里Milvus需要在collection schema里定义向量字段类型和维度。定义明确后数据本身导出成JSON再批量导入问题不大。过滤条件的表达方式要重写ES是JSON DSL嵌套结构Milvus是类似SQL的过滤表达式如source xxx and create_time 2025-01-01。把ES查询翻译成Milvus表达式时最麻烦的是嵌套bool逻辑需要手动拍平。建议先把所有过滤条件整理成标准清单再逐条翻译和验证。归一化问题如果你的原始向量没做归一化在ES里余弦距离可能需要预处理Milvus的COSINE或IP距离度量的处理方式不同建议先用小数据集验证距离分布是否和预期一致。数据导出分批执行ES一次能拉的数据量有限用scroll或sliced query分批导出批量写进Milvus。我导过千万级向量时间主要花在ES侧导出Milvus侧写入速度其实很稳。4.3 全文检索和向量检索的拆分决策前面已经提过我的结论不硬把全文检索挤进向量库。迁移中你可能会发现有些ES复合查询既包含全文又包含向量这时最好的办法是把它们拆开全文部分继续留在ES或导入专业搜索库向量部分进Milvus最终结果在业务应用层合并。一个我使用过的模式是双写新数据同时写入ES和Milvus查询时并行发请求再对各路结果做权重融合。等着重说一句不要为了少维护一个引擎把全文搜索硬塞给Milvus它确实能做分词吗不做你会被分词和相关性调校磨掉大量时间。5. 上线前要盯住的几个关键配置和容易出问题的点版本功能说完了最后集中写一写真正上线时会遇到的细节。这些内容不是官方文档里醒目标注的但没处理好足以让前期选型评估的成绩打折扣。5.1 缓存命中率是最需要盯住的指标2.6的分层存储架构决定了缓存策略会直接影响查询性能。上线前先把对象存储的bucket权限、数据预热任务、缓存大小这些参数配好。我的经验值是默认配置可能偏保守如果查询有明显热点建议适当调大索引缓存和SSD缓存上限。压测阶段一定要记录缓存命中率曲线如果发现命中率曲线随着数据增长快速下降说明缓存的淘汰策略或容量配置不合适尽早调整。5.2 索引类型和数据类型要提前想清楚不要等到数据大了才纠结索引类型。如果你主要场景是HNSW、数据量在千万级那构建参数M、efConstruction、efSearch需要提前压测选优如果场景里有大量频繁的标量过滤建议把高频过滤字段单独建成标量索引。多数据类型支持会让schema设计更方便但也更容易失控——我见过有人把ARRAY嵌套嵌到五层最后过滤表达式写出来自己都看不懂。第二层ARRAY以上我建议直接用反范式化拆成多个字段性能和维护都更友好。5.3 分段膨胀和孤儿数据是隐形炸弹Milvus的数据是按段管理的频繁的小批量写入会产生大量小分段分段多了查询和合并的性能都会受影响。2.6对自动压缩调优做了改进但我在实践中仍然建议写入尽量批量、有节奏避免频繁的零星导入。另一个容易被忽略的是删除操作删除标记累积多了也会拖累扫描效率必要时做compaction清理。5.4 压测不要只压“无过滤”场景选型阶段大家喜欢先跑一下“纯向量检索压测”看起来很爽但这跟上线的真实负载完全不同。实际业务查询几乎都会带过滤条件过滤组合的复杂性对性能影响巨大。我建议压测用例里至少包含高选择性过滤筛掉90%以上、低选择性过滤筛掉30%以下、无过滤、过滤字段不在索引中的情况这四类。这样才能得到真实的性能边界。压测数据也别用随机生成的向量最好从真实业务数据里抽样否则距离分布和索引结构都会和线上失真。5.5 小技巧利用预热任务保证缓存稳定最后分享一个我常用的做法。对典型的线上查询建一个定时预热任务把最近一小时的热点查询参数在低峰期预先跑一遍把相关索引块和标量数据拉进缓存。这样即使突然进入流量高峰缓存里已经有部分数据是热的P99时延能平稳不少。这个技巧在2.6的分层存储架构下比以前的版本更重要——冷数据加载的代价变高了主动预热能提前化解这个问题。从2.2一路用过来我最大的感触是Milvus的迭代方向很明确不盲目追求单机性能的峰值而是围绕大规模数据场景解决“存得下、查得快、管得动”的问题。2.6的三层存储、性能优化和多类型支持最终都指向一个目标——让向量检索真正成为可大规模生产化的基础设施。如果你正好在做选型评估发现自己的核心痛点是成本压不住、过滤场景多、数据量还在涨这版确实是值得认真测试的版本。但测试归测试还是要带上自己的数据和真实查询场景去验证任何人都无法替你的业务特征下结论。
阅读完成 · 觉得有帮助？
