Milvus - 从数据库到 Partition Key 实现多租户

随着 ChatGPT 等大型语言模型的普及,越来越多的开发人员开始使用 CVP(ChatGPT、向量数据库、提示)技术栈来构建自己的 SaaS 服务。在这种背景下,实现高效的多租户架构已成为开发者关注的重点。本文将介绍如何在 Milvus 上实现多租户架构,帮助开发人员为不同的租户管理数据和资源。

Milvus 是全球广泛使用的向量数据库之一,支持高效的大规模数据管理与检索。在多租户架构中,多个租户可以共享一个 Milvus 实例,但每个租户的资源和数据需要彼此隔离。通过区分数据库、集合和分区等 Milvus 对象,开发人员可以实现不同级别的数据隔离与性能优化。

一、面向数据库的多租户

从 Milvus 2.2.9 版本开始,支持创建多个数据库。在这种架构下,每个租户可以分配一个独立的数据库,实现数据隔离和性能保障。每个租户都有自己的数据库,能够自由创建集合和分区,从而独立管理和查询数据。

这种方式确保了租户之间的完全数据隔离,适合需要独立管理数据的场景,如企业内部各部门的数据隔离。但需要注意的是,如果某些租户资源闲置,资源可能会浪费,因此适用于有明确数据库使用需求的租户。

优点:

  • 数据隔离强
  • 搜索性能高

缺点:

  • 最大租户数量限制为 64
  • 可能出现资源浪费

适用场景:

  • 需要强数据隔离和搜索性能的企业或组织
  • 各部门独立管理数据的情况

二、面向集合的多租户

1. 所有租户使用一个集合

最简单的多租户实现方式是让所有租户共享一个集合,并通过为每个租户添加特定字段来区分数据。在查询时,可以使用过滤表达式来排除其他租户的数据。这种方法易于实现,但过滤操作可能会影响搜索性能。

优点:

  • 实现简单
  • 资源利用率高

缺点:

  • 数据隔离弱
  • 过滤器的性能可能成为搜索瓶颈

适用场景:

  • 数据隔离要求不高的小企业
  • 资源有限且租户数量较少的场景

2. 每个租户一个集合

另一种方法是为每个租户创建单独的集合。这样可以提供更强的数据隔离和搜索性能,尤其在需要处理大量数据时表现更优。然而,随着租户数量增加,管理多个集合的开销也随之增加。

优点:

  • 数据隔离强
  • 搜索性能高

缺点:

  • 支持的最大租户数量较少(约 10,000 个)
  • 资源调度和成本较高

适用场景:

  • 需要强数据隔离和高性能搜索的企业
  • 租户数量在 10,000 以下的中大型 SaaS 服务

三、面向分区的多租户

1. 每个租户一个分区

为每个租户分配一个分区而不是集合,可以在实现数据隔离的同时简化管理。分区是 Milvus 内部更轻量化的数据隔离单位,适用于租户数量较多的场景,尤其是资源紧张时。但需要注意,单个集合的分区数量有上限,因此不能支持太多租户。

优点:

  • 数据隔离适中
  • 搜索性能高
  • 更易管理

缺点:

  • 最大支持租户数量为 4,096
  • 需要确保集合内的租户数量不会超过分区上限

适用场景:

  • 需要高性能搜索但租户数量有限的场景
  • 中小型 SaaS 服务

2. 基于 Partition Key 的多租户

Milvus 2.2.9 引入了 Partition Key 功能,允许通过设置某个字段(如租户ID)作为 Partition Key 来实现数据自动划分。基于 Partition Key 的方法意味着租户可能会共享同一个物理分区,但逻辑上通过 Partition Key 将每个租户的数据进行隔离和管理。

在这种策略下,虽然多个租户的数据可能存储在同一分区中,Milvus 通过 Partition Key 的值来动态管理分区,并在进行搜索时,通过指定 Partition Key 过滤掉不相关的租户数据,从而在逻辑上实现数据隔离。

优点:
  • 自动分区管理:无需手动管理分区,Milvus 根据 Partition Key 动态管理。
  • 灵活性强:支持大规模租户(数百万级别),适合快速扩展的场景。
  • 搜索性能高:Milvus 根据 Partition Key 限制搜索范围,只在相关租户的数据内进行查询。
缺点:
  • 物理共享:虽然数据逻辑隔离,但多个租户共享同一物理分区,这可能不适用于对物理隔离有严格要求的场景。
  • 潜在性能瓶颈:如果单个分区内有过多租户,即使使用 Partition Key 进行过滤,性能仍可能受到影响。

适用场景:

  • 大规模 SaaS 服务:适合需要处理大量租户,且租户数量可能快速增长的应用场景。
  • 需要高效管理租户数据的 SaaS:当租户的数量达到数百万时,基于 Partition Key 的方法可以简化管理,并保持良好的性能。

四、策略对比

多租户策略 数据隔离 搜索性能 最大租户数 推荐场景
面向数据库 64 需要独立管理数据的企业或部门
一个集合适用所有租户 中等 不适用 资源有限的小企业
每个租户一个集合 10,000 以下 中大型 SaaS 服务
每个租户一个分区 4,096 中小型 SaaS 服务
基于 Partition Key 10,000,000 以上 需要快速扩展到数百万租户的 SaaS 服务

总结

选择适合的多租户策略取决于应用场景、租户数量、数据隔离需求以及搜索性能要求。对于租户数量较少、对隔离要求高的场景,面向数据库或每个租户一个集合的方案更为合适;而对于大规模、多租户场景,基于 Partition Key 的方法则能够在保持良好性能的同时轻松管理海量租户。

通过合理的多租户策略设计,开发者可以利用 Milvus 构建高效的 SaaS 服务,满足不同客户的需求。

相关推荐
JH307313 分钟前
Oracle与MySQL中CONCAT()函数的使用差异
数据库·mysql·oracle
蓝染-惣右介15 分钟前
【MyBatisPlus·最新教程】包含多个改造案例,常用注解、条件构造器、代码生成、静态工具、类型处理器、分页插件、自动填充字段
java·数据库·tomcat·mybatis
冷心笑看丽美人16 分钟前
Spring框架特性及包下载(Java EE 学习笔记04)
数据库
武子康1 小时前
Java-07 深入浅出 MyBatis - 一对多模型 SqlMapConfig 与 Mapper 详细讲解测试
java·开发语言·数据库·sql·mybatis·springboot
代码吐槽菌2 小时前
基于SSM的毕业论文管理系统【附源码】
java·开发语言·数据库·后端·ssm
路有瑶台2 小时前
MySQL数据库学习(持续更新ing)
数据库·学习·mysql
数字扫地僧2 小时前
WebLogic 版本升级的注意事项与流程
数据库
Viktor_Ye2 小时前
高效集成易快报与金蝶应付单的方案
java·前端·数据库
努力算法的小明3 小时前
SQL 复杂查询
数据库·sql
斗-匕3 小时前
MySQL 三大日志详解
数据库·mysql·oracle