ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【向量检索】之向量数据库Milvus,Faiss详解及应用案例 [打印本页]

---

作者: 立山    时间: 2024-7-18 16:09
标题: 【向量检索】之向量数据库Milvus,Faiss详解及应用案例
Reference

https://www.modb.pro/db/509268
笔记︱几款多模态向量检索引擎：Faiss 、milvus、Proxima、vearch、Jina等 - 知乎 (zhihu.com)
向量数据库入坑指南：聊聊来自元宇宙大厂 Meta 的相似度检索技能 Faiss - 苏洋的文章 - 知乎
常用的三种索引方式及原理-CSDN
向量搜刮应用

向量检索技能，其重要的应用范畴如人脸识别、推荐体系、图片搜刮、视频指纹、语音处理、自然语言处理、文件搜刮

背景

向量检索需要用到向量数据库，而平凡的关系型数据库（如 MySQL、PostgreSQL）通常不适合处理向量检索任务。这是由于**【向量检索有其特殊的需求和性能要求】**。
缘故原由如下：
1、向量检索的特性

• 高维度数据：向量通常是高维数据，可能有数百到数千个维度。处理高维数据需要特殊的数据布局和算法，以确保检索的效率。
  
• 相似性度量：向量检索基于相似性度量（如欧氏间隔、余弦相似度等）来查找相似向量。盘算高维向量之间的相似性需要高效的算法，而平凡数据库没有优化这些操作。
  
• 近似近来邻搜刮（ANN）：在大规模数据集上，准确近来邻搜刮的盘算开销非常大，因此通常使用近似近来邻搜刮算法（如 LSH、HNSW、IVF 等）来提高检索效率。向量数据库通常内置了这些算法。
  

2、平凡数据库的限定

• 索引布局：平凡数据库的索引（如 B 树、哈希索引等）计划用于处理标量数据（如整数、字符串等），而不是高维向量。它们无法有效地支持高维相似性检索。
  
• 查询优化：平凡数据库的查询优化器针对 SQL 查询进行了优化，但对高维向量相似性检索的优化有限，可能导致查询性能低下。
  
• 扩展性：处理大规模向量数据需要分布式存储和盘算本领，平凡数据库在这方面的支持不如专门计划的向量数据库。
  

3、向量数据库的上风
向量数据库（如 FAISS、Milvus、Annoy、Weaviate 等）专门为向量检索计划，具备以下上风：

• 高效的索引布局：支持多种高效的索引布局（如 HNSW、IVF、PQ 等），能够快速处理高维向量的相似性检索。
  
• 优化的相似性盘算：针对高维向量的相似性盘算进行了优化，能够在大规模数据集上高效执行近来邻搜刮。
  
• 扩展性和分布式支持：许多向量数据库支持分布式存储和盘算，能够处理海量向量数据，并在多个节点之间均衡负载。
  

4、结论
向量数据库通过专门的索引布局、优化的相似性盘算以及分布式支持，显著提高了高维向量相似性检索的效率和扩展性。因此，对于需要处理大规模向量数据的应用场景（如推荐体系、图像搜刮、自然语言处理等），使用向量数据库是更好的选择。
索引类型

索引类型原理特点实用场景长处缺点FLAT线性扫描: 直接对全部向量进行线性扫描，盘算每个向量与查询向量之间的间隔。准确度高，速率较慢。小规模数据集或对精度要求非常高的场景。精度高，由于盘算了每个可能的间隔。对于大数据集，速率非常慢。IVF簇划分: 将向量数据集分为多个簇（clusters），然后在这些簇内搜刮。
【Inverted File Index】通过缩小搜刮范围加速查询。搜刮分两步：先找到最相关的簇，再在簇内搜刮。中大规模数据集，平衡速率和精度。加速搜刮速率，平衡速率和精度。精度稍低于 FLAT。PQ子空间划分: 将向量分成多个子空间
量化: 每个子空间独立量化，淘汰存储和盘算复杂度。
【Product Quantization】存储效率高，查询速率快。精度有损，但通常可接受。大规模数据集，对存储和查询速率要求高的场景。存储效率高，查询速率快。量化带来精度丧失。HNSW多层图布局: 构建一个包含多个层次的小世界图
导航搜刮: 从高层次开始，逐层向下搜刮，直到找到近来邻。
【Hierarchical Navigable Small World】高查询效率和精度，支持动态更新。高效查询，动态更新的大规模数据集。高效的查询速率和高精度。构建和维护图布局复杂，内存消耗较大。LSH哈希映射: 将相似的向量映射到相同的哈希桶。
【Locality-Sensitive Hashing】实用于高维数据，但精度相对较低。高维数据的近似近来邻搜刮。实用于高维数据，查询速率快。精度相对较低。ANNOY随机投影树: 构建多棵树，每棵树基于不同的随机投影。
【Approximate Nearest Neighbors Oh Yeah】平衡了搜刮速率和精度。大规模数据集。平衡速率和精度。构建时间较长。IVF-PQ簇划分和量化: 结合 IVF 和 PQ，将向量数据集分为多个簇，并在每个簇内进行量化。
【Inverted File with Product Quantization】进一步优化存储和查询效率。大规模数据集，需要存储和查询效率优化的场景。存储和查询效率进一步优化。构建和维护较复杂。ScaNN结合量化和排序: 结合矢量量化和间隔排序等技能。
【Scalable Nearest Neighbors】在处理大规模数据集时体现精彩。大规模数据集。在大规模数据集上体现精彩。算法复杂度较高。 ——from ChatGPT
相似度指标

• Euclidean distance (L2): This metric is generally used in the field of computer vision (CV).
  
