用8年时间将向量数据库做到极致后，我们为何又推出了Vector Lakebase？

Zilliz 在2019 年正式开源Milvus，成为全球第一家向量数据库企业时，行业对向量搜索的认知，还是给图片、文本、商品、文档算一个 embedding，然后查语义相似，只要能跑起来，就万事大吉。

但我们一直相信，这些产品行为、用户内容、企业知识库、实验数据、历史对话、Agent 记忆，始终是一个企业最宝贵的数据资产。只要一种数据会被持续写入、长期保存、反复查询，并且会影响线上体验，它就应该需要独立的存储、索引、调度、隔离、容灾恢复和成本模型。

也是因此，向量数据的管理，不该只是一个功能，作为一种会影响未来企业发展质量的新的数据形态，它需要一个专门的产品，将它的性能、体验、门槛，做到极致。

而过去8年多时间里，我们也一直在深耕这件事。产品结构上，我们从单机走向分布式，从本地走上云端。能力上，我们优化了很多细节：量化，索引结构，缓存，预取，冷热分层。

通过将数据加载到本地缓存，向量检索的速度，已经可以做到百亿数据毫秒级检索，Milvus与Zilliz Cloud成为了向量数据库极致性能的代名词。

但现实商业世界中，永远存在成本、性能、体验的不可能三角。在传统向量检索架构里，只要数据要保持随时可查询，背后就需要计算与内存资源持续在线。但极致的在线检索性能，真的是所有场景下的必需吗？

现如今，冷数据的占比正越来越高。有时候，一次 A/B 实验结束后，相关 embedding 可能很少再被访问。一个 SaaS 产品里，大量用户不会每天登录。企业知识库中，很多文档几个月都不会有被检索需求。自动驾驶的数据训练，一批数据，我们往往每个月只需要使用一到两次。

在这些场景，一个集合也许一个月只被查询几次，运行时间不超过5小时，用户也并不需要为此投入向量数据库级别的资源建设，让高性能资源一个月时间里有715小时都被浪费。相应的，成本也就成了这一场景下的优先考量要素。

而解决这一问题，也是我们选择在近期推出Vector Lakebase 产品的初心所在。

传统向量数据库，是如何实现高性能在线检索的？

传统向量数据库的架构，本质上是为高频使用的在线服务优化的。而低延迟的向量搜索，需要索引尽量靠近计算，以CPU内存、本地磁盘存储之类的形式存在。

以 HNSW 为例，它是用内存和计算，换取更低查询延迟的典型代表。在HNSW，查询并不是顺序读取一个文件里的所有向量，而是从图中的入口节点开始，沿着更接近查询向量的邻居逐步跳转。在这个过程中，系统不断计算查询向量与候选节点的距离，并更新候选集，一次查询通常需要跳转、计算数百个节点。

如果上百步的读取，每一步都跨网络去S3为代表的对象存储读取，S3本身几十毫秒的远程 I/O 会被重复放大，最终让查询延迟远远超过在线服务可接受的范围。

也是因此，一个典型的向量数据库架构是这样的：S3 只负责保存完整数据

，但真正服务在线查询的，通常是 QueryNode 本地的内存、磁盘和缓存。

一个 collection 想要随时响应查询，就需要提前把 segment 和索引从S3加载到 QueryNode。

在此模式下， 1 亿条 768 维 float32 向量，其原始向量大约 286 GB。如果使用 HNSW，M=48 的图结构还会带来约 55 GB 的邻居链接，使得整体数据和索引接近 340 GB。

然后传统 QueryNode 模型，通常会把这些数据拆到3台在线的128G的机器上，以24,000 美金的年费，保证其高性能的实时在线检索效率。

100M × 768 维 float32

原始向量 + HNSW 图结构

总量约 340 GB

QueryNode 1：128 GB RAM + NVMe，加载约 113 GB segment

QueryNode 2：128 GB RAM + NVMe，加载约 113 GB segment

QueryNode 3：128 GB RAM + NVMe，加载约 113 GB segment

S3 保存完整 340 GB 数据，作为 source of truth。

