milvus: 专为向量查询与检索设计的向量数据库_milvusdm

1. 什么是milvus？

milvus docs
milvus release

Milvus的目标是：store, index, and manage massive embedding vectors generated by deep neural networks and other machine learning (ML) models.

Milvus 向量数据库专为向量查询与检索设计，能够为万亿级向量数据建立索引。

与现有的关系数据库主要按照预定义的模式处理结构化数据不同，Milvus采用自底向上设计，以处理从非结构化数据转换而来的Embedding向量。

特点如下：

• 高性能：性能高超，可对海量数据集进行向量相似度检索。
• 高可用、高可靠：Milvus 支持在云上扩展，其容灾能力能够保证服务高可用。
• 混合查询：Milvus 支持在向量相似度检索过程中进行标量字段过滤，实现混合查询。
• 开发者友好：支持多语言、多工具的 Milvus 生态系统。

2. milvus架构

Milvus 采用共享存储架构，存储计算完全分离，计算节点支持横向扩展。

从架构上来看，Milvus 遵循数据流和控制流分离，整体分为了四个层次，分别为接入层（access layer）、协调服务（coordinator service）、执行节点（worker node）和存储层（storage）。各个层次相互独立，独立扩展和容灾。

Milvus 的内部无状态组件共 8 个，依赖 3 个外部服务/中间件

2.1. 系统层次划分

整个系统分为四个层次：

• 接入层（Access Layer）：系统的门面，由一组无状态 proxy 组成。对外提供用户连接的 endpoint，负责验证客户端请求并合并返回结果。
• 协调服务（Coordinator Service）：系统的大脑，负责分配任务给执行节点。协调服务共有四种角色，分别为 root coord、data coord、query coord 和 index coord。
• 执行节点（Worker Node）：系统的四肢，负责完成协调服务下发的指令和 proxy 发起的数据操作语言（DML）命令。执行节点分为三种角色，分别为 data node、query node 和 index node。
• 存储服务 （Storage）： 系统的骨骼，负责 Milvus 数据的持久化，分为元数据存储（meta store）、消息存储（log broker）和对象存储（object storage）三个部分。
  

2.2. 架构实现特点

Milvus2.x版本的架构实现特点：

• 微服务化：Milvus将服务拆成多个角色，每个角色职责划分相对独立，其中IndexNode/QueryNode/DataNode 这些角色是实际工作的Woker节点，IndexCoord/QueryCoord/DataCoord 是负责协调Woker节点，及将任务协调并分派给其他角色的节点。

  • ETCD:负责存储元数据
  • 对象存储:负责存储向量数据
  • Proxy:Milvus统一的访问层
  • DataNode/DataCoord: 负责向量的写入
  • IndexNode/IndexCoord:负责向量索引的构建
  • QueryNode/QueryCoord : 负责向量的查询
  • RootCoord: 负责处理DDL去协调其他Coord，全局时间分发，维护当前元数据快照

• 支持云原生：Milvus 服务本身是没有状态的，数据存储在对象存储，元数据会存放在ETCD。原生支持K8s部署集群部署，可以根据集群或者个别角色的负载去动态扩缩资源。

• 向量操作【读/写/建索引】之间进程级别隔离：向量 读/写/建索引都是通过不同的节点完成，这样操作之间都是通过进程之间隔离，不会抢占资源，相互影响。

• 在查询的时候指定不同的一致性级别：在真实的业务场景中，一致性要求越强，查询对应的响应时间也会变长。用户可以根据自己的需求选择不同的一致性级别。

2.3. Knowhere

如果把 Milvus 比喻为一辆跑车，Knowhere 就是这辆跑车的引擎。

Knowhere是Milvus的核心向量执行引擎，它集成了几个矢量相似度搜索库，包括Faiss, Hnswlib和Annoy。

Knowhere 的定义范畴分为狭义和广义两种:

• 狭义上的 Knowhere 是下层向量查询库（如Faiss、HNSW、Annoy）和上层服务调度之间的操作接口。同时，异构计算也由 Knowhere 这一层来控制，用于管理索引的构建和查询操作在何种硬件上执行， 如 CPU 或 GPU，未来还可以支持 DPU/TPU/……这也是 Knowhere 这一命名的源起 —— know where。

• 广义上的 Knowhere 还包括 Faiss 及其它所有第三方索引库。因此，可以将 Knowhere 理解为 Milvus 的核心运算引擎。

从上述定义可以得知，Knowhere 只负责处理数据运算相关的任务，其他系统层面的任务如数据分片、负载均衡、灾备等，都不在它的功能范畴中。另外，从 Milvus 2.0.1 开始，广义的 Knowhere 已从 Milvus 项目中剥离出来，成为了一个单独的项目。

架构特点：

• 最底层是系统硬件
• 第三方索引库位于硬件之上
• Knowhere通过CGO与顶部的索引节点和查询节点交互，这允许Go包调用C代码。
  

