没两把刷子，别碰向量数据库

如果一定要在 2023 年的数据库赛道里选出一个网红，那么一定非向量数据库莫属。

2022 年，经历了 OLAP、IoT 的捶打后，我选择加入了向量数据库的赛道。遥想当时，向量数据库还是一个非常小众的赛道，朴素的直觉告诉我，Database for AI 的场景一定有前景。不过，现实却是直到 2022 年下半年，我们还是要和广大开发者布道——什么是向量数据库、它能解决什么问题。

2023 年，大模型的爆火让更多的人知道了向量数据库这一赛道，而后随着 RAG（检索增强生成）对向量数据库的深度依赖，使得向量数据库成为各数据库厂商争相追逐的热门领域。最火热的那段时间每天都有不同领域的产品号称自己是向量数据库，这让大家一度以为向量数据库是一个没什么门槛的赛道……

事实上，向量数据库不仅有门槛，且其核心向量索引技术仍处于不断演进的状态。今天，我们（太可研究所：techinstitute）就来好好唠唠能体现向量数据库竞争力的狠角色—— ANN 索引。

Vol.1

如何定义向量数据库其实没有标准答案，目前业界几款流行的向量数据库例如 Pinecone、Milvus、Qdrant 无论从接口能力还是具体的实现都不尽相同，如果硬要取个交集，基本只有两点：一是支持增删改查向量，二是通过 ANN索引技术实现了快速向量检索。增删改查是一个数据库的标配，所以传统数据库产品加入向量类型的支持并不难，只要扩展性足够好甚至不需要修改太多代码，所以 ANN 索引的差异就成了核心竞争力。

什么是 ANN 索引？这就需要从向量数据的特点讲起。向量本质上是一个固定长度的数组，固定长度数组的特点是可以映射成高维空间的一个点，而向量检索的过程就是寻找到最近的 k 个点，最朴素的做法是把空间里的所有点都计算一下距离，并在比较的过程中维护好最近的 k 个点，这就是 kNN 的过程。

这个过程无疑很慢，会随着向量数据量的增加变得越来越慢，且向量的 top k 查询结果准确性没有那么重要。例如，在文本搜索的场景中“哪个文章和我输入的关键词最匹配”本身就是一件模糊的事情，所以才有了 ANN 索引的出现。

ANN 全称是 approximate nearest neighbor，就是近似的最近邻，通过 ANN 索引也能完成 topk 查询，拿到 k 个结果，但是结果并不是精确的，而是一个近似的结果。同时伴随着有一个 recall 的概念来评价近似的准确率，例如 kNN 算法的 recall 就是 100%，超过 95% 的 ANN 索引精度已经算是很高了。不难猜到 recall 和性能需要做一定的取舍，同一个索引 recall 越高性能就会越差。

Vol.2

上一段落简单介绍了向量数据库和 ANN 索引，进行了不少铺垫，ANN 索引的好坏就决定了一款向量数据库的天花板。目前业界主流的 ANN 索引有几个分别是 IVF、HNSW、DiskANN。

关于 IVF 和 HNSW 的介绍已经有很多了，可以参考 Pinecone 的介绍文章 ，分别是基于聚类和图的索引，IVF 更省内存但 HNSW 性能更好，需要结合自身的场景选择。

DiskANN 的相关介绍就很少了，适用于大规模向量 ANN 搜索的场景，最明显的特点是索引可以存储在磁盘，而 IVF、HNSW 需要加载到内存才能使用。相比之下，DiskANN 的使用成本远低于 IVF 和 HNSW 索引，单机存储量是纯内存版本的 5～10 倍，对有 Billion 级别向量并且成本敏感的用户这无疑很有吸引力。

以上是常见的几个 ANN 索引，在 GitHub

