矢量数据库是为实现高维矢量数据的高效存储、检索和相似性搜索而设计的。使用一种称为嵌入的过程，将向量数据表示为一个连续的、有意义的高维向量。
本文将研究存储/检索向量数据和执行相似性搜索的实用方法，在我们深入研究之前，首先先介绍矢量数据库的两个关键功能：
1、执行搜索的能力
当给定查询向量时，向量数据库可以根据指定的相似度度量(如余弦相似度或欧几里得距离)检索最相似的向量。这允许应用程序根据它们与给定查询的相似性来查找相关项或数据点。
2、高性能
矢量数据库通常使用索引技术，比如近似最近邻(ANN)算法来加速搜索过程。这些索引方法旨在降低在高维向量空间中搜索的计算复杂度，而传统的方法如空间分解由于高维而变得不切实际。
简介
矢量数据库领域现在正在急速的扩展，如何权衡选择呢，这里我整理了5个主要的方向：
- 像Pinecone这样的纯矢量数据库，比如Pinecone也是建立在下面的Faiss之上的
- 全文搜索数据库，如ElasticSearch，以前是作为搜索引擎现在增加了矢量存储和检索的功能
- 矢量库，如Faiss, Annoy和Hnswlib，还不能作为数据库，只是矢量的处理
- 支持矢量的NoSQL数据库，如MongoDB、Cosmos DB和Cassandra，都是老牌的数据存储，但是加入了矢量的功能
- 支持矢量的SQL数据库，如SingleStoreDB或PostgreSQL，与上面不同的是这些数据库支持SQL语句
除了上面提到的五种主要方法外，还有如Vertex AI和Databricks，它们的功能超越了数据库，我们不进行讨论。
1、纯矢量数据库
纯矢量数据库是专门为存储和检索矢量而设计的。包括Chroma, LanceDB, Marqo, Milvus/ Zilliz, Pinecone, Qdrant, Vald, Vespa, Weaviate等。数据是基于对象或数据点的向量表示来组织和索引。这些向量可以是各种类型数据的数字表示，包括图像、文本文档、音频文件或任何其他形式的结构化或非结构化数据。
优点
- 利用索引技术进行高效的相似度搜索
- 大型数据集和高查询工作负载的可伸缩性
- 支持高维数据
- 支持基于HTTP和json的api
- 原生支持向量运算，包括加法，减法，点积，余弦相似度
缺点
纯矢量数据库:纯矢量数据库可以存储矢量和一些元数据，但是其他就不行了。对于大多数用例，可能还需要包括诸如实体、属性和层次结构(图)、位置(地理空间)等描述的数据，这就要其他存储的整合。
有限或没有SQL支持:纯矢量数据库通常使用自己的查询语言，这使得很难对矢量和相关信息运行传统的分析，也很难将矢量和其他数据类型结合起来。
没有完整的CRUD:纯矢量数据库并不是真正为创建、更新和删除操作而设计的。所以必须首先对数据进行矢量化和索引，这些数据库的重点是获取向量数据，并基于向量相似度查询最近邻，而索引是很耗时的。索引矢量数据计算量大、成本高、耗时长。这使得基本上无法进行实时的操作。例如，Pinecone的IMI索引(反向多索引，人工神经网络的一种变体)会产生存储开销，并且是计算密集型。它主要是为静态或半静态数据集设计的，如果经常添加、修改或删除向量，基本上不太可能。而Milvus使用的索引被称为产品量化和分层可导航小世界(HNSW)，这是一种近似的技术，在搜索准确性和效率之间进行权衡。它的索引需要配置各种参数，使用不正确的参数选择可能会影响搜索结果的质量或导致效率低下。
功能性不强:许多矢量数据库在基本特性上严重落后，包括ACID事务、灾难恢复、RBAC、元数据过滤、数据库可管理性、可观察性等。这可能会导致严重的业务问题，要解决这些问题，则需要我们自己来处理了这会导致开发量大增。
2、全文检索数据库
这类数据库包括Elastic/Lucene、OpenSearch和Solr。
优点
- 高可伸缩性和性能，特别是对于非结构化文本文档
- 丰富的文本检索功能，如内置的外语支持，可定制的标记器，词干器，停止列表和N-grams
- 大部分基于开源库(Apache Lucene)
- 成熟的且有大型集成生态系统，包括矢量库
缺点
- 没有优化向量搜索或相似匹配
- 主要设计用于全文搜索，而不是语义搜索，因此基于它构建的应用程序将不具有检索增强生成(RAG)和其他的完整上下文。为了实现语义搜索功能，这些数据库需要使用其他工具以及大量自定义评分和相关模型进行增强。
- 其他数据格式(图像、音频、视频)的有限应用
- 基本上不支持GPU
一般选择这些库的原因都是因为在以前项目上增加新的功能，并且数据量小，对主业务也不会产生多大影响时使用。如果需要重新构架大型项目，不建议使用。
3、开源矢量库
对于许多开发者来说，Faiss、Annoy和Hnswlib等开源矢量库是一个很好的起点。Faiss是一个用于密集向量相似性搜索和聚类的库。Annoy (Approximate Nearest Neighbors Oh Yeah)是一个用于人工神经网络搜索的轻量级库。Hnswlib是一个实现HNSW ANN搜索算法的库。
优点
- 快速近邻搜索
- 为高维构建
- 支持面向人工神经网络的索引结构，包括倒排文件，产品量化和随机投影
- 支持推荐系统、图像搜索和自然语言处理的用例
- SIMD(单指令，多数据)和GPU支持，加快向量相似度搜索操作
缺点
- 维护和集成麻烦
- 与精确方法相比，可能会牺牲搜索准确性
- 需要自己部署和维护：需要你构建和维护复杂的基础设施，为应用程序需求提供足够的CPU、GPU和内存资源。
- 对元数据过滤、SQL、CRUD操作、事务、高可用性、灾难恢复以及备份和还原的支持有限或不支持
他们之所以称为库（或者包）而不是数据库是因为它们只提供了很少的但是却非常专业功能，如果你想入门学习或者做一个简单的demo，它们都是很好开始，但不建议直接应用到生产中。
4、支持矢量的NoSQL数据库
这些数据库包括：NoSQL数据库，如MongoDB, Cassandra/ DataStax Astra, CosmosDB和Rockset。还有像像Redis这样的键值数据库和其他特殊用途的数据库，如Neo4j(图数据库)
几乎所有这些NoSQL数据库都是最近才添加矢量搜索扩展而具备矢量能力的，所以如果要是用的话一定要做好测试。
优点
对于特定的数据模型，NoSQL数据库提供了高性能和可扩展性。Neo4j可以与llm一起用于社交网络或知识图谱。一个具有矢量能力的时间序列数据库(如kdb)可能能够将矢量数据与金融市场数据结合起来。
缺点
NoSQL数据库的矢量功能是基本的/新生的/未经测试的。今年，许多NoSQL数据库添加了向量支持。比如：
今年5月，Cassandra宣布了增加矢量搜索的计划。
4月，Rockset宣布支持基本矢量搜索，
5月Azure Cosmos DB宣布支持MongoDB vCore的矢量搜索。
DataStax和MongoDB在本月（6月）宣布了矢量搜索功能(都是预览版)!
NoSQL数据库的矢量搜索性能可能差别很大，这取决于所支持的矢量函数、索引方法和硬件加速。而且NoSQL数据库的查询效率本来就不高，再加上矢量的功能，一定不会快。
我的观点一直没有变，那就是如果复杂数据一定要存到关系型数据库中，像MongoDB这样的当作辅助存储是没问题，但当作主要存储和主要查询那是所谓的自称为“全栈”的前端干出来的事，因为什么都不懂，所以觉得什么都简单。
5、支持矢量的SQL数据库
这些库与上面的类似，但是它们基本都是关系型数据库并且支持sql查询，例如SingleStoreDB, PostgreSQL, Clickhouse和Kinetica的pgvector/Supabase Vector(测试版)。
在一个已建立的数据库中添加基本的矢量功能并不是一件难事。比如矢量数据库Chroma就是来自ClickHouse
优点
包含矢量搜索功能，如点积，余弦相似度，欧几里得距离和曼哈顿距离。
使用相似度分数找到k个最近邻
多模型SQL数据库提供混合查询，并且可以将向量与其他数据结合起来以获得更有意义的结果
大多数SQL数据库都可以作为服务部署，可以在云上进行完全管理。
缺点
SQL数据库是为结构化数据而设计的。而矢量是非结构化数据，如图像、音频和文本。虽然关系数据库通常可以存储文本和blob，但大多数数据库不会将这些非结构化数据矢量化以用于机器学习。
大多数SQL数据库(还)没有针对向量搜索进行优化。关系数据库的索引和查询机制主要是为结构化数据设计的，而不是为高维矢量数据设计的。虽然用于向量数据处理的SQL数据库的性能可能不是特别好，但支持向量的SQL数据库可能会添加扩展或新功能来支持向量搜索。
传统的SQL数据库不能向外扩展，它们的性能会随着数据的增长而下降。使用SQL数据库处理高维向量的大型数据集可能需要进行额外的优化，比如对数据进行分区或使用专门的索引技术来保持高效的查询性能。
总结
所以，那么如何选择呢？
1、如果入门或者demo的话可以直接使用开源的矢量库，比如Faiss可以支持本地的亿级数据，但是无法提供对外服务。
2、对于产品，如果要开发新的功能并且上线，那就要将矢量存储和现有的存储分开，专业的人做专业的事，可选择纯矢量数据库或开源矢量库自行开发（如果功能简单的话），保证系统的稳定性。
3、如果非要在现有系统上使用矢量功能，比如Elastic、MongoDB 上存储和检索大量的矢量数据，那么一定要做好测试，并且自求多福吧，没准你遇到的问题不仅chatgpt不知道，stackoverflow上也没有。
4、现在矢量存储还是再发展阶段，所以有些功能还不完善，所以尽量使用成熟版本，对于生产环境不要冒险尝鲜。
最后说说架构的建议：
微服务架构是一种软件架构风格，其中应用程序被拆分为一组小型、独立的服务，每个服务都专注于提供特定的业务功能，每个微服务都应该专注于解决一个具体的业务问题或提供一项特定的功能。这种精细化的划分使得每个微服务可以根据需要进行独立的扩展、部署和维护。
矢量搜索也不例外应该独立成单独的服务，服务都独立了存储不是也应该独立吗。
当然如果非要把矢量存储和业务数据放在一起也可以，我没有任何意见，反正出问题又不是我来解决，我就看个热闹就行了😉