• Inner product (IP): This metric is generally used in the field of natural language processing (NLP). The metrics that are widely used for binary embeddings include:
  
• Hamming: This metric is generally used in the field of natural language processing (NLP).
  
• Jaccard: This metric is generally used in the field of molecular similarity search.
  
• Tanimoto: This metric is generally used in the field of molecular similarity search.
  
• Superstructure: This metric is generally used to search for similar superstructure of a molecule.
  
• Substructure: This metric is generally used to search for similar substructure of a molecule.
  

向量数据库

以下是主流向量数据库的对比：
数据库发布者时间功能长处缺点MilvusZilliz (阿里巴巴孵化)2019多模态检索，分布式架构，数据长期化，查询优化高性能，多模态支持，易用性强部分功能依赖贸易支持FAISSFacebook AI Research2017多种索引类型，内存高效利用，GPU 加速高性能（尤其在 GPU 情况），灵活性强，社区支持丰富长期化和分布式支持较弱，使用门槛较高AnnoySpotify2014随机投影树，读多写少，支持磁盘长期化简朴易用，支持磁盘长期化写操作不高效，扩展性有限NMSLIB非官方开源项目2013多种近似近来邻算法，高性能，多语言绑定性能优秀，灵活性强文档和社区支持较少，缺乏贸易支持WeaviateSeMI Technologies2019分布式搜刮，知识图谱，RESTful API 和 GraphQL 支持上下文感知，结合知识图谱提供智能搜刮，支持分布式和大规模数据部分功能依赖外部服务和插件，社区生态较新PineconePinecone.io2020贸易化托管服务，多种索引，主动扩展，实时更新全托管服务，高可靠性，良好文档和客户支持使用本钱高，部分功能需要付费订阅QdrantQdrant2021高性能搜刮，实时更新，分布式架构，数据长期化高性能，实时更新，易用性强，支持分布式和长期化分布式功能较新，社区生态正在发展 —— ChatGPT
Milvus 是一个功能强大、支持多模态和分布式架构的向量数据库，实用于需要处理大规模、多样化数据的场景。
FAISS 则以其高性能和灵活性著称，特别适合需要高效向量检索和 GPU 加速的场景。选择合适的向量数据库需要根据具体的应用需求、数据规模和性能要求来决定。
向量数据库GitHub Star 数目GitHub Fork 数目社区活跃度使用情况及活跃度Milvus14k+2k+高使用情况：广泛应用于多模态检索、推荐体系等范畴。
社区活跃度：活跃，有定期更新和活跃的社区支持。FAISS22k+4k+高使用情况：被广泛用于研究和工业界的高性能向量检索任务，尤其在 GPU 情况下。
社区活跃度：非常活跃，有广泛的文档和社区支持。Annoy11k+1k+中使用情况：常用于推荐体系和音乐检索，尤其适合读多写少的场景。
社区活跃度：活跃，维护较好，但更新频率相对较低。NMSLIB3k+800+中使用情况：用于各种高性能向量检索任务，支持多种算法。
社区活跃度：活跃，有一定的用户底子和贡献者，但相对较小。Weaviate2k+300+中使用情况：实用于知识图谱和上下文感知的检索场景。
社区活跃度：活跃，但由于是相对较新的项目，用户底子和生态正在发展中。Pinecone无公开仓库无公开仓库高（贸易服务）使用情况：被多家企业用于生产情况中的向量检索任务。
社区活跃度：高，通过贸易支持和客户服务提供持续的更新和支持。 Milvus

【向量数据库】
【支持高效的向量检索】Milvus 采用了高效的算法和数据布局，如倒排索引、HNSW、量化等，优化搜刮性能和存储效率，适合于机器学习、人工智能和相似性搜刮的应用场景。
【高度可扩展】Milvus 支持容器化部署（如 Kubernetes）
【易用性和灵活性】【强大的社区支持】
官方Doc

https://milvus.io/docs/v2.2.x
背景

Milvus 是由 Zilliz 开辟并开源的高性能分布式向量数据库，最初是由阿里巴巴孵化，旨在处理大规模、多模态的向量检索任务。Milvus 是 LF AI & Data 基金会的托管项目之一。
功能

• 多模态向量检索：支持文本、图像、视频、音频等多种数据类型的向量检索。
  
• 多种索引类型：支持 IVF（Inverted File）、HNSW（Hierarchical Navigable Small World）、ANNOY、PQ（Product Quantization）等。
  
• 分布式架构：支持横向扩展，能够处理海量数据并提供高并发性能。
  
• 数据长期化：支持数据长期化和动态加载，确保数据的长期性和可恢复性。（Milvus 使用 RocksDB 作为长期化存储）
  
• 高级查询：支持复杂查询，如布尔查询、批量查询等。
  
• 图形化界面：提供 Milvus Insight 图形化管理界面，方便用户管理和监控集群。
  
• API 支持：提供丰富的 API，包括 RESTful API、Python SDK、Java SDK 等。
  

【多模态向量检索支持】

• 特征提取：结合预练习模子进行特征提取，将多模态数据（文本、图像、视频等）转化为向量表示。
  
• 统一接口：全部模态的数据在 Milvus 中统一表示为向量，用户可以通过统一接口进行检索操作。
  

【分布式架构】

• 集群架构：包括 Coordinator、Proxy、Data Node、Query Node、Index Node 等组件，支持横向扩展和高并发。
  
• 数据分片和分区：支持数据水平切分（Sharding）和逻辑分区（Partitioning），便于管理和检索。
  
• 索引管理：支持多种索引类型的分布式构建和维护，提高大规模数据的检索性能。
  
• 负载均衡和故障恢复：使用负载均衡机制和故障恢复机制，保证体系的高可用性。
  
