多租户研究分析

最新推荐文章于 2024-10-05 14:16:38 发布

品茗听雪抚琴

最新推荐文章于 2024-10-05 14:16:38 发布

阅读量654

点赞数 1

文章标签：数据库

本文链接：https://blog.csdn.net/xiuling216/article/details/130426895

版权

本篇章内容为个人研究分析多租户内容，多数为网上学习总结而来，可能比较浅显。
作为个人成长学习使用，同时希望对刷到的朋友有所帮助，一起加油哦！

生命就像一朵花，要拼尽全力绽放，芳香四溢，在风中舞蹈！

多租户历史

多租户技术源于1960年代，许多公司为了要使用更多的运算资源，向持有大型主机（Mainframe）的供应商租用一部分的运算资源，而这些用户经常会用到相同的应用程序，当时会以用户在登录系统时输入的数据来决定用户的帐户ID，基于这个ID，Mainframe的供应商即可利用此ID来计算运算的资源使用量，包含CPU，存储器与软盘或磁带等，这个作法也被SAP公司用在其R/1到R/3的产品线。

到了1990年代，应用程序服务提供者服务（application service provider）模式出现，它的作法与运作模式与租用大型主机时相同，不过租用的资源是在软件上，除了操作系统以外也包含了其上的应用程序。

在虚拟化（virtualization）技术的成熟与应用性的扩张之下，多租户技术可以驾驭虚拟化的平台，更强化在用户应用程序与数据之间的隔离，让多租户技术能更加发挥它的特色。

数据库多租户是云计算时代发展出来的一种新型数据库模式。

概念

租户

数据库多租户中的“租户”一般指拥有独立数据空间的用户或客户。

在多租户技术中，租户（tenant）是指使用系统或电脑运算资源的客户。

多租户

多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。

多租户是在同一台服务器、同一个系统或应用程序中支持多个租户，将租户数据相互隔离，将服务器资源在不同租户之间进行分配。在一个多租户数据库系统中，不同的租户可以访问并使用同一个的数据库，但它们只能访问或操作属于自己的数据，而不能访问或操作其他租户的数据。

多租户架构也被称为单实例架构（Single Instance）。

与多租户相对应的是单租户。

举例解释：

小红、小明、小刚三人大学毕业后同租了一套三室两厅的房子，三人各占一间独立卧室，每间房各配一把钥匙，从而保证每个人都有自己的独立私密空间，如果别人要进入，必须通过权限验证（也就是配套的开门钥匙）才行，但厨房、餐厅、客厅这些资源是共用的。

这个三室一厅就是数据库，这里的小红、小明、小刚就是多租户，独立卧室就是数据隔离的独有数据空间，共用的资源（厨房、餐厅、客厅）就是多租户环境下的硬件、系统和应用程序、组件。

数据库可存储来自多个独立租户的数据（即房子拥有三间不同的房间），然后通过使用保护数据隐私的机制来逻辑隔离不同租户之间的数据（即每个房间都有配套的钥匙来保证安全隔离）。因此多租户架构也被称为单实例架构（Single Instance）。

单租户

单租户架构通常会为每个客户提供单独的软件和服务器资源。

客户企业能够自主控制系统,但企业往往需要投入比多租户架构更多的精力和资源来维护和升级。

单租户架构如同本地化部署方案一样,升级流程不仅成本高昂,还会耗费大量资源。此外,单租户部署对结构要求严苛,导致只有部分架构可以升级,不利于长期发展。

单租户模式下，不同客户之间的应用软件和数据一般通过硬件来进行隔离，因此单租户模式被广泛应用在客户需要支持定制化的应用场景。

举例解释：

如果多租户是多个人租一套房子，每个人拥有一个房间，那么单租户就是一个人租一套房子，无须与其他人共享客厅、餐厅、厨房等资源。单租户数据库架构中，每个客户都会有独立的软件和硬件环境支撑系统运行，数据库仅存储来自一个租户的数据，因此单租户模式通常也被称为多实例架构(Multiple Instance)。

多租户解决的问题

百度百科解释多租户技术：如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。

在数据库中进一步解释：如何在同一套服务器、系统、数据库下支持多个用户或客户的数据隔离和访问控制，让每个客户拥有自己的独立的数据空间。

功能价值

对于数据库提供商：