[打榜的索引](https://github.com/erikbern/ann-benchmarks ANN benchemark)还有很多，但大多数都没经历过生产验证，而有些则是某些数据库独有的索引和该数据库耦合在一起无法分离，真正广泛应用的不多。

在技术选型时，性能往往是入场券，但一般不是决定性的因素。同理，在如此多的 ANN 索引中选择合适的才是最好的，要综合考虑性能、成本、易用性、检索需求匹配多等。分析到这里就要提一下，目前绝大部分 ANN 索引的局限性，不支持更新、条件过滤不友好。

不支持更新或更新很慢是非常致命的局限性，以至于在基于索引设计向量数据库时不得不做一些妥协。以我参与过的向量数据库来说，由于索引无法更新，就需要在写入数据后再异步的构建索引，此外在 LSM-tree 的数据 compaction 合并后的数据无法立刻使用（因为没有索引），必须等索引构建好之后才能执行后续流程，如果 compaction 很频繁会非常消耗资源。这就导致整个写链路逻辑和数据管理异常复杂，非常容易出 bug。

条件过滤不友好这点倒不是特别致命，只是性能表现很反直觉。对于一般的数据库来说，查询所有的数据和查询一半的数据，如果索引建得正确的话，查询一半的性能肯定是快于前者的，因为数据扫描量降低了，相应的查询延迟也会跟着降低。但是对于一般的 ANN 索引来讲，不支持条件过滤，需要数据库层面做后过滤，比如，如果要查询 “top 10”、“地区在上海”的数据，执行过程中会先查出来 10 条数据，比较一下地区字段是否等于上海，如果不是就再查后 10 条，如此循环直到满足查询条件。如果叠加上索引 top k 越大性能越差的特点，就会使得查询性能骤降。所以对于很多 ANN 索引过滤条件越多，可能查询得越慢。

Vol.3

那么，上述提到的两个问题有没有解决方案呢？

对于条件过滤不友好这个问题，很多数据库都对 HNSW 做了改造，在其构建图的边上增加属性，因此可以在图搜索时利用到这些属性达到快速过滤的效果。而且一些新的索引在设计之初就考虑了这点，能大大缓解此类问题。只是这些新索引还有待时间检验。

Microsoft 开源了向量索引 SPTAG 一直试图解决这些问题。首先 SPTAG已经用在了 bing 搜索里，所以可用性没什么问题，其次 SPTAG 也是基于磁盘的索引，测试下来性能优于 DiskANN，所以在超大规模向量的场景下成本更低。此外，微软还尝试引入 SPFresh 机制，让索引支持实时更新，PR 目前还没合并，非常期待它合并进主分支。关于 SPFresh 的详细介绍可以参考前同事的一篇文章，写得非常专业。

除了 SPFresh 这个非常有创新的功能之外，SPTAG 其他的功能也很完善:

• 索引数据的组织结构分为两种，一是基于 KD-tree（K-dimensional tree）特点是索引构建性能更高，另一种是基于 BKT（Balanced k-means Tree）特点是精度更高。

• 使用向量数据 Relaxed Monotonicity 的特性，解决带条件过滤场景下的 ANN 搜索问题。Relaxed Monotonicity的意思是向量数据在是有单调性趋势的，但不具备像数字、字符串类型严格单调有序的特性。基于单调趋势的特点，可以做到类似于传统数据库中火山模型的效果。不仅仅是解决复杂过滤条件的问题，还可以实现迭代器模式获取数据的效果。

• 使用 GPU 构建索引，这是很多向量数据库、索引都在尝试的方向，毕竟向量计算天然就是 GPU 的主战场，NVIDIA 也在积极探索基于 GPU 的索引。

• 基于磁盘、节约内存。

Vol.4

向量索引的演进还没有到决胜负的时刻，还在不停地演进当中。在今年匆匆上马向量支持的数据库们，很多都直接把 HNSW 索引集成进来，以为这就是最终答案，这就有些过于武断了。未来，随着研究的深入一定还会有更多的 ANN 索引出现，对现在的向量数据库架构是个很大的挑战，非常考验代码架构的抽象能力和扩展性，毕竟如果代码和某个索引耦合得太紧，过了半年发现该索引落伍了，也就意味着这款数据库过时了。

引用

• https://www.pinecone.io/learn/series/faiss/hnsw/

• https://www.microsoft.com/en-us/research/project/project-akupara-approximate-nearest-neighbor-search-for-large-scale-semantic-search/

• https://github.com/microsoft/SPTAG

• https://arxiv.org/abs/2111.08566

• https://zhuanlan.zhihu.com/p/667662224

• https://jingdongwang2017.github.io/Pubs/NeurIPS2021-SPANN.pdf