向量数据库：抛弃数据库范式的代价？

作者 | 栾小凡 - Zilliz 合伙人 & 研发 VP

向量数据库大概是沉寂已久的数据库圈 2023 年最火的话题。最近有很多朋友询问我对向量数据库的看法，现在确实是讨论这个问题的好时机，一方面大模型和向量数据库仍然是热点话题，另一方面我们已经有了足够的样本和时间去仔细思考什么是真正面向 AI 应用的数据库。本文标题致敬 David J. DeWitt 和 Michael Stonebraker，他们讨论 Map reduce 的同名文章是我学习分布式系统的入门文章，也引领我进入数据库行业。

尽管我本人也深度参与了开源向量数据库 Milvus 的开发工作，但我个人对过去一年里 VectorDB 的鼓吹者大肆宣传向量数据库与 AI 的关系感到厌倦。的确，向量数据库确实在部分与大模型相关的应用场景中起到了重要作用，但是，向量数据库目前的产品定位，形态，功能都与我们在 2019 年发明向量数据库这个词的初心相去甚远，更不要说能够很好的适配和支撑 AIGC 应用接下来的发展。现在是时候承认一个我们所有人都知道已经的事实了，目前所有的向量数据库（是的，也包括 Milvus 自身）根本不能被称之为一款数据库产品，某种意义是大规模数据处理领域的一种倒退，原因是：

1. 向量数据库放弃了数据库中重要的范式和理念

2. 绝大多数向量数据库的实现方式并不高效

3. 向量数据库不能处理复杂的向量查询

4. 缺少了大部分数据库应有的功能

现存的 VectorDB 可能不是处理 AIGC Native 应用最适合的产品，是适合的时机作出改变了。我们先讨论什么是向量数据库以及其爆红的原因，然后我们在具体讨论上述四个原因。

什么是向量数据库？

向量数据库，正如其名，是专为管理向量数据而设计的数据库。这类数据库的诞生主要是为了应对非结构化数据的处理挑战。传统的表格形式不适合存储和表达非结构化数据，如图片、音频和视频。这些数据类型需要通过机器学习算法来提取内部的“特征”，这些特征通常以向量的形式表示。

随着大模型和人工智能技术的迅速进步，模型在理解数据语义方面的能力显著增强。这一发展推动了向量数据应用场景的广泛扩展，使得如何高效地存储和检索向量数据成为了一个关键议题。向量数据库应运而生，旨在解决这一问题。

向量数据库的核心能力在于其对高维数据相似性的理解和处理能力。通过采用近邻图、聚类、局部敏感哈希（LSH）等多种机器学习算法，向量数据库能够实现多种复杂的数据操作。这些操作包括最近邻 / 最远邻检索、聚类计算、以及相似性过滤等功能。

相比于传统的向量搜索服务和向量检索库，向量数据库从一开始就非常注重数据持久性（Persistence), 一致性（Consistency), 可用性（Availability), 可扩展性（Scalability), 安全性（Security）等数据库关键能力。之所以命名为向量数据库，是因为我们希望向量数据的处理能够像结构化数据一样高效和易用。

接下来，让我们看看当前的向量数据库到底存在着哪些具体的问题。

向量数据库放弃了数据库中重要的范式和理念

很多 VectorDB 并不能被称为一个真正的数据库，他们

1. 不支持预定义 Schema

2. 查询接口很随意，缺乏 High Level 查询语言

3. 缺乏数据库基本机制，正确性和稳定性难以保证

4. 缺乏频繁更新，删除的能力和实时查询的能力

不支持预定义 Schema: 很多向量数据库基于应用性考虑，不支持预定义的 Schema。预定义的 Schema 有助于保持数据的完整性和一致性，避免应用程序向数据集中添加“垃圾”。相比之下，传统数据库如 MongoDB 即使支持动态 Schema，也是基于精细的数据类型设计和索引构建，且仍可能牺牲一些效率和性能。

查询接口的随意性和缺乏高级查询语言: 向量数据库的查询接口通常缺乏规范性，没有高级的查询语言。这导致了接口的泛化能力较弱，例如 Pinecone 的查询接口甚至不包括指定要检索的字段，更不用说分页、聚合等数据库常见的功能。接口的泛化能力弱意味着其变化频繁，增加了学习成本。