QueryNode 把 segment 和索引加载到本地，并提供查询服务。

但问题是，对于我们开头提到的那种一个月只加载一次的数据，其实并不需要如此高性能的配置。

那有没有可能，把向量数据放在 S3 ，让查询与计算能自动按需启动、按需加载、按需释放？每个月用多久、用多少，就按照实际使用的资源计费？同时还能保证过滤搜索、语义检索、权限设计，以及在工作负载高峰期的检索效率。

答案是可以，这正是 Vector Lakebase 要解决的问题。

实现Vector Lakebase按需搜索，为什么这么难？

过去的向量搜索，为了保证在线响应效率，必须把数据可查询、 计算资源常驻绑定在一起，

而Vector Lakebase 要做的，就是把这两件事解耦：让数据可以常驻在对象存储；计算服务按需启动与释放。

对于热数据，系统仍然可以always-on serving。索引常驻本地，查询路径最短，目标是低延迟、高 QPS 和稳定 P99。

对于冷数据，系统可以使用 on-demand search。让数据和索引持久存在对象存储里。查询发生时，再启动计算资源，加载必要的索引元数据和相关数据块，完成搜索后释放资源。

但要达到这个效果，需要克服冷启动速度、单次查询总量可控、 I/O 放大以及控制平面成本等至少四大问题。

第一关：如何解决海量原始索引的冷启动效率

如果按传统方式处理冷数据查询，那么340 GB HNSW 索引，光是从S3拉起到本地，所需的冷启动时间就会直接超过 4 分钟。用户发起一次搜索需要等几分钟，产品体验约等于零。

所以 Lakebase 要解决的第一个问题，是如何让冷数据尽快进入可搜索状态。为此，我们做了三大针对性优化。

优化一：用 1+3-bit matryoshka quantization 缩小冷启动索引

Lakebase 的第一步，就是把需要加载的索引压缩到足够小的可用状态。

这里我们使用的是基于 RabitQ（Gao & Long, 2024）构建的 1+3-bit 套娃式量化。

第一步，我们会在1bit量化压缩过的数据上进行初步检索（该模式下，数据加载量仅为HNSW的三十分之一）。此外，由于RabitQ 会提供 1-bit 距离误差边界，让系统可以更安全地剪枝候选结果，这一轮搜索的recall 可以达到 85% 到 90%。

在1bit数据进行计算时，3bit量化的数据也在这个过程中被加载好，然后对 1-bit 阶段留下的候选结果，做1+3 bit精度的重新评分，最终实现95%的召回。

两层之间，1bit负责过滤，3bit负责优化。

优化二：降低量化误差，避免压缩牺牲 recall

量化解决了加载速度问题，但也带来另一个风险：量化误差可能影响召回质量。

因此，Lakebase 在量化质量上做了两点优化。

第一是 per-vector optimal scaling。

系统不会让所有向量共享同一个全局缩放因子，而是为每个向量单独选择更合适的 scaling，使每个向量的量化误差最小化。

第二是基于维度方差的非均匀 bit allocation。

不同维度承载的信息量并不相同。方差更高、区分度更强的维度，会获得更多 bit；信息量较低的维度，则使用更少 bit。

这两项优化，可以在不增加索引体积的前提下，尽量降低量化误差，让压缩后的索引仍然保持较高 recall。

优化三：用 GPU 和 AVX-512 避免量化本身成为瓶颈

量化还会带来一个工程问题，量化计算本身也很耗费资源。为此，Lakebase 在索引构建和查询执行路径上都做了硬件优化。

索引构建阶段使用 GPU 加速，降低上亿规模向量量化和索引生成的时间成本。

查询阶段则使用AVX-512/ARM SVE优化距离计算，提高 CPU 上的计算吞吐。

到这里，Lakebase 已经解决了冷启动中关于数据压缩的第一个大问题。但这还不够，如果每次查询仍然要扫描 1 亿条向量，计算成本还是太高。

第二关：如何避免冷数据的全量扫描

按需计算的成本以及用户体验取决于两件事：启动多快，以及多久能释放。