• 数据长期化：支持数据长期化和恢复，确保数据在节点故障或重启时不会丢失。
  

架构

Milvus 的架构重要由以下几个组件构成：

• Coordinator：负责集群管理、元数据管理和任务调度。
  
• Proxy：处理客户端请求，负责数据路由和负载均衡。
  
• Data Node：负责数据存储和管理，包括数据长期化和索引构建。
  
• Query Node：处理查询请求，执行向量检索和结果返回。
  
• Index Node：负责索引构建和维护，提高查询效率。
  
• Meta Store：存储元数据，如数据表布局、索引信息等。
  

【节点】
query node 负责查询，data node 负责数据写入和长期化、index node负责索引创建和加速查询
the query node is in charge of data query; the data node is responsible for data insertion and data persistence; and the index node mainly deals with index building and query acceleration.
计划原则

The design principles of Milvus 2.0
数据流程
   【logs --> log snapshot --> segment】
  Both the table and the log are data, In the case of Milvus, it aggregates logs using a processing window from TimeTick. Based on log sequence, multiple logs are aggregated into one small file called log snapshot. Then these log snapshots are combined to form a segment, which can be used individually for load balance.
  第三方依赖：MinIO, etcd, and Pulsar.
Milvus cluster includes eight microservice components and three third-party dependencies: MinIO, etcd, and Pulsar.
Storage层有三个部分构成：
Meta store、Log broker、Object storage
数据处理过程

Reference
**数据写入和数据长期化：**https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md
加载数据到内存（实时查询）：https://milvus.io/blog/deep-dive-5-real-time-query.md#Load-data-to-query-node
1、数据写入：可以为每个 collection 设置分片数目（每个分片对应一个虚拟通道 vchannel），数据将根据主键的哈希值写入相应的分片。
You can specify a number of shards for each collection in Milvus, each shard corresponding to a virtual channel (vchannel). Any incoming insert/delete request is routed to shards based on the hash value of primary key.
当segment满了，会主动出发data flush (512 MB by default)

• **【segment】**Milvus中用于数据存储的最小单元。
  
• indexes are built on segments.
  
• Automatically flush segment data If the segment is full, the data coord automatically triggers data flush.
  

三种类型的segment

• There are three types of segments with different status in Milvus: growing, sealed, and flushed segment.
  
• growing：可以插入数据
  
• sealed：不再插入数据 A sealed segment is a closed segment
  
• flushed ：已经被写入磁盘 A flushed segment is a segment that has already been written into disk. A segment can only be flushed when the allocated space in a sealed segment expires.
  

2、索引创建：index node 从segmeng中将数据加载到内存，创建索引后再写回 object storage
The index node loads the log snapshots to index from a segment (which is in object storage) to memory , deserializes the corresponding data and metadata to build index, serializes the index when index building completes, and writes it back to object storage.
向量检索维度太高，传统基于树的索引不再顺应，取而代之的有基于聚类和基于图的索引。
Vectors cannot be efficiently indexed with traditional tree-based indexes due to their high-dimensional nature, but can be indexed with techniques that are more mature in this subject, such as cluster- or graph-based indexes.
3、查询：query node在加载到内存的segment中执行查询
A collection in Milvus is split into multiple segments, and the query nodes loads indexes by segment.
每个query 节点只负责两个任务：按照 query coord 的指令加载或开释段；在当地段中进行搜刮。
Each node is responsible only for two tasks: Load or release segments following the instructions from query coord; conduct a search within the local segments.
有两种类型的segment： growing segments 和sealed segments
There are two types of segments, growing segments (for incremental data), and sealed segments (for historical data). Query nodes subscribe to vchannel to receive recent updates (incremental data) as growing segments.

两只类型的数据被加载到query node : growing segments 和sealed segments
There are two types of data that are loaded to query node: streaming data from log broker, and historical data from object storage (also called persistent storage below).
query node 1从长期化存储中加载历史数据S1，从订阅日志代理中的channel 1加载G1
In query node 1 in the image, historical data (batch data), are loaded via the allocated S1 and S3 from persistent storage. In the meanwhile, query node 1 loads incremental data (streaming data) by subscribing to channel 1 in log broker.
存储布局（逻辑）

Collection

In Milvus, a collection is equivalent to a table in a relational database management system (RDBMS)
数据存储在聚集（Collection）中，每个聚集包含多个实体（Entity），每个实体包含多个字段（Field），但最重要的是向量字段（Vector Field）。
【分组存储】: 将不同类型的数据分别存储在不同的 collections 中。比方，一个用于存储图像特征向量的 collection，另一个用于存储文本特征向量的 collection。
index

索引构建由索引节点完成。为了避免数据更新时频仍构建索引，Milvus 中的聚集被进一步划分为多个段，每个段都有自己的索引。

• 检索加速: 索引通过优化数据存储和访问路径，提高查询速率，特别是在处理大规模向量数据时。
  
• 数据布局优化: 不同的索引类型（如 IVF、HNSW 等）使用不同的技能来组织数据，从而提拔检索效率和存储空间利用率。
  
• 重要索引类型:
  
  
  
  • FLAT: 准确搜刮，实用于小数据集。
    
  • IVF_FLAT: 倒排文件 + FLAT，平衡精度和速率。
    
  • IVF_SQ8: 倒排文件 + 量化技能，提高速率和低落存储空间。
    
  • IVF_PQ: 倒排文件 + 产物量化，实用于大规模数据集。
    
  • HNSW: 小世界图布局，实现高效的近似近来邻搜刮。
    
  
  

schema

Schema 用于定义聚集的属性以及聚集中字段。
Milvus 一个聚集中仅支持一个主键字段。
Reference: 字段架构属性
Field 数据类型