节约成本：由于不需要为每个客户创建单独的数据库实例，减少硬件和资源的需求，因此可以降低硬件成本、人力成本。
增加灵活性：采用多租户策略将应用程序集中管理，所以可以更加轻松地添加或删除新的客户，降低维护和管理数据库复杂性。
提高效率：多租户模型可以简化部署流程，使得客户可以更快速地开始使用数据库服务，从而提高了交付速度和响应时间。
盈利：多租户模型还可以为厂家提供新的盈利机会，例如以基于租户的收费模式来提供不同的定价方案。

对于客户：

节约成本：根据用户的需要来灵活地扩展和缩减资源池。使用提供商的多租户服务，可以在需要时获得额外容量，而在不需要时则无需付费。同时也避免了数据冗余问题。
提高安全性：多租户会由专家提供持续的审查和安全保障工作,这些专家往往对新型攻击方式和漏洞保持高度警惕。
增加灵活性：如果选择自行购置硬件和软件，那么在需求旺盛时可能会难以满足需求，而在需求疲软时则可能会闲置不用。
提高效率：通过在单一数据库上托管多个客户，系统管理员可以精简数据库架构，并且可以更便捷地进行备份、恢复、部署以及维护工作。

使用场景

通常是数据库在云上部署，也支持在本地服务器或私有数据中心等地方进行部署。多租户数据库天然地适应云服务。在云服务中通过多租户可以向不同的多个客户提供数据库服务，并且各客户间的数据保证相互隔离。

一般有如下使用场景：

云数据库：多租户模式可以使得一台物理服务器上托管多个客户数据，实现资源共享，提高硬件利用率和降低成本。
SaaS应用程序：软件即服务（SaaS）模式需要支持在单个应用程序中为许多不相关的用户提供服务。多租户模式能够隔离不同客户的数据，确保每个客户的数据独立安全，且不会被其他用户所访问。
大型企业内部数据分权限访问：多租户可以在大型企业内部实现业务、团队、系统间数据的分权限访问，保证数据的安全性。
IaaS/PaaS：在互联网基础设施或平台服务中，必须同时支持多个客户/租户。多租户模式可帮助提供一致的集成环境，并为客户提供更灵活的部署和管理控制。
B2B电子商务电商平台：由于购方和销方数量庞大，因此需要实现多租户模式来对数据进行划分和隔离，以确保数据的完整性和安全性。

实现方式

方案简介

在数据库上存在三种主要的方案，分别是：

1.DB隔离

即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好。

优点：

隔离性最高，为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；

如果出现故障，恢复数据比较简单。

在大租户场景下非常适用。

缺点：

增大了数据库的安装数量，元数据较多，随之带来数据库维护成本和存储成本的增加。

这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。

2.表隔离

即多个或所有租户共享一个DB，但一个Tenant一个Schema。

优点：

表隔离模式，在元数据上总量比DB隔离方式会少。

为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；

每个数据库可以支持更多的租户数量。

缺点：

租户迁移、备份与恢复需要制定到具体表，自动化代码需要随着业务变化进行修改，运维成本偏高。

如果需要跨租户统计数据，存在一定困难。

3.行隔离

即租户共享同一个DB、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。

优点：

三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。

缺点：

隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；尤其是当多个大租户一起向同一个类业务写入/读取数据时，存在一定资源争用，同时数据迁移也需要带相应的租户ID。共享性越高，对技术的要求越高。

数据备份和恢复最困难，需要逐表逐条备份和还原。

如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。

BigInsights多租户方案

BigInsights多租户支持以上三种方案

实现BigInsights 多租户隔离，可使用以下几种方法：

使用VPC：为每个租户创建单独的VPC（Virtual Private Cloud，即虚拟私有云），将租户数据和网络隔离起来。这样可以确保每个租户的数据在物理上是隔离的。在实际使用中可以将Docker与VPC结合起来，提供多租户解决方案。
使用角色和权限模型：通过为每个租户分配自己的角色和权限，可以控制他们可以访问的数据和操作。这样可以保证每个租户只能访问其自己的数据，并且不能干扰其他租户的操作。
使用多个命名空间：将不同租户的数据存储在各自的命名空间中。这样可以使不同租户之间的数据相互隔离，避免数据混乱。
使用表或行隔离：在表或行级别上进行隔离，这意味着每个租户只能访问其自己的或和行。这种方法需要对数据结构进行设计，以确保正确地区分不同租户的数据。

方案架构

1. BigInsights DB隔离

以下介绍BigInsights使用docker来实现多租户DB隔离的架构（单集群3节点部署情况）：

2. BigInsights 表隔离、行隔离

（单集群3节点部署情况）

