向量搜索在搜索、推荐、NLP 等众多应用领域被广泛的使用，典型的互联网业务，包括电商、 出行、点评、地图等都大量使用相关技术。随着 ChatGPT 带来的 AI 技术应用新热潮，向量 数据库又一次地获得了更多的关注。支持向量存储和搜索技术的系统很多，包括传统的数据 库如 PostgreSQL，经典的搜索系统 Elastic Search，以及创业公司产品如 Milvus、Weaviate 等等。

向量技术要在系统中实现，业界常见的做法有以下几种：

1. 基于具体的业务，如图片搜索、视频搜索、AI 训练实现多种算法，形成函数库。例如： Facebook 的 FAISS、微软的 SPTAG、阿里巴巴的 Proxima 等。

2. 基于现有的系统，例如 Elastic Search、PostgreSQL 等搜索系统或通用数据库系统， 实现对向量数据类型的存储、索引和查询。多数系统为了减少侵入性修改，采用插件的 形式对现有搜索系统或数据库系统做增强。

3. 直接做成一套新的系统，有的叫做搜索（例如京东 Vearch 等），有的叫做数据库（ 例如 Milvus、Weaviate）。需要支持多种常见的标量数据类型，以及向量数据类型，并 完整实现分布式系统所需要的可靠性、可用性、备份恢复，以及各种语言的 SDK 等。

很明显，不同产品的生态也很不相同，基于 Elastic Search 的用的就是搜索的 DSL；基于 数据库的用的就是 SQL；新做的系统则可能选择特有的 API。从数据库系统的角度看，此类 系统更像是分布式 NoSQL，可以在 ACID 事务性和分布式一致性等方面做一些取舍；存储 引擎可以借助现有的数据库引擎或 KV 类引擎；查询尤其是混合了搜索和类 SQL 查询可以 参考 SQL 数据库的查询优化和执行技术，做一些融合设计。

向量数据的来源通常是 AI 模型中对文本、图像、声音、视频等的 embedding 表示，所以 要查询两个向量是否相同或相似，就得靠它们之间的距离：欧式距离、余弦距离等。但是 要在一大堆向量中对每个记录都计算一次距离显然不靠谱，就像关系数据库中查询符合 某个条件的记录不能动不动全表扫描一样。所以问题的关键在于构建索引，以及牺牲精确性， 改用近似查询算法：Approximate Nearest Neighbor (ANN) 等。