https://milvus.io/docs/schema.md
构成部分

查询 节点

【Query Node】
Milvus 将一个聚集拆分成多个 Segment，查询节点按 Segment 加载索引。当搜刮请求到达时，会广播到全部查询节点并发搜刮。然后每个节点剪枝当地 Segment，搜刮符合条件的向量，并缩减后返回搜刮结果。
Knowhere

Knowhere 是 Milvus 的核心向量执行引擎，它整合了多个向量相似性搜刮库，包括Faiss、Hnswlib和Annoy。 Knowhere 还旨在支持异构盘算。它控制在哪个硬件（CPU 或 GPU）上执行索引构建和搜刮请求。
ANNS 向量索引

Milvus 支持的向量索引类型大多采用近似近来邻搜刮（ANNS）算法。相较于通常非常耗时的准确检索，ANNS 的核心思想不再局限于返回最准确的结果，而是只搜刮目标的邻人。ANNS 通过在可接受的范围内捐躯准确率来提高检索效率。
优缺点

长处：

• 高性能：优化大规模数据和高并发场景。
  
• 多模态支持：处理多种数据类型的向量检索。
  
• 易用性和灵活性：通过提供多语言SDK和RESTful API，Milvus 确保了易用性和灵活性，满意开辟者和企业在图像检索、推荐体系、自然语言处理等多种场景下的需求。
  
• 分布式架构：支持横向扩展，适合大规模数据。
  

缺点：

• 部分高级功能依赖贸易支持。
  
• 学习曲线较陡峭，需要一定的配置和管理经验。
  

Milvus 应用场景

使用场景：推荐体系、图像搜刮、文本检索、视频检索等。
Milvus 应用场景示例：电商平台的多模态商品搜刮
场景形貌： 某大型电商平台需要提供多模态商品搜刮功能，包括基于图像、文本和视频的搜刮。用户可以通过上传图片、输入文本形貌或提供视频片段来查找相似的商品。平台需要处理海量商品数据，支持高并发的搜刮请求，并提供实时更新和长期化存储。
具体应用：

• 图像搜刮：用户上传一张商品图片，体系通过预练习的图像识别模子（如 ResNet）提取图像特征向量。Milvus 存储和管理这些特征向量，通过向量相似性搜刮返回最相似的商品。
  
• 文本搜刮：用户输入商品形貌（如“红色连衣裙”），体系通过 NLP 模子（如 BERT）提取文本特征向量。Milvus 存储文本向量，并基于向量相似性搜刮返回相关商品。
  
• 视频搜刮：用户上传一个视频片段，体系通过视频明白模子提取视频帧的特征向量。Milvus 存储和管理视频特征向量，通过向量相似性搜刮返回与视频内容相关的商品。
  

Milvus 的上风：

• 多模态支持：能够同时处理图像、文本和视频的向量检索，提供统一的检索接口。
  
• 分布式架构：支持横向扩展，顺应电商平台海量商品数据和高并发的搜刮请求。
  
• 数据长期化：支持数据长期化存储，确保数据的安全性和可恢复性。
  

问答

插入操作和查询操作是分离的吗？
插入操作和查询操作由两个相互独立的模块处理。从客户端的角度来看，当插入的数据进入消息队列时，插入操作就完成了。但是，插入的数据在加载到查询节点之前是不可搜刮的。如果段大小未到达索引构建阈值（默认为 512 MB），Milvus 将诉诸暴力搜刮，查询性能可能会低落。
Milvus 会将重复主键视为更新操作吗？
不会。Milvus 目前不支持更新操作，也不查抄实体主键是否重复。您有责任确保实体主键是唯一的，如果不是，Milvus 可能包含多个具有重复主键的实体。
FAISS

   Faiss is a library for efficient similarity search and clustering of dense vectors.
  C++ 开辟的，一些有效的算法要在GPU上实现
背景

FAISS（Facebook AI Similarity Search）是由 Facebook AI Research 开辟的高效向量相似性搜刮库，旨在处理大规模、高维向量数据的相似性搜刮任务。
功能

• 多种索引类型：支持 Flat、IVF（Inverted File）、HNSW（Hierarchical Navigable Small World）、PQ（Product Quantization）等索引。
  
• 高效盘算：优化了内存和盘算资源的使用，支持大规模向量数据的高效检索。
  
• GPU 加速：支持 GPU 加速，显著提拔大规模数据的检索性能。
  
• 聚类和分类：支持 K-means 聚类、层次聚类等算法，以及近来邻分类等任务。
  
• 多语言支持：提供 C++ 和 Python 接口，方便集成和使用。
  

架构

FAISS 的架构相对简朴，由以下几个核心组件构成：

• Index：存储和管理向量数据，并提供高效的检索功能。根据不同的索引类型，Index 有不同的实现。
  
• Vector Storage：存储原始向量数据。
  
• Distance Computation：盘算向量之间的相似性，支持多种相似性度量，如 L2 间隔、内积等。
  

优缺点

长处：

• 高性能：特别是在 GPU 情况下，FAISS 能够显著提拔检索速率。
  
• 灵活性：支持多种索引类型和配置，顺应不同应用场景。
  
• 社区支持：拥有大量用户和丰富的文档资源。
  

缺点：

• 数据长期化和分布式支持较弱：重要实用于内存内检索，不适合超大规模数据的长期存储和分布式处理。
  
• 学习曲线较陡峭：需要一定的配置和使用经验，特别是在选择和配置索引类型时。
  

数据长期化和分布式支持较弱的缘故原由

• 计划目标：FAISS 的计划更关注于内存内盘算的效率和性能，而不是数据存储和长期化。
  
• 内存内操作：重要在内存中操作向量数据和索引，以保证高效的相似性搜刮。
  
