云原生向量数据库Milvus(一)-简述、系统架构及应用场景(上)

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: Milvus 是一款云原生向量数据库,它具备高可用、高性能、易拓展的特点,用于海量向量数据的实时召回。

什么是 Milvus

Milvus 是一款云原生向量数据库,它具备高可用、高性能、易拓展的特点,用于海量向量数据的实时召回。

Milvus 基于 FAISS、Annoy、HNSW 等向量搜索库构建,核心是解决稠密向量相似度检索的问题。在向量检索库的基础上,Milvus 支持数据分区分片、数据持久化、增量数据摄取、标量向量混合查询、time travel 等功能,同时大幅优化了向量检索的性能,可满足任何向量检索场景的应用需求。通常,建议用户使用 Kubernetes 部署 Milvus,以获得最佳可用性和弹性。

Milvus 采用共享存储架构,存储计算完全分离,计算节点支持横向扩展。从架构上来看,Milvus 遵循数据流和控制流分离,整体分为了四个层次,分别为接入层(access layer)、协调服务(coordinator service)、执行节点(worker node)和存储层(storage)。各个层次相互独立,独立扩展和容灾。

网络异常,图片无法展示
|


为什么需要 Milvus

随着互联网不断发展,电子邮件、论文、物联网传感数据、社交媒体照片、蛋白质分子结构等非结构化数据已经变得越来越普遍。如果想要使用计算机来处理这些数据,需要使用 embedding 技术将这些数据转化为向量。随后,Milvus 会存储这些向量,并为其建立索引。Milvus 能够根据两个向量之间的距离来分析他们的相关性。如果两个向量十分相似,这说明向量所代表的源数据也十分相似。

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

与现有的主要用作处理结构化数据的关系型数据库不同,Milvus 在底层设计上就是为了处理由各种非结构化数据转换而来的 Embedding 向量而生。


为什么选择使用 Milvus

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


Milvus基本概念

非结构化数据

非结构化数据指的是数据结构不规则,没有统一的预定义数据模型,不方便用数据库二维逻辑表来表现的数据。

非结构化数据包括图片、视频、音频、自然语言等,占所有数据总量的 80%。

非结构化数据的处理可以通过各种人工智能(AI)或机器学习(ML)模型转化为向量数据后进行处理。


特征向量

向量又称为 embedding vector,是指由 embedding 技术从离散变量(如图片、视频、音频、自然语言等各种非结构化数据)转变而来的连续向量。

在数学表示上,向量是一个由浮点数或者二值型数据组成的 n 维数组。

通过现代的向量转化技术,比如各种人工智能(AI)或者机器学习(ML)模型,可以将非结构化数据抽象为 n 维特征向量空间的向量。这样就可以采用最近邻算法(ANN)计算非结构化数据之间的相似度。


向量相似度检索

相似度检索是指将目标对象与数据库中数据进行比对,并召回最相似的结果。同理,向量相似度检索返回的是最相似的向量数据。

近似最近邻搜索(ANN)算法能够计算向量之间的距离,从而提升向量相似度检索的速度。如果两条向量十分相似,这就意味着他们所代表的源数据也十分相似。


Collection-集合

包含一组 entity,可以等价于关系型数据库系统(RDBMS)中的表。


Entity-实体

包含一组 field。field 与实际对象相对应。field 可以是代表对象属性的结构化数据,也可以是代表对象特征的向量。primary key 是用于指代一个 entity 的唯一值。

注意: 你可以自定义 primary key,否则 Milvus 将会自动生成 primary key。请注意,目前 Milvus 不支持 primary key 去重,因此有可能在一个 collection 内出现 primary key 相同的 entity。


Field-字段

Entity 的组成部分。Field 可以是结构化数据,例如数字和字符串,也可以是向量。

注意:Milvus 2.0 现已支持标量字段过滤。并且,Milvus 2.0在一个集合中只支持一个主键字段。

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

Milvus向量数据库 关系型数据库
Collection
Entity
Field 表字段

Partition-分区

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


Segment-段

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


Sharding-分片

