共计 4202 个字符，预计需要花费 11 分钟才能阅读完成。
矢量数据库是为实现高维矢量数据的高效存储、检索和相似性搜寻而设计的。应用一种称为嵌入的过程，将向量数据表示为一个间断的、有意义的高维向量。
本文将钻研存储 / 检索向量数据和执行相似性搜寻的实用办法，在咱们深入研究之前，首先先介绍矢量数据库的两个要害性能：
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、当初矢量存储还是再倒退阶段，所以有些性能还不欠缺，所以尽量应用成熟版本，对于生产环境不要冒险尝鲜。
最初说说架构的倡议：
微服务架构是一种软件架构格调，其中应用程序被拆分为一组小型、独立的服务，每个服务都专一于提供特定的业务性能，每个微服务都应该专一于解决一个具体的业务问题或提供一项特定的性能。这种精细化的划分使得每个微服务能够依据须要进行独立的扩大、部署和保护。
矢量搜寻也不例外应该独立成独自的服务，服务都独立了存储不是也应该独立吗。
当然如果非要把矢量存储和业务数据放在一起也能够，我没有任何意见，反正出问题又不是我来解决，我就看个冷落就行了😉
https://avoid.overfit.cn/post/24ac8df6f375489d9d1ece144cdf4596