万字深度长文：8年向量数据库经验总结，为何我们要为Milvus重构AI时代的存储引擎

过去八九年，我们一直专注于将向量数据库从一个相对小众的技术方向，打造成为AI基础设施中的关键组件。在这个过程中，我们听到了许多建议，也获得了不少成长。但与此同时，也有不少人试图说服我们：传统数据库不是已经能存储各种数据类型了吗？加一个向量字段类型，配上一个ANN索引，向量数据库就要面临淘汰了。

向量数据的本质特征

坦率地说，很多传统数据库确实也采用了类似的策略：增加一列vector字段，接入一个向量索引，demo能够运行，也确实有一些企业在语义检索初期会选择这样的方案。但当业务规模发展到一定程度之后，就会发现传统数据库加补丁的方式，根本无法解决AI时代面临的新问题。向量不仅仅是一种新的字段类型，更是一种全新的数据形态。

问题一：写放大困境

从存储模型设计的角度来看，向量数据具有独特的复合特性：它有表结构、行记录和主键，看起来像传统数据库；它的规模巨大，需要被Spark、Ray、DuckDB、训练pipeline和评估系统反复读取和改写，看起来又像数据湖；它的原始对象往往是视频、图片、PDF、音频，通常继续保留在对象存储服务中。然而，向量数据还多了一层传统系统没有很好处理的内容：embedding、sparse vector、caption、vector index、text index、delete log、stats，以及外部对象引用之间不断变化的版本关系。

问题二：读路径冲突

过去十年，lakehouse生态中最常见的存储选择是Parquet这类列存格式。它适合分析型负载：字段相对稳定，数据多读少改，扫描时只读取需要的列，压缩率高，生态成熟。但在AI工作流中，向量数据打破了少改多读这一核心前提。以LAION-5B为例，每条记录包含一个URL、一段caption、几个数值字段，以及一份CLIP embedding。仅768维fp32格式的向量就有3KB，而1024到2048维的embedding单条可达4到8KB。相比传统TPC-H测试基准中每行约150字节的数据，向量数据单行字节数是其20倍以上。这直接导致两个严重后果：每次schema演进都意味着TB级数据工程；每次caption修订都可能在旧存储布局下触发数百万row id的物理重写，GB级别的I/O开销。

问题三：多引擎协作挑战

当同一份向量数据同时服务列式扫描和行级点查时，问题更加复杂。列式扫描（如WHERE过滤、离线分析）喜欢连续I/O、大row group、高压缩率；行级点查（ANN检索后的回表操作）则需要低延迟随机访问、按需解码。一个文件格式无法同时满足这两种截然相反的需求。更棘手的是，hybrid search会在同一次查询中同时触发两种读法：先用标量字段过滤，再用ANN召回，最后按row id回表取caption、vector和metadata。这意味着同一份数据在200毫秒内需要完成两种截然不同的访问模式。

如有侵权，请联系删除。