Shard 是指将数据写入操作分散到不同节点上,使 Milvus 能充分利用集群的并行计算能力进行写入。默认情况下,单个 Collection 包含 2 个分片(Shard)。目前 Milvus 采用基于主键哈希的分片方式,未来将支持随机分片、自定义分片等更加灵活的分片方式。

注意: 分区的意义在于通过划定分区减少数据读取,而分片的意义在于多台机器上并行写入操作。


向量索引

向量索引基于原始数据构建,可以提高对 collection 数据搜索的速度。Milvus 支持多种索引类型。为提高查询性能,你可以为每个向量字段指定一种索引类型。目前,一个向量字段仅支持一种索引类型。切换索引类型时,Milvus 自动删除之前的索引。

相似性搜索引擎的工作原理是将输入的对象与数据库中的对象进行比较,找出与输入最相似的对象。索引是有效组织数据的过程,极大地加速了对大型数据集的查询,在相似性搜索的实现中起着重要作用。对一个大规模向量数据集创建索引后,查询可以被路由到最有可能包含与输入查询相似的向量的集群或数据子集。在实践中,这意味着要牺牲一定程度的准确性来加快对真正的大规模向量数据集的查询。


PChannel

PChannel 表示物理通道。每个 PChannel 对应一个日志存储主题。默认情况下,将分配一组 256 个 PChannels 来存储记录 Milvus 集群启动时数据插入、删除和更新的日志。


VChannel

VChannel 表示逻辑通道(虚拟通道)。每个集合将分配一组 VChannels,用于记录数据的插入、删除和更新。VChannels 在逻辑上是分开的,但在物理上共享资源。


Binlog

binlog 是一个二进制日志,或者是一个更小的段单位,记录和处理 Milvus 向量数据库中数据的更新和更改。 一个段的数据保存在多个二进制日志中。 Milvus 中的 binlog 分为三种:InsertBinlog、DeleteBinlog 和 DDLBinlog。


日志代理(Log broker)

日志代理是一个支持回放的发布订阅系统。它负责流数据持久化、可靠异步查询的执行、事件通知和查询结果的返回。当工作节点从系统崩溃中恢复时,它还确保增量数据的完整性。


日志订阅者

日志订阅方通过订阅日志序列来更新本地数据,并以只读副本的形式提供服务。


日志序列(Log sequence)

日志序列记录了在 Milvus 中更改集合状态的所有操作。


正则化

正则化是指转换嵌入(向量)以使其范数等于 1 的过程。 如果使用内积 (IP) 来计算embeddings相似度,则必须对所有embeddings进行正则化。 正则化后,内积等于余弦相似度。


Milvus 系统架构

Milvus 2.0 是一款云原生向量数据库,采用存储与计算分离的架构设计,所有组件均为无状态组件,极大地增强了系统弹性和灵活性。

网络异常,图片无法展示
|


整个系统分为四个层次:

  • 接入层(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)三个部分。

各个层次相互独立,独立扩展和容灾。


接入层

接入层由一组无状态 proxy 组成,是整个系统的门面,对外提供用户连接的 endpoint。接入层负责验证客户端请求并减少返回结果。

  • Proxy 本身是无状态的,一般通过负载均衡组件(Nginx、Kubernetes Ingress、NodePort、LVS)对外提供统一的访问地址并提供服务。
  • 由于 Milvus 采用大规模并行处理(MPP)架构,proxy 会先对执行节点返回的中间结果进行全局聚合和后处理后,再返回至客户端。