尽管有1-bit 索引压缩启动时间，但对 1 亿条向量做计算，整体的资源消耗时间仍然不容小觑。

所以 Lakebase 还需要减少每次查询真正访问的数据量。

为了解决这个问题，我们使用了 IVF clustering 和全局索引剪枝。

查询开始前，系统会把向量聚成多个 bucket。查询进来后，会先找到最相关的 centroid，再只搜索对应 bucket。在上文所举的例子里，通过这个方法，每次查询大约只需要扫描 3% 的数据。

100M 条向量 → IVF clustering

bucket 数量 N 会随着数据量增长

查询 q → 找到最近的 centroid → 只搜索对应 bucket

只扫描约 3% 的数据

S3 I/O 只拉取约 3% 的数据

计算只在约 3% 的数据上执行

当然，IVF 不是新东西。但我们的实现有两个不同点。

第一是规模。

大多数 IVF 实现在十亿级向量规模下会失效，因为构建索引需要一次性把所有数据加载进内存。我们构建了分布式索引构建能力，把 clustering 工作分片到多个节点上，让 IVF 可以扩展到任意规模，甚至数十亿向量。

第二是和 Lakebase 的交互方式。

查询时，只有相关 bucket 会直接从 S3 拉取，QueryNode 内存里只保留约 3% 的数据。一个只加载了 3% 数据集的节点，可以在查询完成后几乎立刻被回收。

结合前文中的 1-bit 量化，实际的数据加载与运算，会大幅压缩：340 GB → 13 GB（量化）→ 每次查询约 400 MB（IVF 剪枝）。

冷启动阶段，只用 5–10 秒加载 cluster centroid 和 1-bit 索引元数据，后续每次查询只需要获取相关 bucket的400MB数据，效率大大提升。

第三关：原始数据读取带来的S3 I/O问题

向量搜索本身返回的是 ID。但业务真正需要的往往是存在S3中的完整结果：原始文本、metadata、scalar fields，甚至原始向量。每次原始结果读取，都需要一次S3 point read。

但如果S3中原始文本的存储格式不适合 point read，I/O 问题就会被严重放大。

很多产品在S3中的文件存储格式默认为Parquet。标准 Parquet 常用 64 MB row group，而一条向量记录可能只有 3 KB。这就导致我们只需要读取3KB的原始数据，采用Parquet格式的时候，却需要下载整个64 MB的 row group，实际 I/O浪费接近 20,000 倍。

因此，我们推出了Storage V2 ：将宽列和窄列分开，分别存储向量和标量字段，并把 row group 缩到 1 MB，从而减少 64 倍 的I/O 放大。

但问题是Parquet本身还有一个天然矛盾。块级压缩依赖于较大的 row group。row group 一旦变小，压缩率就会下降，文件体积也会随之变大。换句话说，在 Parquet 里，小 row group 和高压缩率很难同时成立。

所以 Lakebase 引入了 Vortex。

Vortex 由 Spiral 开发，并托管在 Linux Foundation。它不强制使用固定 row group，layout 可以自由配置。它还支持通过 Delta → RLE → BitPacking 的嵌套编码，在不解压的情况下，对压缩数据直接做 point query。同时，它还能基于 BtrBlocks 算法自动选择编码方式，在压缩率、编码速度和解码速度之间做平衡。

以上是一个对比的结果展示，在3M 行，128 维向量，S3，256 个并发 reader，每次读取 10 行 batch的情况下：

• Parquet 格式每次读取需要下载 9.44 MB 的数据——即整个 row group。
• Lance 通过以 512 byte 的粒度读取数据，将读取量降低到 0.006 MB，但代价是 IOPS 下降：每行大约需要 5 次 S3 GET 请求，而其他格式只需约 2 次。
• Vortex 格式的读取量仅为 0.07 MB，每行大约需要 2 次 GET 请求——比 Parquet 格式减少了 135 倍的数据量，而且没有 IOPS 下降。Full-scan throughput 也比 Parquet 高 2.4 倍，写入性能相当。

至此，第三个障碍解决了。

第四关：多租户情况下，控制平面成本如何降低

前三个问题都在查询链路上。还有一个问题更隐蔽：控制平面。