SQL

index.query(

vector=[0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3],

top_k=3,

include_values=True

)

数据库行业近年来经历了从 NoSQL 到 NewSQL 的重大转变。这一转变的核心在于让用户能够明确表达他们的需求，而不是如何实现这些需求。许多向量数据库没有从历史中吸取教训，这种简单直接的 API 尽管在早期实现会比较高效，但很可能在未来演进过程中逐渐显现为一个短板。

缺乏数据库基本机制和测试，正确性难以保证：由于向量数据库不需要 100% 的查询准确率，很多产品没有重点关注数据准确性。在使用 VectorDBbench 进行测试时发现，在特殊数据集，如 OOD（Out of Distribution）、Filtering 场景下，许多向量数据库的搜索质量难以得到保证。尤其是很多向量检索直接使用开源索引的 Faiss 和 HNSW 索引，往往无法实现即插即用并获得良好的检索效果。在并发插入和更新场景下，由于缺乏多版本并发控制（MVCC）、事务等基本数据库机制的支持，许多向量数据库同样面临着并发处理问题和数据可见性问题。鉴于迄今为止的实验评估，我个人对许多向量数据库在实际生产环境中的应用效果持怀疑态度，也建议所有开发者在选择向量数据库之前进行更加全面的评估。

缺乏频繁更新、删除和实时查询的能力：对于在线服务型数据库来说，处理高频率的增删改查操作是至关重要的，这也是区分传统向量检索和向量数据库的一个重要标志。然而，大多数向量数据库虽然支持数据的增量插入和删除，但面临着插入性能瓶颈和查询性能衰退的严重问题，这通常与依赖的开源向量数据库索引如 Faiss 和 HNSW 的特性有关。以 HNSW 为例，数据的索引是在插入过程中实时完成的，这一过程既缓慢又会影响查询效率。因此，许多向量数据库的插入速度不超过 10MB/s，无法满足大量数据入库时的性能需求。另一方面，频繁的数据删除会导致图索引的连通性变差，进而影响查询性能和结果。

绝大多数向量数据库的实现方式并不高效

在深入分析向量数据库的实现方式时，我们可以清晰地看到：绝大多数向量数据库并没有达到理想的高效运行状态。传统分布式数据库主要面临两大挑战：有效地进行数据分片（Sharding）和创建高效索引。在这些传统数据库中，Sharding 通常基于主键、索引键或分区键，采用 Range 分区或 Hash 分区，使得系统能够根据查询条件高效地选取数据片段。而索引结构，如 hash、B 树和 LSM 树，能够将搜索范围有效缩小至少数几个数据库页面，大幅降低查询的 I/O 和过滤成本。

然而，向量数据库在处理这两个方面时表现不佳。首先，由于向量数据查询的特殊性质，传统的 Sharding 和索引方法并不完全奏效。多数向量数据库在设计初期未充分考虑 Sharding 问题，在从单机向分布式结构转变时，常常只能依赖随机分片和查询归并策略。这导致了随着数据量的增长，查询成本也以 O(N) 的规模增加。一个更有效的 Sharding 策略应该基于数据分布特性，而非单纯的数据写入时间。

其次，由于向量的高维特性，向量数据没法使用传统的数据结构进行索引。许多向量数据库依赖的是纯内存图索引和聚类索引，这导致了高昂的存储成本。为了应对这一挑战，采用冷热数据分离、存算分离与缓存策略成为了降低成本的关键。另一方面，由于缺少测试集合，向量索引的实际性能很难被全面的评估，比如我们发现图索引的连通性在某些数据特性下会降低，尤其在高过滤、频繁删除的场景中，这使得部分数据变得难以检索，而绝大多数向量数据库并未针对这些特殊场景作出处理。

此外，向量数据库开发者们常常忽略向量检索的概率特性。在绝大多数应用场景中，追求 99% 的准确率下的高性能和低成本比追求 100% 的绝对准确率更为重要。利用机器学习动态调整索引参数和查询参数，可以在大数据集中实现超过 10 倍的性能提升。此外，机器学习算法还可用于向量降维、量化和动态剪枝，进一步提高数据库的效率。