• 缺乏内置的长期化机制：固然支持手动保存和加载索引，但缺乏主动长期化和数据恢复机制。
  
• 单节点计划：初衷是为单节点计划，缺乏内置的集群管理、负载均衡和分布式同等性支持。
  

核心：它能够实现“高性能向量检索”的缘故原由
数据类型：Faiss只使用32位浮点矩阵（32-bit floating）。
Faiss 也能够指定数据类型，比如 IndexFlatL2、IndexHNSW、IndexIVF等二十来种类型
FAISS 应用场景

使用场景：推荐体系、图像搜刮、文本检索、生物信息学等。
FAISS 应用场景示例：研究机构的大规模基因相似性分析
场景形貌： 某研究机构需要进行大规模基因数据的相似性分析，比较数百万条基因序列之间的相似性，以发现潜在的基因关联和突变模式。体系需要高效的盘算本领，以在合理时间内完成大规模的相似性盘算。
具体应用：

• 数据准备：研究职员将基因序列数据转化为高维特征向量（如通过 k-mer 频率、序列嵌入等方法）。
  
• 索引构建：使用 FAISS 构建大规模基因特征向量的索引。研究机构可以利用 FAISS 的 IVF-PQ（Inverted File with Product Quantization）索引，以在保证高精度的同时显著淘汰内存占用。
  
• 相似性搜刮：通过 FAISS 的内存内盘算和 GPU 加速，快速进行基因向量的相似性搜刮，发现与目标基因序列最相似的其他基因。
  

FAISS 的上风：

• 高性能盘算：通过 GPU 加速和高效的索引布局，能够在大规模数据集上实现极高的相似性搜刮性能。
  
• 内存内操作：实用于需要在内存中进行高效盘算的场景，特别是在基因相似性分析中，能够在较短时间内处理大量数据。
  
• 灵活性：支持多种索引类型和相似性度量，顺应不同的数据特征和分析需求。
  

对比

Elasticsearch 是一个开源的分布式搜刮和分析引擎，重要用于全文搜刮、布局化搜刮、日志和数据分析。尽管 Elasticsearch 强大且多功能，但在替代 Milvus 或 FAISS 用于向量检索方面有其局限性。
Elasticsearch 的长处

• 全文搜刮和布局化搜刮：Elasticsearch 在处理全文搜刮、布尔查询和布局化数据搜刮方面非常强大，提供了丰富的查询DSL。
  
• 分布式架构：Elasticsearch 的分布式架构和水平扩展本领使其能够处理大规模数据集和高并发查询。
  
• 数据长期化：内置数据长期化和索引恢复机制，保证数据的长期性和可恢复性。
  
• 实时索引和查询：支持实时的数据索引和查询，非常适合日志分析和时间序列数据。
  
• 生态体系和工具：拥有丰富的生态体系和工具，如 Kibana 用于数据可视化，Logstash 用于数据处理和管道。
  

Elasticsearch 的向量检索功能

Elasticsearch 引入了向量检索功能，通过插件（如 Elasticsearch k-NN 插件）或直接支持向量字段（如 dense_vector 类型）来实现向量相似性搜刮。以下是它在向量检索方面的特点：

• k-NN 插件：Elasticsearch 提供 k-NN 插件，支持基于 L2 间隔和余弦相似度的向量检索。
  
• dense_vector 类型：允许将向量作为字段存储在索引中，并使用向量相似度进行搜刮。
  
• 集成性：可以与 Elasticsearch 的其他功能（如全文搜刮、聚合分析）无缝集成。
  

Elasticsearch 与 Milvus 和 FAISS 的对比

1. 性能

• FAISS：专为高效内存内向量检索计划，特别是在 GPU 情况下，能够提供极高的检索速率。
  
• Milvus：专注于高性能向量检索，支持多种索引类型和分布式架构，适合大规模、高并发的向量检索任务。
  
• Elasticsearch：在全文搜刮和布局化搜刮方面体现精彩，但在高维向量检索性能上可能不如 FAISS 和 Milvus。尽管 k-NN 插件提供了向量检索功能，但在处理大规模高维向量数据时，性能可能不如专门计划的向量数据库。
  

2. 数据长期化和分布式支持

• Milvus：内置数据长期化和分布式支持，适合大规模数据管理和高并发访问。
  
• Elasticsearch：具备强大的数据长期化和分布式架构，能够处理大规模数据，并提供高可用性和数据恢复机制。
  
• FAISS：重要计划用于内存内检索，缺乏内置的数据长期化和分布式支持，需要额外的解决方案来实现这些功能。
  

3. 多模态支持

• Milvus：专为多模态向量检索计划，能够处理文本、图像、视频等多种数据类型。
  
• Elasticsearch：重要用于文本和布局化数据搜刮，通过扩展支持向量检索，但在多模态数据处理上不如 Milvus 专业。
  

4. 易用性和生态体系

• Elasticsearch：拥有丰富的生态体系和工具，提供直观的界面和广泛的社区支持，易于集成和使用。
  
• Milvus 和 FAISS：需要一定的配置和使用经验，Milvus 提供了图形化管理界面和丰富的 API，而 FAISS 更适合有特定高性能需求的用户。
  

5.实用场景

• Milvus 特别适合于需要高效向量搜刮的应用，如图像和视频检索、推荐体系、自然语言处理和生物信息学等。它在处理这些需要盘算内容相似度的复杂查询时体现精彩。
  
• Elasticsearch 广泛用于日志分析、全文搜刮、数据可视化（通过Kibana）和近实时的数据分析等场景。它在处理文本数据和提供灵活、复杂的查询本领方面非常强大。
  