即使所有 QueryNode 都空闲，在传统向量数据库模式下，每个 Milvus 实例仍然要保持 Coordinator 和 etcd 运行。QueryNode 可以缩到零，但这两个组件不行。它们是有状态组件，必须常驻。

相应的，当租户数量达到百万级时，控制平面的开销，甚至会超过 QueryNode 成本。

Lakebase通过对控制平面的优化，将相关的成本开销从 O(N) 降低成了O(1)。

传统 Milvus 的控制平面成本是 O(N)：

┌──────────────────────────────────────────────────────────────┐

│                     Shared infrastructure                    │

│        Kafka / Pulsar (shared)        Index Pool(shared)    │

└──────────────────────────────────────────────────────────────┘

|                     |                     |

Tenant A              Tenant B              Tenant C

┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐

│  Coordinator     │  │  Coordinator     │  │  Coordinator     │

│  etcd            │  │  etcd            │  │  etcd            │

├──────────────────┤  ├──────────────────┤  ├──────────────────┤

│  QueryNode       │  │  QueryNode       │  │  QueryNode       │

│  (dedicated)     │  │  (dedicated)     │  │  (dedicated)     │

└────────┬─────────┘  └────────┬─────────┘  └────────┬─────────┘

└─────────────────────┼─────────────────────┘

↓

┌──────┐

│  S3  │

└──────┘

Lakebase 的控制平面成本是 O(1)：

┌───────────────────────────────────────────────────────────────┐

│               Shared control plane(per-region)               │

│                                                               │

│  ┌──────────────────┐  ┌──────────┐  ┌───────────────────┐    │

│  │ Shared           │  │ Catalog  │  │   WAL Service     │    │

│  │ Coordinator      │  │  ≠ etcd  │  │  → S3, ≠ Kafka    │    │

│  │                  │  │          │  │                   │    │

│  └──────────────────┘  └──────────┘  └───────────────────┘    │

│                                                               │

│  ┌───────────────────────────────────────────────────────┐    │

│  │              Index Service(GPU Build Pool)           │    │

│  └───────────────────────────────────────────────────────┘    │

└─────────────────────────────┬─────────────────────────────────┘

┌────────────────────┼─────────────────────┐

Tenant A NS           Tenant B NS           Tenant C NS

┌────────────┐         ┌────────────┐         ┌───────────┐

│ QueryNode  │         │   (idle)   │         │ QueryNode │

│ QueryNode  │         │  scale = 0 │         └────┬──────┘

└──────┬─────┘         └────────────┘              │

└─────────────────────┬─────────────────────┘

↓

┌──────┐

│  S3  │

└──────┘

Lakebase 中，我们淘汰了原有的按租户分配资源的模式，用Shared Coordinator 替代了 per-tenant coordinator。并用Catalog 取代了每个实例单独部署的 etcd，然后移除了 2 GB 的存储上限。

WAL Service 可直接写入 S3，无需本地磁盘。实测吞吐量达到 750 MB/s，是 Kafka 的 5.8 倍，用于取代 Kafka/Pulsar。

Index Service 则变成了一个跨租户共享的 GPU 构建池，取代了原先每个实例单独分配 GPU 的模式。

“Scale to zero” 不再只是“QueryNode 可以释放”。它开始意味着：整个实例在空闲时几乎没有成本。

┌──────────────────────────────────────────────────────────────┐

│              Multi-tenant × Lakebase On-demand Search        │

│                                                              │

│  S3 storage layer                  compute (on demand)       │

│  ┌──────────────┐                                            │

│  │Tenant A data │ ◄──── query ──── QueryNode A (active)      │

│  ├──────────────┤                                            │

│  │Tenant B data │                  (idle, no QueryNode)      │

│  ├──────────────┤                                            │

│  │Tenant C data │                  (idle, no QueryNode)      │

│  ├──────────────┤                                            │

│  │Tenant N data │ ◄──── query ──── QueryNode N (active)      │

│  └──────────────┘                                            │

│                                                              │

│  1M tenants, 1% active → 99% of data has zero compute cost   │