向量数据库不能处理复杂的向量查询

在很多用户的眼里，向量数据库提供的价值就是对高维向量进行 ANN 检索。事实上，这种刻板印象完全来源于向量数据库的过于简化的糟糕实现 - 缺乏抽象，没有内存管理，没有可插拔的执行引擎。在真实应用场景里，我们见到了用户对向量更加复杂的查询需求，例如：

混合查询提升查询质量：用户需要的不仅是 Dense Embedding，还包括 Sparse Embedding 以及两种向量混合查询。Sparse embedding（如 BM25 和 Splade）可以更有效地检索细节信息，而 Dense embedding 则擅长捕捉上下文和语义信息。结合这两种 embedding，并基于适当的模型进行 reranking（重新排序），能够大幅提升查询召回的准确性。

向量与标量的综合结合功能：向量数据库不仅可以执行标量过滤，还能进行 GroupBy、Aggregation 等关系型数据库操作。常见的操作包括寻找年龄在 20 至 30 岁之间的 top10 相关用户，或者找出最相似的 100 个文档分块，并按其文档 ID 进行分组，最终返回最相似的文档。

向量丰富语义的应用：向量数据含有丰富的语义信息，支持包括最近邻过滤（例如找像猫但排除加菲猫的照片）、异常数据识别、基于距离范围的 RangeSearch、基于最近邻的 GroupBy、KNN Join 等操作。这些功能在特定场景下具有实际应用价值。

随着 AI 应用场景的不断发展，我们面临的查询任务变得越来越复杂。目前，无论是那些基于传统数据库并加入插件的向量数据库，还是那些以轻量级和易用性为主要卖点的向量数据库，在面对复杂的向量查询时，往往显得不够强大（以开源的 HNSW 作为执行引擎，也很难满足更加复杂的查询能力）。为了应对这一挑战，一个理想的向量数据库应该具备与传统数据库相似的核心组件，例如 AI 原生的解析器、优化器，以及更加符合向量数据特点的执行引擎。这些组件需要在更高的抽象层次上结合在一起，从而能够更好地适应业务的快速演进和发展需求。

缺少了大量数据库应有的功能

以下所有功能通常由现代数据库管理系统（DBMS）提供，而大多数向量数据库都缺少这些功能：

1. 离线加载 - 将数据从其原始格式或源数据库转换成 Parquet，CSV 离线格式并批量加载到数据库中，以加快大量数据的插入速度。

2. 数据库的一致性 - 支持强一致性查询和复杂的 Write After Read 操作，并确保数据的准确性和完整性。

3. 安全 - 包括角色基础访问控制（RBAC）、认证、TLS，数据加密等能力。

4. 多租户支持 - 在一个集群或一个表中支持多个租户的数据，许多用户现在的使用方式是建立更多的表和建群，这显然是难以的维护的做法

5. 数据导出 - 支持全量数据导出，许多向量数据库不支持该功能的原因依然是其糟糕的实现，但这依然会导致供应商锁定。

6. 容灾能力 - 提供跨机房的灾难恢复能力，确保数据的高可用性和持续性。

总之，我认为绝大多数“向量数据库”被称之为数据库只是一个误会，或者只是一种营销术语。在向量数据库具备传统数据应该具备的能力和工具之前，用户在生产环境中使用向量数据库的旅程依然会非常挣扎。

向量数据库，真的“凉”了？

在深入探讨向量数据库的局限性之后，作为一个拥有三年向量数据库和十年传统数据库行业经验的从业者，我反而对专有向量数据库的未来感到更加乐观。我们可以问自己两个问题：

1. 目前的向量数据库是否能满足 AI Native 开发者的期望和需求？

2. 如果现状尚未达到这一目标，那么我们应该做些什么？

经过与数百名专注于 AI 原生应用的开发者的对话，我发现他们普遍面临一个类似的挑战：在 AI 原生应用开发中，迫切需要的是一种能够深刻理解语义的搜索系统。这种系统的核心功能是能从大量数据中提取出高质量的上下文信息，从而支持大型模型进行更精确的推理，并有效地消除幻觉。随着业务需求的发展，搜索技术也在持续地创新和多样化。现代的搜索方法已经超越了传统的向量检索，包括图索引、关系型查询和关键词搜索等多种技术。未来的搜索架构可能会更加复杂：