• Milvus适合高维向量检索（如图像、音频、文本嵌入等相似度搜刮），由于它能提供高效的向量检索。Milvus在大规模数据集和复杂索引类型下，会**倾向于将大量数据加载到内存**中。这使得Milvus在处理高维向量检索时能提供低延迟和高吞吐量。
  
• Elasticsearch适合全文搜刮或布局化数据检索，由于它**通过倒排索引和缓存机制**能在较低内存占用下提供高效的查询。
  

数据规模

具体来说，处理大规模高维向量数据时，Elasticsearch 的性能瓶颈会因数据规模和具体的检索需求而有所不同。然而，可以提供一些指导性的数据规模和考虑因素，资助判断何时应该使用专门计划的向量数据库（如 Milvus 或 FAISS）而不是 Elasticsearch。
判断数据规模的尺度

1. 向量维度

高维向量数据（如 128 维、256 维甚至更高）需要更多的盘算资源来进行相似性盘算。一样寻常来说，当向量维度超过 100 时，就需要考虑优化盘算性能的方案。
2. 向量数目

数据集的规模在向量数目上也是一个关键因素。如果数据集中有数百万到数亿的向量，Elasticsearch 在进行高效检索时可能会碰到性能瓶颈。在这种情况下，专门的向量数据库可能更适合。
3. 检索延迟和并发请求量

对于实时性要求高、并发请求量大的应用场景，Elasticsearch 的性能可能无法满意要求。专门的向量数据库（如 Milvus 和 FAISS）在计划上更适合这种高并发、低延迟的需求。
具体规模建议

• 小规模数据集：
  
  
  
  • 向量数目：少于 100,000 个向量
    
  • 向量维度：少于 128 维
    
  • 实用性：Elasticsearch 可以很好地处理，并提供丰富的搜刮功能。
    
  
  
• 中等规模数据集：
  
  
  
  • 向量数目：100,000 到 1,000,000 个向量
    
  • 向量维度：128 到 256 维
    
  • 实用性：Elasticsearch 可以处理，但可能需要优化和调优索引配置。在高并发场景下可能出现性能问题。
    
  
  
• 大规模数据集：
  
  
  
  • 向量数目：超过 1,000,000 个向量
    
  • 向量维度：超过 256 维
    
  • 实用性：需要考虑使用专门的向量数据库（如 Milvus 或 FAISS），以确保检索性能和体系可扩展性。
    
  
  

问答

！！！传统数据库和向量数据库的显著区别在哪里？
传统数据库重IO，向量数据库则需要大量盘算资源
传统数据库：

• 重IO操作：传统数据库（如MySQL、PostgreSQL等）在进行数据读写时，重要依赖磁盘的输入输出操作（IO）。这些操作包括将数据从磁盘读取到内存或将数据从内存写入磁盘。
  
• 关注磁盘IO和CPU使用率等指标：在管理和优化传统数据库时，管理员通常会关注磁盘IO（读写速率和延迟）和CPU使用率。这是由于这两个指标直接影响数据库的性能，尤其是在处理大量读写请求时。
  

向量数据库：

• 计划盘算节点和存储时需要考虑CPU和GPU：向量数据库（如Milvus、FAISS等）在存储和检索向量（高维数据，如图像或文本的嵌入表示）时，不但依赖CPU，还可能需要使用GPU。这是由于向量检索（如盘算向量之间的相似度）通常需要大量的盘算资源，尤其是在处理高维向量和大规模数据时，GPU能够显著提高盘算效率
  

实践

Faiss

安装：INSTALL-FAISS
使用

1. # 构建索引
2. import faiss                   # make faiss available
3. index = faiss.IndexFlatL2(d)   # build the index
4. print(index.is_trained)
5. index.add(xb)                  # add vectors to the index
6. print(index.ntotal)
8. # 搜索
9. k = 4                          # we want to see 4 nearest neighbors
10. D, I = index.search(xb[:5], k) # sanity check 输入为query embeddig和neighbors数

复制代码

API Reference

https://faiss.ai/
https://ai.meta.com/tools/faiss/
https://github.com/facebookresearch/faiss/wiki
https://github.com/facebookresearch/faiss/wiki/Faiss-indexes
example Reference
How to Use FAISS to Build Your First Similarity Search-medium
Milvus

Reference
milvus.io/docs
Milvus性能优化提速之道：揭秘优化本领，避开十大误区- 知乎
https://github.com/milvus-io/pymilvus/tree/2.2/examples
在 Milvus 中，collection 和 index 是两个核心概念，它们分别负责数据存储和数据检索的组织和优化。

• Collection 与 Index 的关系:
  
  
  
  • 每个 collection 可以有多个字段，其中一个字段通常是向量字段。为了加速对该向量字段的检索，可以为其创建索引。
    
  • 索引是基于 collection 中的向量数据构建的，创建索引后，检索操作会显著加速。
    
  
  

示例应用

• 创建 Collection:
  

1. from pymilvus import CollectionSchema, FieldSchema, DataType, Collection
3. # 定义字段
4. id_field = FieldSchema(name="id", dtype=DataType.INT64, is_primary=True)
5. vector_field = FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=128)
7. # 定义 schema
8. schema = CollectionSchema(fields=[id_field, vector_field], description="example collection")
10. # 创建 collection
11. collection = Collection(name="example_collection", schema=schema)

复制代码

• 创建 Index:
  

1. index_params = {
2.     "index_type": "IVF_FLAT",
3.     "params": {"nlist": 128},
4.     "metric_type": "L2"
5. }
6. collection.create_index(field_name="vector", index_params=index_params)

复制代码

通过明白 collection 和 index 的概念及其功能，可以更好地在 Milvus 中组织和优化向量数据的存储和检索。
查看 collection

