Milvus简介及安装
Milvus简介
什么是Milvus
（1）Milvus是一款云原生向量数据库，它具备高可用、高性能、易拓展的特点，用于海量向量数据的实时召回。
（2）Milvus基于FAISS、Annoy、HNSW等向量搜索库构建，核心是解决稠密向量相似度检索的问题。
（3）在向量检索库的基础上，Milvus支持数据分区分片、数据持久化、增量数据摄取、标量向量混合查询、time travel 等功能，同时大幅优化了向量检索的性能，可满足任何向量检索场景的应用需求。
（4）通常，建议用户使用 Kubernetes 部署 Milvus，以获得最佳可用性和弹性。
Milvus 采用共享存储架构，存储计算完全分离，计算节点支持横向扩展。从架构上来看，Milvus 遵循数据流和控制流分离，整体分为了四个层次，分别为接入层（access layer）、协调服务（coordinator service）、执行节点（worker node）和存储层（storage）。各个层次相互独立，独立扩展和容灾。
为什么需要Milvus
随着互联网不断发展，电子邮件、论文、物联网传感数据、社交媒体照片、蛋白质分子结构等非结构化数据已经变得越来越普遍。如果想要使用计算机来处理这些数据，需要使用embedding技术将这些数据转化为向量。随后，Milvus会存储这些向量，并为其建立索引。Milvus 能够根据两个向量之间的距离来分析他们的相关性。如果两个向量十分相似，这说明向量所代表的源数据也十分相似。
Milvus 向量数据库专为向量查询与检索设计，能够为万亿级向量数据建立索引。Milvus 在底层设计上就是为了处理由各种非结构化数据转换而来的Embedding向量而生。
为什么使用Milvus
（1）高性能：性能高超，可对海量数据集进行向量相似度检索；
（2）高可用、高可靠：Milvus 支持在云上扩展，其容灾能力能够保证服务高可用；
（3）混合查询：Milvus 支持在向量相似度检索过程中进行标量字段过滤，实现混合查询；
（4）开发者友好：支持多语言、多工具的 Milvus 生态系统。
Milvus系统架构
总览
Milvus 2.0 是一款云原生向量数据库，采用存储与计算分离的架构设计，所有组件均为无状态组件，极大地增强了系统弹性和灵活性：
整个系统分为四个层次，各个层次相互独立，独立扩展和容灾：
（1）接入层（Access Layer）：它是系统的门面，由一组无状态的Proxy组成，对外提供用户连接的endpoint，负责验证客户端请求并合并返回结果。
（2）协调服务（Coordinator Service）：系统的大脑，负责分配任务给执行节点。协调服务共有四种角色，分别为 root coord、data coord、query coord 和 index coord。
（3）执行节点（Worker Node）：系统的四肢，负责完成协调服务下发的指令和proxy发起的数据操作语言（DML）命令。执行节点分为三种角色，分别为data node、query node和index node。
（4） 存储服务 （Storage）： 系统的骨骼，负责Milvus数据的持久化，分为元数据存储（meta store）、消息存储（log broker）和对象存储（object storage）三个部分。
接入层（Access Layer）
（1）接入层由一组无状态 proxy 组成，是整个系统的门面，对外提供用户连接的 endpoint。接入层负责验证客户端请求并减少返回结果；
（2）Proxy本身是无状态的，一般通过负载均衡组件（Nginx、Kubernetes Ingress、NodePort、LVS）对外提供统一的访问地址并提供服务。
（3） 由于Milvus采用大规模并行处理（MPP）架构，proxy会先对执行节点返回的中间结果进行全局聚合和后处理后，再返回至客户端。
协调服务（Coordinator Service）
（1）协调服务是系统的大脑，负责向执行节点分配任务。它承担的任务包括集群拓扑节点管理、负载均衡、时间戳生成、数据声明和数据管理等。
（2）协调服务共有四种角色：
- Root coordinator（root coord）：负责处理数据定义语言（DDL）和数据控制语言（DCL）请求。比如，创建或删除collection、partition、index等，同时负责维护中心授时服务TSO和时间窗口的推进。
- Query coordinator (query coord）：负责管理query node的拓扑结构和负载均衡以及从增长的 segment 移交切换到密封的 segment。
- Data coordinator (data coord）：负责管理data node的拓扑结构，维护数据的元信息以及触发 flush、compact 等后台数据操作。
- Index coordinator (index coord）：负责管理index node的拓扑结构，构建索引和维护索引元信息。
执行节点（Worker Node）
（1）执行节点是系统的四肢，负责完成协调服务下发的指令和 proxy 发起的数据操作语言（DML）命令。
（2）由于采取了存储计算分离，执行节点是无状态的，可以配合 Kubernetes 快速实现扩缩容和故障恢复
（3）执行节点分为三种角色：
- Query node： Query node 通过订阅消息存储（log broker）获取增量日志数据并转化为 growing segment，基于对象存储加载历史数据，提供标量 + 向量的混合查询和搜索功能。
- Data node：Data node 通过订阅消息存储获取增量日志数据，处理更改请求，并将日志数据打包存储在对象存储上实现日志快照持久化。
- Index node：Index node 负责执行索引构建任务。Index node 不需要常驻于内存，可以通过 serverless 的模式实现。
存储服务 （Storage）
存储服务是系统的骨骼，负责 Milvus 数据的持久化，分为元数据存储（meta store）、对象存储（object storage）和消息存储（log broker）三个部分。
元数据存储（meta store）
负责存储元信息的快照，如集合 schema 信息、节点状态信息、消息消费的 checkpoint 等。元信息存储需要极高的可用性、强一致和事务支持，因此etcd是这个场景下的不二选择。除此之外，etcd还承担了服务注册和健康检查的职责。
对象存储（object storage）
负责存储日志的快照文件、标量 / 向量索引文件以及查询的中间处理结果。Milvus 采用MinIO作为对象存储，另外也支持部署于AWS S3和Azure Blob这两大最广泛使用的低成本存储。但是，由于对象存储访问延迟较高，且需要按照查询计费，因此Milvus未来计划支持基于内存或 SSD 的缓存池，通过冷热分离的方式提升性能以降低成本。
消息存储（log broker）
消息存储是一套支持回放的发布订阅系统，用于持久化流式写入的数据，以及可靠的异步执行查询、事件通知和结果返回。执行节点宕机恢复时，通过回放消息存储保证增量数据的完整性。
目前，分布式版Milvus依赖Pulsar作为消息存储，单机版Milvus依赖RocksDB作为消息存储。消息存储也可以替换为Kafka、Pravega等流式存储。整个Milvus围绕日志为核心来设计，遵循日志即数据的准则，因此在 2.0 版本中没有维护物理上的表，而是通过日志持久化和日志快照来保证数据的可靠性。
日志系统作为系统的主干，承担了数据持久化和解耦的作用。通过日志的发布订阅机制，Milvus将系统的读、写组件解耦。一个极致简化的模型如上图所示，整个系统主要由两个角色构成，分别是消息存储（log broker）（负责维护”日志序列 “）与“日志订阅者”。其中的“日志序列” 记录了所有改变库表状态的操作，“日志订阅者”通过订阅日志序列更新本地数据，以只读副本的方式提供服务。 发布订阅机制还为系统在变更数据捕获（CDC）和全面的分布式部署方面的可扩展性提供了空间。
Milvus主要的组件
Milvus支持两种部署模式，单机模式（standalone）和分布式模式（cluster）。两种模式具备完全相同的能力，用户可根据数据规模、访问量等因素选择适合自己的模式。Standalone模式部署的Milvus暂时不支持在线升级为cluster模式。
单机模式
单机版的Milvus主要有三个组件，分别是Milvus、etcd和MinIO：
- Milvus负责提供系统的核心功能；
- etcd是元数据引擎，用于管理Milvus内部组件的元数据访问和存储，例如：proxy、index node等；
- MinIO是存储引擎，负责维护Milvus的数据持久化。
分布式模式
（1）分布式版的Milvus主要有八个微服务组件和三个第三方依赖组成，每个微服务组件可使用 Kubernetes 独立部署。
（2）八个微服务组件分别是：Root coord、Proxy、Query coord、Query node、Index coord、 Index node、Data coord和Data node。
（3）三个第三方依赖，分别是etcd、MinIO和Pulsar：
- etcd 负责存储集群中各组件的元数据信息；
- MinIO 负责处理集群中大型文件的数据持久化，如索引文件和全二进制日志文件；
- Pulsar 负责管理近期更改操作的日志，输出流式日志及提供日志订阅服务。
Milvus的应用场景
开发者可以使用Milvus搭建符合自己场景需求的向量相似度检索系统。Milvus的使用场景如下：
（1） 图片检索系统：以图搜图，从海量数据库中即时返回与上传图片最相似的图片。
（2）视频检索系统：将视频关键帧转化为向量并插入 Milvus，便可检索相似视频，或进行实时视频推荐。
（3）音频检索系统：快速检索海量演讲、音乐、音效等音频数据，并返回相似音频。
（4） 分子式检索系统：超高速检索相似化学分子结构、超结构、子结构。
（5） 推荐系统：根据用户行为及需求推荐相关信息或商品。
（6）智能问答机器人：交互式智能问答机器人可自动为用户答疑解惑。
（7）DNA序列分类系统：通过对比相似 DNA 序列，仅需几毫秒便可精确对基因进行分类。
（8） 文本搜索引擎：帮助用户从文本数据库中通过关键词搜索所需信息。
Milvus支持的搜索类型
Milvus支持多种类型的搜索功能，如下：
（1）ANN搜索：查找最接近查询向量的前K个向量；
（2）过滤搜索：在指定的过滤条件下执行 ANN 搜索；
（3）范围搜索：查找查询向量指定半径范围内的向量；
（4）混合搜索：基于多个向量场进行 ANN 搜索；
（5）全文搜索：基于 BM25 的全文搜索；
（6）Rerankers：根据附加标准或辅助算法调整搜索结果顺序，完善初始 ANN 搜索结果；
（7）获取：根据主键检索数据；
（8）查询：使用特定表达式检索数据。
Milvus与Pinecone的对比
以下是Milvus与Pinecone的整体对比：
虽然两者作为向量数据库功能相似，但是在特定领域的术语不同：
当然两者在能力方面也存在不同：
- 部署模式：Milvus提供多种部署选项，包括本地部署、Docker、Kubernetes on-premises、云SaaS和面向企业的自带云（BYOC），而Pinecone仅限于SaaS部署。
- 嵌入功能：Milvus 支持额外的嵌入库，可直接使用嵌入模型将源数据转换为向量。
- 数据类型：与 Pinecone 相比，Milvus 支持更广泛的数据类型，包括数组和 JSON。Pinecone 只支持以字符串、数字、布尔值或字符串列表为值的扁平元数据结构，而 Milvus 可以在一个 JSON 字段内处理任何 JSON 对象，包括嵌套结构。Pinecone 限制每个向量的元数据大小为 40KB。
- 度量和索引类型：Milvus 支持多种度量和索引类型，以适应各种使用情况，而 Pinecone 的选择较为有限。虽然在 Milvus 中必须为向量建立索引，但也提供了 AUTO_INDEX 选项来简化配置过程。
- Schema 设计：Milvus 为模式设计提供了灵活的
create_collection模式，包括快速设置动态模式，以获得类似 Pinecone 的无模式体验，以及自定义设置预定义模式字段和索引，类似关系数据库管理系统（RDBMS）。 - 多向量字段：Milvus 支持在单个 Collections 中存储多个向量字段，这些字段可以是稀疏的，也可以是密集的，维度也可能不同。Pinecone 不提供类似功能。
- 工具：Milvus 为数据库管理和利用提供了更广泛的工具选择，如 Attu、Birdwatcher、Backup、CLI、CDC 以及 Spark 和 Kafka 连接器。
Milvus基本概念
非结构化数据
（1）非结构化数据指的是数据结构不规则，没有统一的预定义数据模型，不方便用数据库二维逻辑表来表现的数据。
（2）非结构化数据包括图片、视频、音频、自然语言等，占所有数据总量的 80%。
（3）非结构化数据的处理可以通过各种人工智能（AI）或机器学习（ML）模型转化为向量数据后进行处理。
特征向量
（1）向量又称为embedding vector，是指由embedding技术从离散变量（如图片、视频、音频、自然语言等各种非结构化数据）转变而来的连续向量。
（2）在数学表示上，向量是一个由浮点数或者二值型数据组成的 n 维数组。
（3）通过现代的向量转化技术，比如各种人工智能（AI）或者机器学习（ML）模型，可以将非结构化数据抽象为 n 维特征向量空间的向量。这样就可以采用最近邻算法（ANN）计算非结构化数据之间的相似度。
向量相似度检索
（1）相似度检索是指将目标对象与数据库中数据进行比对，并召回最相似的结果。同理，向量相似度检索返回的是最相似的向量数据。
（2）近似最近邻搜索（ANN）算法能够计算向量之间的距离，从而提升向量相似度检索的速度。如果两条向量十分相似，这就意味着他们所代表的源数据也十分相似。
Collection
包含一组 entity，可以等价于关系型数据库系统（RDBMS）中的表。
Entity
（1）包含一组field。field与实际对象相对应。field可以是代表对象属性的结构化数据，也可以是代表对象特征的向量。primary key用于指代一个entity的唯一值。
（2）开发者可以自定义primary key，否则Milvus将会自动生成primary key。
（3）请注意，目前Milvus不支持primary key去重，因此有可能在一个collection内出现primary key相同的entity。
Field
（1）Entity 的组成部分。Field 可以是结构化数据，例如数字和字符串，也可以是向量。
（2）Milvus 2.0 现已支持标量字段过滤。并且，Milvus 2.0 在一个集合中只支持一个主键字段。
Milvus与关系数据库对比
Milvus 与关系型数据库的对应关系如下：
Partition
分区（Partition）是集合（Collection）的一个分区。Milvus 支持将收集数据划分为物理存储上的多个部分。这个过程称为分区，每个分区可以包含多个段。
Segment
Milvus在数据插入时，通过合并数据自动创建的数据文件。一个collection可以包含多个segment。一个segment可以包含多个entity。在搜索中，Milvus会搜索每个segment，并返回合并后的结果。
Sharding
（1）Shard 是指将数据写入操作分散到不同节点上，使 Milvus 能充分利用集群的并行计算能力进行写入。默认情况下，单个 Collection 包含 2 个分片（Shard）。
（2）目前 Milvus 采用基于主键哈希的分片方式，未来将支持随机分片、自定义分片等更加灵活的分片方式。
（3）分区的意义在于通过划定分区减少数据读取，而分片的意义在于多台机器上并行写入操作。
索引
（1）索引基于原始数据构建，可以提高对 collection 数据搜索的速度。
（2）Milvus 支持多种索引类型。为提高查询性能，开发者可以为每个向量字段指定一种索引类型。目前，一个向量字段仅支持一种索引类型。切换索引类型时，Milvus 自动删除之前的索引。
（3）相似性搜索引擎的工作原理：将输入的对象与数据库中的对象进行比较，找出与输入最相似的对象。
（4）索引是有效组织数据的过程，极大地加速了对大型数据集的查询，在相似性搜索的实现中起着重要作用。对一个大规模向量数据集创建索引后，查询可以被路由到最有可能包含与输入查询相似的向量的集群或数据子集。在实践中，这意味着要牺牲一定程度的准确性来加快对真正的大规模向量数据集的查询。
PChannel
PChannel 表示物理信道。每个 PChannel 对应一个日志存储主题。默认情况下，将分配一组 256 个 PChannels 来存储记录 Milvus 集群启动时数据插入、删除和更新的日志。
VChannel
VChannel 表示逻辑通道。每个集合将分配一组 VChannels，用于记录数据的插入、删除和更新。VChannels 在逻辑上是分开的，但在物理上共享资源。
安装Docker
关于Docker的具体安装，这里不详细介绍，只给出docker engine的可用镜像地址：
1 | { |
安装Milvus
点击 这里 选择对应的版本，或者直接点击 链接 下载2.6.4的版本：
下载完成后，修改yaml文件名称为docker-compose.yml。新建一个目录，名字可以为milvus，然后cmd到该目录中，执行如下命令：
1 | docker-compose up -d |
由于在下载镜像，所以需要一些时间，出现下面的信息，说明下载完成：
然后执行如下命令来查看是否启动成功：
1 | docker compose ps |
三个都是up，则说明启动成功：
在Docker-DeskTop中也能查看启动情况：
这样我们就安装完Milvus，但是这样不直观，需要可视化工具来管理向量，下面就开始安装Attu这一工具。
安装Attu
第一步，使用ipconfig命令查看一下当前IP地址：
笔者使用的是WLAN，所以只需看这个适配器的IPV4地址，如果你开了虚拟机，那么VMnet1和VMnet8也是不用管的。
第二步，使用如下命令来安装Attu：
1 | docker run --name attu-261 -p 3000:3000 -e MILVUS_URL=192.168.43.212:19530 zilliz/attu:v2.6.1 |
其中表示将容器的3000端口转发到宿主机的3000端口，而其中的MILVUS_URL则是之前的本地IP地址，19530是向量数据库的端口，容器名称为attu-261，出现下面的http://172.17.0.2:3000表示启动成功：
访问Attu
打开浏览器，访问如下地址：
1 | http://localhost:3000 |
页面出现如下信息：
点击连接，即可登录到控制台：
