当前位置: 首页 > news >正文

Milvus 资源调度系统的核心部分:「查询节点」「资源组」「数据库」

Milvus 的资源管理分为三层:查询节点、资源组和 数据库。

查询节点:处理查询任务的组件。它在物理机或容器(如 Kubernetes 中的 pod)上运行。

资源组:查询节点的集合,充当逻辑组件(数据库和 Collections)与物理资源之间的桥梁。您可以将一个或多个数据库或集合分配给一个资源组。

下面我将详细解释这三个概念。

🧱 总体图(打个比方)

你可以把整个 Milvus 系统想象成一个「大型图书馆系统」,里头有:

  • 很多“读者”(查询请求)
  • 很多“图书馆分馆”(数据库)
  • 每个分馆有很多“图书柜”(Collection)
  • 后台有一群“图书管理员”(查询节点)在负责查找图书
  • 管理员是按组编排的,比如“第一组负责科技馆”,“第二组负责历史馆”,这就是“资源组”

🧩 一层一层说清楚:


① 查询节点(QueryNode)

是什么?

  • 查询节点是 Milvus 的底层服务组件,专门负责 处理向量检索、聚类、过滤查询等任务
  • 你可以理解为“一台专门干活的工作机器”。

跑在哪里?

  • 查询节点可以跑在物理服务器上,也可以跑在 Kubernetes 的 Pod 中。
  • 一个 Milvus 系统可以有很多个查询节点(多台机器/多个 Pod)。

干嘛用?

  • 查询节点会接收用户的查询任务,比如“在 Collection A 中找相似的向量”,然后自己去磁盘/内存里找结果。
  • 查询节点是消耗 CPU、内存最多的部分,属于“干活的前线工人”。

② 资源组(Resource Group)

是什么?

  • 资源组是一组 QueryNode 的集合,是一个逻辑上的划分。
  • 它的作用是把查询节点分组,每组负责不同的任务/客户/数据库。

举例理解:

  • 假设你有 100 个 QueryNode,你可以划分成 2 个资源组:

    • rg_high_priority:专门给 VIP 租户用,响应快。
    • rg_low_priority:给普通用户用。

为什么要分资源组?

  • 为了资源隔离,比如:

    • VIP 用户不能因为普通用户太多而被拖慢
    • 某个数据库出了问题不会拖垮所有查询节点
  • 资源组就是一个调度系统:让哪些 QueryNode 服务哪些 Collection 或数据库


③ 数据库(Database)

是什么?

  • Milvus 现在支持多数据库(类似 MySQL 的多个库),每个数据库相当于一个「租户空间」。
  • 每个数据库下可以有多个 Collection,比如 vector_db1 下有 itemsusers 表。

和资源组的关系?

  • 你可以把某个数据库“绑定”到某个资源组,让它的所有 Collection 查询都由那组 QueryNode 来处理。

🧠 整体逻辑关系总结图:

              用户查询请求↓┌─────────┐│ Database│   ← 你定义的数据库,如 db1、db2└─────────┘↓┌─────────────┐│ Collection  │ ← 数据表└─────────────┘↓分配到某个资源组↓┌──────────────────┐│ Resource Group A │ ← 一组 QueryNode│  (高优先级)      │└──────────────────┘↓┌────────────────────┐│ QueryNode A1 ~ A10 │ ← 干活的机器└────────────────────┘

✅ 举个完整的例子

假设你有这样一个场景:

  • 有两个客户:阿里巴巴(VIP)和普通客户(长尾用户)
  • 阿里巴巴的数据存放在数据库 vip_customer_db
  • 普通客户数据在 normal_customer_db
  • 你想确保阿里巴巴的查询速度不受其它人影响

你可以这样做:

  1. 创建两个资源组:rg_viprg_normal
  2. 分配更多 QueryNode 给 rg_vip(比如 10 个节点),只给 rg_normal 分 4 个节点
  3. vip_customer_db 绑定到 rg_vip,把 normal_customer_db 绑定到 rg_normal

这样:

  • 阿里巴巴的查询总是在 rg_vip 中处理
  • 即使普通客户量暴增,也不会影响阿里的响应速度
  • 同时资源利用率也更合理,避免大家抢资源

🧠 再次强调区别:

名称是什么谁组成的管理对象举例
查询节点干活的机器(QueryNode)单个服务实例负责执行查询任务一个 Pod / 容器
资源组一组查询节点的集合多个 QueryNode逻辑分组、调度单位高优、低优资源组
数据库存数据的逻辑库(租户单位)多个 Collection用户管理的数据集用户A的数据库 user_db

✅ 一句话总结

数据库 是租户的数据空间,资源组 是逻辑资源划分,查询节点 是实际执行工作的工人。
它们之间是:数据库 ←→ 资源组 ←→ 查询节点 的映射链。

http://www.lqws.cn/news/528985.html

相关文章:

  • gitlab https链接转为ssh链接
  • Docker 网络——AI教你学Docker
  • Vue 2 项目中内嵌 md 文件
  • Windows 下使用 nvm 管理 Node.js 多版本 —— 完整指南
  • 动态规划之01背包问题
  • 互联网医院系统源码解析:如何实现视频问诊、电子处方等核心功能?
  • 焊接与热切割作业证用途有哪些
  • 【SpringBoot】Spring Boot + RESTful 技术实战指南
  • 数据结构进阶 - 第二章 线性表
  • 缓存与加速技术实践-MongoDB数据库应用
  • React:利用计算属性名特点更新表单值
  • Spark SQL to_json 函数介绍
  • LLM复杂记忆存储-多会话隔离案例实战
  • Flink Oracle CDC 总结
  • Spring 框架
  • Python+selenium自动化生成测试报告
  • 在一个成熟产品中,如何设计数据库架构以应对客户字段多样化,确保系统的可维护性、可扩展性和高性能。
  • 智慧城市云计算大数据中心项目设计方案
  • 技术调研:时序数据库(一)
  • ASP.NET Core Web API 实现 JWT 身份验证
  • 【人工智能与机器人研究】基于ROS的多传感器融合巡检机器人系统研究
  • Android 16系统源码_无障碍辅助(二)Android 的无障碍框架
  • 人工智能中的集成学习:从原理到实战
  • PDF Kit 使用示例(HarmonyOS)
  • 跟着AI学习C#之项目实战-电商平台 Day1
  • Web3解读:解锁去中心化网络的潜力
  • MessagesPlaceholder和多轮AI翻译助手实战
  • 【强化学习】《Reinforcement Learning: An Introduction》(第二版)概述
  • 杰理-可视化sdk-耳机灯效添加
  • Windows中使用createdump创建进程dump文件的基本用法