相关实践学习
使用CLup和iSCSI共享盘快速体验PolarDB for PostgtreSQL
在Clup云管控平台中快速体验创建与管理在iSCSI共享盘上的PolarDB for PostgtreSQL。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
相关文章
|
17小时前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第14天】 随着企业加速其数字化转型的步伐,云原生架构成为了实现敏捷性、可扩展性和高效运营的重要推动力。本文将探讨云原生技术的核心组件,包括容器化、微服务和持续集成/持续部署(CI/CD),并分析这些技术如何助力企业构建灵活且高效的IT环境。此外,文章还将讨论云原生安全策略的重要性及其对企业数据保护的影响。
|
1天前
|
算法 数据库 Docker
大模型必备向量数据库-Milvus的安装过程
大模型必备向量数据库-Milvus的安装过程
4 0
|
1天前
|
Cloud Native Devops 持续交付
构筑未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第13天】 随着企业加速其数字化转型的步伐,云原生架构逐渐成为实现敏捷性、可扩展性和资源优化的关键技术。本文探讨了云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及DevOps实践,并分析了这些技术如何协同工作,以支持企业在不断变化的市场环境中快速适应和创新。通过深入剖析云原生技术的优势和挑战,本文为读者提供了一个关于企业如何在云平台上构建、部署和管理复杂应用程序的全面视角。
|
1天前
|
敏捷开发 Cloud Native 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第13天】 随着企业加速其数字化进程,云原生架构已经成为推动创新和维持市场竞争力的核心要素。本文将探讨云原生技术的基本原理、它如何促进敏捷开发,以及它在实现可扩展性、弹性和资源优化方面的优势。通过分析案例研究和行业趋势,我们将深入理解云原生架构是如何成为企业转型不可或缺的技术支撑。
|
1天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构的演进之路
【5月更文挑战第13天】 在数字化转型的浪潮中,企业与组织正迅速采用云原生技术以提升其业务敏捷性、可扩展性和运营效率。本文深入探讨了云原生架构的关键组成部分,包括容器化、微服务、持续集成与持续部署(CI/CD)、以及声明式API,并分析了这些技术如何共同塑造着云平台的未来。同时,文中将剖析云原生安全挑战并提出相应的解决策略,为构建一个更加可靠、安全的云环境提供指导。
|
1天前
|
Cloud Native OLAP OLTP
云原生一体化数据库技术是一个具有潜力的领域
【5月更文挑战第13天】在业务处理分析一体化趋势下,开发者需权衡OLTP和OLAP数据库的选型。一体化数据库如阿里云瑶池通过Zero-ETL实现数据自动搬迁,简化流程,支持高并发事务和复杂分析。但也带来定制化开发、性能优化及管理维护的挑战。随着集中式与分布式数据库边界模糊,开发者需更深入理解各种架构特点,灵活选择以适应业务需求。云原生一体化数据库在处理大规模数据和高并发场景中展现优势,但选择时需综合考虑技术成熟度、成本和维护因素。总的来说,一体化数据库技术是未来发展的重要方向,但也需要谨慎评估和决策。
10 3
|
2天前
|
Cloud Native 持续交付 开发者
探索云原生架构的未来之路
【5月更文挑战第12天】 随着企业数字化转型的深入,传统的IT架构日益显得笨重且难以适应快速变化的市场需求。云原生技术以其灵活、可扩展的特性应运而生,被视为推动现代应用开发和运维模式变革的重要力量。本文将探讨云原生架构的关键组件,分析其优势,并预测未来发展趋势。
|
2天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【5月更文挑战第12天】 随着企业加速其数字化进程,云原生架构已成为实现敏捷性、可扩展性和资源优化的关键技术。本文深入探讨了如何通过采纳云原生原则和模式,企业能够有效地应对不断变化的市场需求,同时确保系统的可靠性和安全性。我们将分析云原生的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及无服务器计算,并展示它们如何共同促进业务和技术的同步演进。
|
2天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第12天】 随着数字化转型的浪潮不断冲击传统IT架构,企业亟需灵活、高效且可扩展的技术解决方案以保持竞争力。云原生技术作为一种新兴的系统构建方式,以其独特的弹性、微服务和持续交付等特性,成为推动企业快速响应市场变化的关键因素。本文将深入探讨云原生架构的核心组件,分析其如何促进企业的敏捷性,以及在实施过程中可能遇到的挑战和解决策略,为企业采纳云原生技术提供参考。
|
3天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第11天】 随着数字化转型的深入,企业对技术的敏捷性、可扩展性和成本效益提出了更高的要求。云原生架构作为一种新兴的设计理念和实践方法,正逐渐成为推动企业技术革新的关键力量。本文将深入探讨云原生架构的核心组件,包括容器化、微服务、持续集成/持续交付(CI/CD)以及DevOps文化,并分析它们如何共同作用于企业的IT基础设施,实现灵活、高效的运营模式。同时,我们也将识别在采纳云原生技术时面临的主要挑战,并提出相应的解决策略,以帮助企业顺利过渡到云原生时代。