1. # 查看index
2. from pymilvus import Collection
3. collection = Collection("book")  # Get an existing collection.
5. # 查看collection
6. collection.schema                # Return the schema.CollectionSchema of the collection.
7. collection.description           # Return the description of the collection.
8. collection.name                  # Return the name of the collection.
9. collection.is_empty              # Return the boolean value that indicates if the collection is empty.
10. collection.num_entities          # Return the number of entities in the collection.
11. collection.primary_field         # Return the schema.FieldSchema of the primary key field.
12. collection.partitions            # Return the list[Partition] object.
13. collection.indexes               # Return the list[Index] object.
14. collection.properties       # Return the expiration time of data in the collection.

复制代码

加载到内存 collection

Milvus 中的全部搜刮和查询操作都是在内存中执行的。因此在执行搜刮或查询之前需要将聚集加载到内存。
这个加载过程发生在Milvus服务所在的服务器上，而不是客户端。

1. # Get an existing collection.
2. collection = Collection("book")      
3. collection.load(replica_number=2)
5. utility.loading_progress("book")
6. # Output: {'loading_progress': 100%}

复制代码

在搜刮或查询之后从内存中开释聚集以淘汰内存使用量。

1. from pymilvus import Collection
2. collection = Collection("book")      # Get an existing collection.
3. collection.release()       

复制代码

数据写入和更新 collection

1. from pymilvus import Collection
2. collection = Collection("book")      # Get an existing collection.
3. mr = collection.insert(data)
5. # 批量插入 API
6. # 使用 NumPy 数组将数据集的每一列组织到单独的文件中。在这种情况下，使用每列的字段名称来命名 NumPy 文件。
7. from pymilvus import utility
8. task_id = utility.do_bulk_insert(
9.     collection_name="book",
10.     partition_name="2022",
11.     files=["book_id.npy", "word_count.npy", "book_intro.npy", "book_props.npy"]
12. )
14. def flush_collection(self):
15.     """ 刷新数据 """
16.     self.collection.load() # 这个方法用于将 collection 加载到内存中，以便进行查询，如果 collection 已经在内存中，则此操作不会重复加载。
17.     self.collection.flush() # 这个方法用于将内存中的数据刷新到磁盘上，确保所有在内存中的变更（例如插入或删除操作）都持久化到磁盘。
18.     logger.info("Success flush collection")

复制代码

Milvus 刷新数据到磁盘

当插入的数据加载到消息队列中时，Milvus 返回乐成，但数据还未刷入磁盘。此时，Milvus 的数据节点会将消息队列中的数据以增量日志的情势写入长期化存储。如果flush()调用，则强制数据节点立即将消息队列中的全部数据写入长期化存储。如果您**需要在插入后立即搜刮数据**，则可以在数据插入后调用该flush()方法。
   Milvus 会主动触发该flush()操作。大多数情况下，无需手动调用此操作。
  如果需要**全量更新一个 Collection** 的数据，推荐使用新建表 + 导入数据 + Alias 切换的方案
MilvusHelper