└──────────────────────────────────────────────────────────────┘

传统模式中，多租户意味着通过不同 collection 或 partition 在一个集群中共享tenant。但这种集群存在硬性限制：etcd 的 2 GB 元数据限制、coordinator 的吞吐量以及固定的QueryNode 容量。

而在Vector Lakebase，Catalog 用可扩展的 metadata store 替代 etcd，Shared Coordinator 可以在没有 per-tenant 开销的情况下支持更多 tenant，S3 提供存储弹性，最终实现单机群服务多租户，而且只有正在接收查询的租户会消耗计算资源。其他租户只为存储付费。

选择Vector Lakebase意味着什么？

回到一开始的问题，1 亿条向量，768 维 float32，每天 10 次查询，每次 1 分钟，每月活跃约 5 小时的情况下，用户到底需要多大成本？

答案取决于计算资源是否必须持续在线。

在自托管 Milvus 中，主要成本来自常驻计算资源。即使查询频率很低，集群也需要持续在线，以保证数据处于可查询状态。按 3 台 r6g.4xlarge on-demand 实例估算，仅 EC2 成本约为 2,073 美元/月，还不包括Kafka等依赖组件。

Zilliz Cloud Tiered Storage Model 降低了运维复杂度，并通过分层存储降低冷数据的存储成本。但从计算模型看，它仍然是持续在线的服务模式。其冷启动成本通常是一次性的：数据加载完成后，后续查询可以保持较低延迟。对高频或稳定访问的场景来说，这种模式非常合适；但对每月只活跃数小时的工作负载来说，计算资源的基础成本其实并不必要。

Vector Lakebase On-demand Search，可以让数据可以长期保存在对象存储中，计算资源只在查询会话开始时启动，并在任务结束后释放。

相应的，在这个例子中，Vector Lakebase 模式下，用户只需为每月约 5 小时的计算以及实际的S3存储成本付费。每年只需要 240 美元，不使用的99% 的时间里没有计算成本。

而随着语义数据可以被自由加载释放，团队也不再需要用同一种计算形态处理所有工作负载。热数据可以使用持续在线的 serving compute；低频语义查询可以使用 on-demand search；数据发现、聚类、清洗和批处理任务可以使用 batch compute。

当然，Vector Lakebase也不是万能的。为了保证会话之间计算成本为零，节点会在查询结束后缩容到零，每次新的请求发起时会有约 5–10 秒冷启动。

所以，这三种模式没有完全的优劣之分，取决于你的数据是否需要长期占据计算资源。

开始使用 Zilliz Vector Lakebase

Zilliz Vector Lakebase Public Preview 现已开放。如果你正在构建 AI 搜索、智能体记忆、企业知识库、多模态检索、数据湖语义分析或大规模批量分析工作流，现在就可以开始体验新一代面向 AI 工作负载的语义数据平台。

尝鲜链接：https://zilliz.com.cn

附：Zilliz Vector Lakebase 能力一览

当前阶段的Zilliz Vector Lakebase ，主要做了五方面的能力建设：

服务能力升级：推出分层服务方案，为极致性能、容量优化和低成本分层存储等不同场景提供对应选择。

按需搜索能力升级：推出按需搜索（On-Demand Search），让大规模低频检索、数据探索和离线分析不再需要长期维持闲置计算资源。

数据湖搜索能力升级：支持外部数据湖搜索（External Data Lake Search），可直接在已有数据湖上增加高性能索引和大规模搜索能力。

检索能力升级：在同一系统内支持向量搜索、全文搜索、JSON 查询、地理空间搜索、多向量搜索、多路径检索和重排序。

湖原生存储能力升级：同构统一的lake-Native Storage，基于 Vortex 开放格式，为在线服务和离线分析提供统一、高效、低成本的数据底座。与 Lance 和 Parquet 相比，它能提供更快、更便宜的随机读取，以及按列格式的灵活性和更广泛的数据建模能力。

作者介绍

栾小凡

Zilliz CTO

LF Al & Data 基金会技术咨询委员会成员

文章来自于微信公众号 "Zilliz"，作者 "Zilliz"