3. 核心概念

所有概念及术语参见 Milvus glossary

3.1.向量相似度检索

向量相似性搜索是将一个向量与数据库中的数据进行比较，以找到与目标搜索向量最相似的向量的过程。

近似最近邻(ANN)搜索算法用于计算向量之间的相似性

3.2. 记录相关概念

• collection-集合： 包含一组 entity，可以等价于关系型数据库系统（RDBMS）中的表。
• entity-实体：包含一组 field。
  • 注意: Milvus 2.0在一个集合中只支持一个主键字段。
    • 可以自定义 primary key，否则 Milvus 将会自动生成 primary key
    • 目前 Milvus 不支持 primary key 去重，因此有可能在一个 collection 内出现 primary key 相同的 entity。
• field -字段：Entity 的组成部分
  • field 可以是代表对象属性的结构化数据，例如数字和字符串
  • field 可以是代表对象特征的向量。primary key 是用于指代一个 entity 的唯一值。
  • 注意： Milvus 2.0 现已支持标量字段过滤

Milvus与关系型数据库的对应关系如下：

3.3.Partition-分区

分区是集合（Collection）的一个分区。Milvus 支持将收集数据划分为物理存储上的多个部分。这个过程称为分区，每个分区可以包含多个segment。

3.4.Segment-段

Milvus 在数据插入时，通过合并数据自动创建的数据文件。一个 collection 可以包含多个 segment。一个 segment 可以包含多个 entity。在搜索中，Milvus 会搜索每个 segment，并返回合并后的结果。

3.5.Sharding-分片

Sharding是指将写操作分配到不同的节点上，以最大限度地利用Milvus集群的并行计算潜力来写数据。默认情况下，单个集合包含两个分片。Milvus采用基于主键哈希的分片方法。Milvus未来支持更灵活的分片方法，如随机分片和自定义分片。

3.6. bitset

bitset是位的集合，位是只有两个可能值的元素，最典型的是0和1，或者布尔值true和false。

• 在Milvus中，bitset是由位数0和1组成的数组，与整型、浮点数或字符不同，bitset可以用来紧凑而高效地表示某些数据。默认为0，只有满足特定要求时才会设置为1。
• 对bitset的操作使用布尔逻辑进行，在布尔逻辑下，输出值要么有效，要么无效，也分别用1和0表示
  如：逻辑运算符AND可用于基于位于相同索引位置的项比较两个bitset，并使用结果生成一个新的bitset，如果位置上的两个元素相同，则在新的bitset中，1将被写入该位置;如果不相同，则为0。

Bitset是一个简单而强大的机制，可以帮助Milvus执行属性过滤、数据删除和Time Travel查询。

• Attribute filtering： 满足给定属性过滤器要求的数据被标记为1。
• Data deletion：bitset作为一种简洁的方式来存储关于段中的一行是否被删除的信息。被删除的实体在相应的bitset中被标记为1，在搜索或查询期间不会计算
• Query with Time Travel：当您使用Time Travel进行搜索时，Milvus使用bitsets来存储有关某个段中的数据是否满足travel_timestamp中的时间戳要求的信息

4. 业务架构

在实际项目落地时，业务架构图示意如下：

5.部署模式

5.1.单机版 Milvus

单机版 Milvus 包括三个组件：

• Milvus 负责提供系统的核心功能。
• etcd 是元数据引擎，用于管理 Milvus 内部组件的元数据访问和存储，例如：proxy、index node 等。
• MinIO 是存储引擎，负责维护 Milvus 的数据持久化。
  

5.2.分布式版 Milvus

分布式版 Milvus 由八个微服务组件和三个第三方依赖组成，每个微服务组件可使用 Kubernetes 独立部署。

• 微服务组件
  • Root coord ： 负责处理数据定义语言（DDL）和数据控制语言（DCL）请求。比如，创建或删除 collection、partition、index 等，同时负责维护中心授时服务 TSO 和时间窗口的推进。
  • Query coord：负责管理 query node 的拓扑结构和负载均衡以及从 growing segment 移交切换到 sealed segment。Query node 中的 segment 只存在两种状态：growing 和 sealed，分别对应增量数据和历史数据。
  • Index coord：负责管理 index node 的拓扑结构，构建索引和维护索引元信息。
  • Data coord：负责管理 data node 的拓扑结构，维护数据的元信息以及触发 flush、compact 等后台数据操作。
  • Proxy：
  • Query node： 通过订阅消息存储（log broker）获取增量日志数据并转化为 growing segment，基于对象存储加载历史数据，提供标量+向量的混合查询和搜索功能。
  • Index node：负责执行索引构建任务。Index node不需要常驻于内存，可以通过 serverless 的模式实现。
  • Data node：通过订阅消息存储获取增量日志数据，处理更改请求，并将日志数据打包存储在对象存储上实现日志快照持久化。
