Milvus 3.0 开源解读｜如何借助原生 TEXT 类型和 LOB 高效管理原始文本

在AI检索系统中，Embedding向量化技术让我们能够快速找到语义相近的内容。然而，从TEXT_MATCH、BM25等词法检索，到reranking重排序、答案生成、高亮展示和安全审计，系统始终需要保存并访问原始文本。 早期，行业普遍采用向量数据库+外部存储的解耦架构：向量数据库仅存放Embedding和简单元数据，而长文档正文、代码段、日志等则存放在S3、MongoDB或Elasticsearch中。这种架构虽然在一定程度上缓解了存储压力，却带来了新的问题——数据不一致风险、冗长链路以及难以保证的原子性操作。

一、TEXT类型：重新定义长文本的数据模型

具体而言，当需要更新或删除文档时，必须同时操作外部存储与向量数据库。在分布式网络环境下，这种跨系统的协同极易引发数据不一致：向量检索可能命中某条记录，但取回的正文却是错误版本或根本缺失。 混合检索场景进一步放大了这一问题。如果原始文本不在向量数据库内，BM25倒排索引的构建与全文过滤就必须依赖外部组件，导致检索链路冗长且难以保证原子性。 既然如此，为何不直接将正文存入数据库？一个重要原因在于：如果简单地将巨量原始文本作为普通字符串列塞入向量数据库，大Payload会进入内存缓冲区、flush、compaction和I/O的每一个环节。百KB到数MB的长文本会迅速挤爆内存，并在数据合并重构时引发严重的磁盘与网络写放大问题。

二、LOB存储策略：混合布局化解性能困境

Milvus 3.0引入DataType.TEXT和LOB存储路径，旨在让长文本像稠密向量、稀疏向量和标量字段一样，成为数据库中的一等公民，并纳入对象存储的完整生命周期管理。 首先需要区分TEXT与VARCHAR的适用场景。对于标签、状态、名称、类别、ID等短元数据，VARCHAR依然是更合适的选择。TEXT则专门面向更长的内容场景：RAG chunk文本、文档正文、源代码、日志、客服对话、多语言文本，以及需要参与全文检索或混合检索的字段。 TEXT类型支持与analyzer、text_match、BM25以及稠密向量的混合搜索配合使用。这意味着从数据模型层面看，正文终于可以和向量、标量字段放在同一个Collection中进行统一管理。

三、Compaction优化：避免无意义的写放大

为什么Milvus需要为TEXT单独设计LOB机制，而非继续像普通Segment列一样保存？原因主要有四点： 1. Growing Segment的内存压力会迅速放大：Milvus要求刚写入的数据立即可查，QueryNode中的Growing Segment必须能够访问最近写入的数据。对于普通标量字段，这部分数据通常不大。但当一行数据携带几百KB甚至数MB的正文时，决定内存占用的可能不再是向量，而是文本Payload本身。 2. 写入链路可能重复保存同一份大文本：传统写入链路可简化为WAL → StreamingNode write buffer → object storage。与此同时，QueryNode本身也需要访问刚写入的数据以支持Growing Data查询。如果StreamingNode为等待flush而保留一份完整Payload，查询侧已经持有一份，则同一份正文在内存中被重复保存。 3. Compaction带来的写放大：Compaction的目的是整理Segment、处理删除记录并重组数据。但如果长文本与其他字段始终捆绑在同一个Segment文件中，哪

为在读取性能与存储开销之间取得最佳平衡，Milvus 3.0并未将所有TEXT都无条件拆成独立文件，而是在存储底层通过混合存储布局引入动态分层处理机制。 系统根据文本Payload体积自动切换保存策略：短文本直接存放在Segment中，大文本则转为LOB文件并在Segment中保存引用。当前默认阈值为64 KiB，具体参数可配置。这种设计的精妙之处在于：TEXT是应用层的数据类型，而inline和LOB是底层根据Payload大小采用的两种存储方式。 小文本继续保持Inline状态，直接保存在Segment中，常规读取依然轻量；大文本则移到独立的LOB文件中，Segment只保留对应引用。内存中的Growing Segment和写缓冲区不再需要常驻巨量Payload，显著降低了内存压力。 Compaction阶段，Milvus引入hole ratio指标来评估LOB文件是否值得复用。如果hole ratio较低，继续使用已有LOB文件，只复制或更新引用；如果hole ratio较高，则只把仍然有效的文本重新写入新的LOB文件。这样就避免了一个典型的写放大场景：明明只删

如有侵权，请联系删除。