1. import os
2. import sys
3. from loguru import logger
4. from pymilvus import (
5.     connections,
6.     FieldSchema, CollectionSchema, DataType,
7.     Collection, utility,
8.     BulkInsertState
9. )
11. class MilvusHandler:
12.     def __init__(
13.             self,
14.             host=MILVUS_HOST,
15.             port=MILVUS_PORT
16.     ):
17.         self.host = host
18.         self.port = port
19.         self.connect()
21.     def connect(self):
22.         connections.connect("default", host=self.host, port=self.port)
23.         logger.info("Successfully connected to Milvus")
25.     @staticmethod
26.     def disconnect():
27.         # 断开连接
28.         connections.disconnect("default")
29.         logger.info("Successfully disconnected from Milvus")
31.     def create_collection(self, collection_name=None, collection_dim=None):
32.         # 初始化 Collection 对象
33.         if self.has_collection(collection_name=collection_name):
34.             collection = Collection(name=collection_name)
35.             logger.info(f"Connected to existing collection:{collection_name}")
36.         else:
37.             fields = [
38.                 FieldSchema(name="id", dtype=DataType.VARCHAR, description="text name", max_length=500, is_primary=True,
39.                             auto_id=False),
40.                 FieldSchema(name="vec", dtype=DataType.FLOAT_VECTOR, description="text embedding vectors",
41.                             dim=collection_dim)
42.             ]
43.             schema = CollectionSchema(fields, "Collection for text embeddings")
44.             collection = Collection(name=collection_name, schema=schema, using='default')
45.             self.create_index(collection=collection, filed_name="vec")
46.             logger.info(f"Successfully created collection :{collection_name}")
47.         return collection
49.     @staticmethod
50.     def create_alias(collection_name, alias):
51.         utility.create_alias(collection_name=collection_name, alias=alias)
53.     @staticmethod
54.     def drop_alias(alias):
55.         utility.drop_alias(alias=alias)
57.     @staticmethod
58.     def drop_collection(collection_name):
59.         utility.drop_collection(collection_name)
60.         logger.info(f"Dropped collection: {collection_name}")
62.     def has_collection(self, collection_name):
63.         return utility.has_collection(collection_name)
65.     @staticmethod
66.     def list_collections():
67.         collections = utility.list_collections()
68.         logger.info(f"List of collections: {collections}")
69.         return collections
71.     @staticmethod
72.     def create_index(collection, filed_name=None, index_param=None):
73.         if not index_param:
74.             index_param = {
75.                 "index_type": "FLAT",
76.                 "metric_type": "IP",
77.                 "params": {}
78.             }
79.         collection.create_index(filed_name, index_param)
80.         logger.info(f"Success create index")
82.     @staticmethod
83.     def drop_index(collection):
84.         collection.drop_index()
85.         logger.info(f"Success drop index")
87.     @staticmethod
88.     def load_collection(collection):
89.         collection.load()
91.     @staticmethod
92.     def flush_collection(collection):
93.         collection.flush()
95.     @staticmethod
96.     def load_and_flush_collection(collection):
97.         """ 刷新数据 """
98.         # 测试加载速度
99.         import time
100.         start_time = time.time()
101.         collection.load()
102.         end_time = time.time()
103.         print(f"Loading time: {end_time - start_time} seconds")
104.         collection.flush()
105.         logger.info("Success flush collection")
107.     @staticmethod
108.     def release_collection(collection):
109.         """释放内存中加载的collection"""
110.         collection.release()
111.         logger.info("Success release collection")
113.     @staticmethod
114.     def compact_collection(collection):
115.         """合并segement"""
116.         collection.compact()
117.         logger.info(f" release collection status：{collection.get_compaction_state()}")
119.     @staticmethod
120.     def insert_entity(collection, entities):
121.         """
122.         单次写入小于 10MB 以下，建议选择流式写入
123.         """
124.         # entities = [
125.         #     {"name": "id", "values": ids, "type": DataType.VARCHAR},
126.         #     {"name": "vec", "values": vectors, "type": DataType.FLOAT_VECTOR}
127.         # ]
128.         mr = collection.insert(entities)
129.         # (insert count: 10, delete count: 0, upsert count: 0, timestamp: {self._timestamp}, success count: {self.succ_count}, err count: {self.err_count})
130.         logger.info(f"Data inserted successfully.{mr}")
131.         return mr
133.     @staticmethod
134.     def bulk_insert(collection_name=None, files: list = ["id.npy", "vec.npy"]):
135.         """
136.          BulkInsert 不会对查询性能造成太大的影响
137.         :param collection_name:
138.         :param files:
139.         :return:
140.         """
141.         task_id = utility.do_bulk_insert(
142.             collection_name=collection_name,
143.             files=files
144.         )
146.         task = utility.get_bulk_insert_state(task_id=task_id)
147.         print("Task state:", task.state_name)
148.         print("Imported files:", task.files)
149.         print("Collection name:", task.collection_name)
150.         print("Partition name:", task.partition_name)
151.         print("Start time:", task.create_time_str)
152.         print("Imported row count:", task.row_count)
153.         print("Entities ID array generated by this task:", task.ids)
155.         if task.state == BulkInsertState.ImportFailed:
156.             print("Failed reason:", task.failed_reason)
158.     @staticmethod
159.     def delete_entity(collection, ids):
160.         expr = f'id in {ids}'
161.         dr = collection.delete(expr)
162.         logger.info(f"Data deleted successfully.{dr}")
163.         return dr
165.     def update_entity(self, ids, collection, vectors):
166.         self.delete_entity(collection, ids)
167.         self.insert_entity(collection, entities=[ids, vectors])
168.         logger.info(f"Data update successfully")
170.     @staticmethod
171.     def get_entity_num(collection):
172.         entity_num = collection.num_entities
173.         logger.info(f"Number of entities: {entity_num}")
174.         return entity_num
176.     @staticmethod
177.     def search(collection, query_vector, top_k=10):
179.         # "param": {"metric_type":  "IP", "params": {"nprobe": _NPROBE}},
180.         search_param = {
181.             "data": [query_vector],
182.             "anns_field": "vec",
183.             "param": {"metric_type": "IP"},
184.             "limit": top_k,
185.             "expr": None,
186.             "output_fields": ["id"]}
188.         results = collection.search(**search_param)
190.         # results[0].ids
191.         #
192.         # results[0].distances
193.         #
194.         # hit = results[0][0]
195.         # hit.entity.get('title')
196.         return results

复制代码

• collection.num_entities 返回的是逻辑上的总实体数，包括了已删除但尚未物理移除的实体。compaction 操作会集并数据段，并在此过程中移除标记为删除的数据。当前存在问题：删除未被盘算 https://github.com/milvus-io/milvus/issues/17193
  

Milvus Lite 和 Milvus

• 架构：
  
  
  
  • Milvus：采用了分布式架构，实用于需要处理大规模数据和高并发请求的场景。它能够分布在多个节点上，提供高可用性和扩展性。
    
  • Milvus Lite：是一个轻量级版本，实用于单节点部署，重要面向开辟、测试和小规模应用场景。
    
  
  
• 资源需求：
  
  
  
  • Milvus：由于其分布式架构，通常需要更多的盘算和存储资源来运行，需要集群情况和专业的运维支持。
    
  • Milvus Lite：计划为轻量级，占用资源少，可以在单机上运行，适合资源有限的情况。
    
  
  
• 性能和扩展性：
  
  
  
  • Milvus：在性能和扩展性方面更强大，能够处理大规模数据和高并发请求，可以根据需要水平扩展集群。
    
  • Milvus Lite：性能和扩展性有限，重要实用于小规模数据和低并发请求的场景。
    
  
  
• 运维复杂度：
  
  
  
  • Milvus：需要专业的运维管理，包括节点管理、负载均衡和故障恢复等。
    
  • Milvus Lite：运维相对简朴，适合开辟者个人或小团队进行开辟和测试。
    
  
  

实用场景

• Milvus：实用于需要处理大量数据、复杂查询以及高并发请求的大型生产情况，如搜刮引擎、大数据分析、推荐体系等。
  
• Milvus Lite：实用于开辟、测试、小规模应用场景或资源受限的情况，适合个人开辟者、小团队、初创企业进行向量检索相关的开辟和测试。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4