1. 作为 AIGC 系统的存储核心，向量数据库的作用定义都不断扩展。它们不仅应该存储向量信息，还应该包括标签、倒排索引等标量数据，从而提供更加丰富和复杂的查询语义。这种多元化的数据存储和检索机制对于提升搜索的质量和功能至关重要。即将发布的 Milvus 2.4 和版本将引入多向量混合查询和稀疏索引功能，为 AIGC 应用提供更加强大的存储支持。

2. AIGC 技术的迅猛发展正在加速相关应用的普及。一个显著的例子是 ChatGPT，它在仅仅 5 天内就吸引了一百万用户，并在两个月内用户数激增至一亿。这种爆炸式的增长不仅体现在用户数量的迅速上升，而且还在于用户粘性的持续提升。因此，开发者在项目初期就需要特别关注应用的弹性和扩展性。在处理 AIGC 应用，如 RAG 和 Agent 等，面临的一个典型挑战是如何高效管理多租户环境。Milvus 在这方面进行了创新性的尝试，提出了基于分区键的多租户解决方案。这个方案允许单个集群支持千万级别的租户数据分离，这对于处理大规模用户数据是至关重要的。Zilliz Cloud 即将推出的 Serverless tier 将支持千万级别的租户，单个租户的数据可以弹性扩展到亿级别，同时支持多租户之间的冷热数据分离。使用 Serverless tier，预计单个知识库的成本将比现有解决方案降低 10 倍，这将进一步推动了 RAG 应用的普及。

3. 在 AI 原生时代的背景下，我们目睹了团队规模的显著变化。当前，小型且高效的团队通过优秀的产品能够迅速占领市场。这种趋势在多个案例中得到了验证。例如，Pika 团队虽然只有 4 人，但他们的公司估值已超过 10 亿；而 Midjourney 团队在只有 11 名成员的情况下，年营收已经超过一个亿。这些例子展示了小规模团队在 AI 原生时代所拥有的巨大潜力。这样的“小而美”的公司倾向于专注于业务逻辑本身，而不是将大量时间和资源投入到基础设施管理中。因此，他们倾向于选择云托管向量数据库作为首选。在选择过程中，容灾能力、弹性和数据安全性成为重要的考量因素。目前，所有向量数据库供应商在这些方面都还有很远的路要走。

4. 随着数据量的持续增长，数据存储和检索性能变得尤为关键。在业务早期，使用如 PGVector 等插件可迅速满足需求。然而，随着业务扩展和存储成本上升，转向专业向量数据库并进行针对性优化成为必要。Milvus 不仅是首个支持磁盘索引的向量数据库，也是首个推出 GPU 索引的供应商。此外，Zilliz 自研的 Cardinal 索引相比开源 HNSW 实现了三倍性能提升和 50% 存储节约，其独创的磁盘索引技术进一步提升了 5 倍存储效率。与 NVIDIA 合作开发的 Cagra GPU 索引在性能上比 CPU 性能提高了 10 倍，显示了异构算力在向量处理中的巨大潜力。

正如我们所见，尽管向量数据库在当前的形态中存在诸多不足，但它们在 AI 驱动的未来中仍扮演着至关重要的角色。事实上，最让我感到兴奋是开发范式和应用场景的改变，这让我想起了 15 年前 MapReduce 的崛起和 10 年前移动互联网兴起 MongoDB 的诞生，这对于数据库行业是一个新的历史性机遇。面对如此多的不足，我们不应仅仅停留在批评的层面，而应该借鉴过往数十年的关系型数据库经验，结合今天的 AI 应用场景，找到属于向量数据库的独特价值。

如果要用一句话来概括向量数据库，那就是“以 AI 的方式理解数据，以数据库的方式访问数据”。伟大的数据库产品往往诞生于应用开发范式的变革时期。今天，向量数据库也似乎正站在属于它的历史性机遇前。