• 第三方依赖
  • etcd 负责存储集群中各组件的元数据信息。
  • MinIO 负责处理集群中大型文件的数据持久化，如索引文件和全二进制日志文件。
  • Pulsar 或 Kafka 负责管理近期更改操作的日志，输出流式日志及提供日志订阅服务。
    

6. Milvus提供的工具

6.1. Milvus Cli

Milvus CLI (Command-Line Interface)是一个命令行工具，提供数据库连接、数据操作、数据导入导出等功能。基于Milvus Python SDK，它允许使用交互式命令行提示符通过终端执行命令。

6.2. Milvus Backup

Milvus Backup是一个允许用户备份和恢复Milvus数据的工具。它同时提供CLI和API，以适应不同的应用场景。

6.3. MilvusDM

MilvusDM (Milvus Data Migration)是一个开源工具，专为使用Milvus导入和导出数据而设计。MilvusDM允许迁移特定集合或分区中的数据。

为了大幅提高数据管理效率，降低DevOps成本，MilvusDM支持以下迁移通道:

• Milvus to Milvus: Migrates data between instances of Milvus.
• Faiss to Milvus: Imports unzipped data from Faiss to Milvus.
• HDF5 to Milvus: Imports HDF5 files into Milvus.
• Milvus to HDF5: Saves the data in Milvus as HDF5 files.

6.4. Milvus Attu

Milvus的一个高效的开源管理工具。它具有直观的图形用户界面(GUI)，允许您轻松地与数据库进行交互。只需单击几下，就可以可视化集群状态、管理元数据、执行数据查询等等。

7. Milvus 应用场景

可以使用 Milvus 搭建符合自己场景需求的向量相似度检索系统。Milvus 的使用场景如下所示：

• 图片检索系统：以图搜图，从海量数据库中即时返回与上传图片最相似的图片。
• 视频检索系统：将视频关键帧转化为向量并插入 Milvus，便可检索相似视频，或进行实时视频推荐。
• 音频检索系统：快速检索海量演讲、音乐、音效等音频数据，并返回相似音频。
• 生物化学分子式检索系统：超高速检索相似化学分子结构、超结构、子结构。
• 推荐系统：根据用户行为及需求推荐相关信息或商品。
• 智能问答机器人：交互式智能问答机器人可自动为用户答疑解惑。
• DNA 序列分类系统：通过对比相似 DNA 序列，仅需几毫秒便可精确对基因进行分类。
• 文本搜索引擎：帮助用户从文本数据库中通过关键词搜索所需信息。

8. Milvus Long Term Roadmap

Milvus Project Roadmap 及时间计划：

9. 使用教程示例

9.1. text_search_engine

Milvus在自然语言处理(NLP)领域的一个主要应用是文本搜索引擎。这是一个很好的工具，可以帮助用户找到他们正在寻找的信息。它甚至可以显示难以找到的信息。文本搜索引擎将用户输入的关键字或语义与文本数据库进行比较，然后返回符合特定条件的结果。

在本教程中，您将学习如何构建文本搜索引擎。本教程使用BERT将文本转换为固定长度的向量。将Milvus作为向量数据库进行存储和向量相似性搜索。然后使用MySQL将Milvus生成的向量id映射到文本数据。

9.2 Text to Image Search Engine

本教程使用CLIP模型提取图像的特征并将其转换为向量。然后将这些图像矢量存储在Milvus向量数据库中。当用户输入查询文本时，这些文本也使用相同的ML模型CLIP转换为嵌入向量。随后，在Milvus中进行向量相似性搜索，检索与输入文本向量最相似的图像向量。

9.3. Question Answering System

本教程讲如何构建一个QA系统：该系统可以将新的用户问题链接到先前存储在向量数据库中的大量答案。

要构建这样一个聊天机器人，需要准备自己的问题和相应答案数据集。将问题和答案存储在MySQL(一个关系数据库)中。然后使用自然语言处理(NLP)的机器学习(ML)模型BERT将问题转换为向量。这些问题向量在Milvus中存储和索引。

当用户输入一个新问题时，BERT模型也会将其转换为一个向量，Milvus会搜索与这个新向量最相似的问题向量。QA系统对最相似的问题返回相应的答案。

9.4. Recommender System

本教程讲如何构建一个电影推荐系统：该系统可以推荐符合用户兴趣的电影。

要构建这样一个推荐系统，首先下载一个与电影相关的数据集。本教程使用MovieLens 1M。或者你可以准备自己的数据集，其中应该包括用户对电影的评分、用户的人口统计特征和电影描述等信息。使用PaddlePaddle组合用户id和特征，并将它们转换为256维向量。以类似的方式将电影id和特征转换为矢量。

将电影向量存储在Milvus中，并使用用户向量进行相似度搜索。如果用户向量与电影向量相似，Milvus将返回电影向量及其ID作为推荐结果。然后使用存储在Redis或MySQL中的电影向量ID查询电影信息。