BigInsights 表隔离实现：

使用命名空间(namespace)来隔离表，命名空间用于将对象组织到逻辑组中，不同命名空间中的对象互不干扰，可以实现对租户之间的数据隔离。

对于每个租户，可以创建一个独立的命名空间，并在命名空间中创建相关的表、索引和视图等数据库对象。这样，每个租户都可以独立地管理和访问自己的数据而无需担心与其他租户之间的数据冲突。

BigInsights 行隔离实现：

使用Row Level Security（RLS）功能来实现租户行隔离。所有资源都运行在同一个数据库上，共享同一个模式。但由于行级安全 (RLS)，从安全的角度来看仍然是孤立的，并可以做到对于租户应用程序透明。

通过定义安全策略来管理访问控制，系统管理员可以为每个租户创建相应的行级别过滤器，以便只有经过身份验证和授权的用户才能查看和修改其特定租户所拥有的数据，保证了租户数据在逻辑上的隔离性。

整体思路是：

创建不同的用户；
创建带有”租户_id“的表：通过附加列“tenant_id”确保数据的隔离，然后从“rls.tenant_id”会话变量中添加一个默认值，并将“tenant_id”列添加到主键,并在所有索引列列表的前面。
定义行级安全性RLS;
租户配置设置

涉及功能点

租户管理：提供租户管理机制，管理员可以创建、更新和删除租户，并且可以为每个租户分配资源和权限，以保护数据的安全性和隔离性。
数据隔离: 能够确保不同租户之间的数据完全独立，不会相互干扰。在读取或写入数据时，只有拥有相关权限的租户才有访问的权限。
自动备份和恢复：支持自动备份和恢复策略，以管理多个不同租户的数据备份和恢复，从而简化管理员的工作并提高数据安全性。
连接管理：提供租户集群节点的连接数的限制，从而限制连接消耗资源，以防止时空的连接行为压倒部署资源。
工作负载控制：当刷新或压缩无法跟上传入的写速率时，可以通过拒绝部分或全部写请求来减慢传入的写请求。防止耗尽磁盘空间或读性能显著降低。

案例

案例1：

比如在 SaaS（Software as a Service）模型下，服务提供商需要为不同客户提供独立的资源和环境，确保每个客户的数据都得到适当的隔离，这种情况可以使用数据库的多租户技术来实现。

案例2：

比如大型企业有时需要在本地环境中提供多个部门之间的共享数据库，但是每个部门间的数据需要相互隔离。在这种情况下，由于整个企业拥有一个大的数据库，因此可以节省硬件成本，同时还能够保证数据访问、隔离和安全性。

竞争情况

TiDB

支持多租户。但官方文档未找到具体方案。

chatGPT查到的TiDB多租户支持通过以下两种方式实现：

基于TiDB的“Schema”进行隔离：每个租户采用独立的Schema，可以单独创建、管理和控制。TiDB支持在不同的Schema下创建同名的表，即使是同一个租户也需要执行完整的限权流程才能访问另一个Schema下的数据。
基于TiDB Operator的Namespace隔离：使用Kubernetes平台部署TiDB Operator后，每个租户可以被分配到特定的Namespace中，并将数据库的资源对象（如Pod、Service等）也分配到相应的Namespace中。通过这种方式，每个租户可以像拥有自己的独立数据库一样对其进行管理和控制，安全性和运维效率得到了极大的提高。

Oceanbase

支持多租户。

在 MySQL 租户中新建账号，可以将账号关联多个数据库。在 Oracle 租户中新建账号，该账号只有其对应 Schema 的权限。

用户租户支持服务能力水平扩展到多台机器上，支持动态扩容和缩容，内部会根据用户的配置自动创建和删除日志流。用户租户的数据有更强的数据保护和可用性要求，支持跨集群物理同步和物理备份恢复，典型数据包括：Schema 数据、用户表数据及事务数据等。

支持资源配置：CPU、内存、存储空间和 IOPS

GaussDB

支持多租户。

角色划分：每个租户都被赋予独立的角色，主要由超级管理员创建并授权。租户可以拥有一个或多个角色，每个角色包含一组权限和方法。这些权限和方法仅限于租户所拥有的库和表空间，因此实现了在逻辑上的数据隔离。

数据隔离：GaussDB还支持在不同的库和表空间中存储各自的数据，确保每个租户的数据相互独立，互不影响。每个租户拥有的库和表空间都是相互隔离的，可以根据需要创建、修改和删除多个库和表空间。