数据库租户能力大调研

字数 4240阅读 795评论 0赞 0

随着SaaS软件日益流行，如何为企业用户提供即统一又相互独立的服务，成为很多基础软件商的课题，因而租户能力正受到更多关注。另一方面，随着分布式数据库的流行，如何充分利用分布式环境的算力及存储资源为不同业务服务，也同样对租户能力提出的要求。本文针对常用的租户实现方法、技术路线进行说明，重点说明场景数据库的租户能力并加以对比。

1. 多租户能力概述

多租户（Multi Tenancy/Tenant）是一种软件架构，是实现如何在多用户环境下共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。与之相对应的就是单租户SaaS架构（也被称作多实例架构（Multiple Instance））。两者的区别在于，单租户是为每个客户单独创建各自的软件应用和支撑环境。后者通常被广泛引用在客户需要支持定制化的应用场合。

1).多租户业务诉求

很多平台类应用或系统（如电商 CRM 平台、仓库订单平台等等），它们的服务模型是围绕用户维度（这里的用户维度可以是一个卖家或品牌，可以是一个仓库等）展开的。因此，这类型的平台业务，为了支持业务系统的水平扩展性，业务的数据库通常是按用户维度进行水平切分。当平台类应用的一些用户慢慢成长为大用户（比如大品牌、大卖家、大仓库等）后，这些大用户由于其数据量或流量明显要比其它用户多得多，容易出现如业务热点瓶颈、资源使用不均、服务品质受损等问题。SaaS 多租户模型作为一种应用的架构，常用来解决业务的上述问题。在SaaS多租户模型中，业务系统会需要服务多个用户，每个用户（或每批用户）可以被视为一个租户。SaaS 多租户解决业务系统稳定性问题以及租户资源弹性定制的核心思路，就是租户间的资源隔离及数据隔离。针对多租户的问题，可以有多种解决思路。

2).多租户构建模式

针对多租户需求，常见有三种构建模式：

独立数据库：一个租户独享一个数据库实例，提供最强的分离度，租户数据彼此物理不可见，备份恢复都很灵活；
共享数据库、独立 Schema：将每个租户关联到同一个数据库的不同 Schema，租户间数据彼此逻辑不可见，上层应用程序的实现和独立数据库一样简单，但备份恢复稍显复杂；
共享数据库、共享 Schema、共享数据表：租户数据在数据表级别实现共享，提供最低成本，但引入了额外的编程复杂性，备份恢复也更复杂。
从上面多种构建模式对比可见，各方案有着鲜明的优缺点。在技术实现上，可分为两种情况，一种是采用数据库内置能力来支持租户，一种是在应用侧来解决。针对前者，后文将着重谈谈各数据库的租户能力；后者往往依赖于应用研发能力。特别是共享库、Schema、表的模式，具有成本低的明显优势，通常在应用研发侧来解决，但这一模式面临诸多难点，在实际使用中常通过中间件策略增强这一模式能力，补齐短板。
3).中间件策略解决难点
如上面所说，采用中间件策略可以解决第三种模式的短板，这其中需要着重解决以下问题：
开发复杂问题。原模式中通常需要引入租户ID的概念，在行级增加标识来区分，这对于业务研发是不太友好的，需要在中间件层面最好屏蔽，让业务研发回归到租户内，不用感知到租户信息。
跨机分布式事务。有时是需要提供跨租户的数据访问，这意味着业务需要做很多额外的应用改造成本，才能尽量来避免跨机事务导致业务出现报错。可通过中间件层提供强一致分布式事务能力来解决这一问题。
元数据一致性。当使用跨Schema或共享数据表的模式，都面临操作所有租户对象同时生效问题。比如在 MySQL 的建删表、加减列、加减索引等常见的DDL操作，需要中间件能力来保证平台所有租户的表能同时生效，一旦执行中断，可以自动回退，无需人工介入来订正。
租户数据迁移。当租户发展壮大后会面临资源不足需要迁移等情况，此时就需要针对租户提供数据迁移能力，与底层资源层解耦，实现按需使用。这部分维护成本很高，中间件可提供此能力便于在租户层面进行迁移。

2. 数据库租户能力调研

有很多数据库已经内置了多租户能力，用户可很方便地基于此快速开发 SaaS 类应用。下面简单对比下：

1). Oracle 租户能力

Oracle 多租户功能允许在一个数据库实例中同时运行多个独立的数据库，这些数据库被称为插件数据库（简称 PDB）。多租户功能通过将不同的 PDB 分离在不同的存储空间中，实现数据和应用程序的隔离，从而提高数据库的利用率和灵活性。以下是 Oracle 多租户功能的主要特点：

独立性：每个 PDB 都是一个独立的数据库，具有自己的数据和配置。这使得您可以在同一个数据库实例中运行多个独立的应用程序，而不会相互干扰。
共享资源：多个 PDB 可以共享一些资源，如数据库服务器、CPU 和内存。这有助于提高资源利用率，并降低硬件成本。
数据隔离：每个 PDB 都有自己独立的数据存储，确保数据安全性。此外，Oracle 多租户还支持跨 PDB 数据复制和同步，便于数据在不同 PDB 之间共享和一致性。
权限管理：Oracle 多租户功能允许您为每个 PDB 独立设置用户和权限。这有助于实现精细化的权限控制，提高数据安全性。
简化管理：通过 Oracle 多租户功能，您可以集中管理多个 PDB，从而简化数据库管理和维护工作。
高可用性：Oracle 多租户支持 PDB 的自动故障转移、数据备份和恢复，确保应用程序的高可用性。
2).PostgreSQL 租户能力
PostgreSQL 数据库本身并没有类似 Oracle 数据提供完善的租户能力，但是可以结合多种开源技术和框架，实现广义软件架构上的多租户模式。PostgreSQL 支持实例-库-Schema三级，也支持行级安全策略，可通过上面技术能力，实现在库、Schema和行级别的租户能力。
3).TiDB 租户能力
TiDB 采用了双层资源管控机制来实现更精确的管控。“流量控制”模块控制资源限额，确保仅在限额内的操作才能得以执行；“调度控制”模块则对队列中的任务设置不同的优先级，以确保在负载剧烈变化或超负荷运行时，高优先级的任务能够得到快速反馈。TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控，TiKV 层会根据配额映射的优先级来对请求做调度。
资源组，是资源管理的逻辑单元。任意一个会话属于唯一的资源组，而同一资源组的所有会话共享同一组资源限额。TiDB 支持数据库用户与资源组的映射关系，通过设置数据库用户的默认资源组，用户会话可以分属于不同的资源组。未指定默认资源组的用户，与系统内置的 default 资源组相关联。
资源限额，TiDB 首先支持为资源组配置用量 (RU)。RU (Request Unit) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位，目前会考虑 CPU、IOPS 和 IO 带宽三个指标，按照一定的比例统一到 RU 单位上。TiDB 支持设置资源组为 BURSTABLE 模式，BURSTABLE 模式允许资源组超额使用到集群的空闲资源。
调度优先级，默认情况下所有资源组的优先级 (PRIORITY)均为“中等(medium)”。当资源组在同一优先级下，调度优先级按照资源配额的比例分配，这已经能够满足绝大多数场景的需要。用户仍旧可以显式地指定资源组优先级为“高(high)”或者“低(low)”，从而完成更复杂的设定。
4).OceanBase 租户能力
OceanBase 数据库采用了多租户架构。多租户架构适用于资源整合、SaaS 服务等场景，同时也降低了运维复杂度。集群偏向于部署层面的物理概念，是 Zone 和节点的集合，Zone 和节点具有部署地域（称为 Region）等属性；而租户则偏向于资源层面的逻辑概念，是在物理节点上划分的资源单元，可以指定其资源规格，包括 CPU、内存、日志盘空间、IOPS 等。租户类似于传统数据库的数据库实例，租户通过资源池与资源关联，从而独占一定的资源配额，可以动态调整资源配额。在租户下可以创建 Database、表、用户等数据库对象。
资源规格，定义常见物理资源项的大小，包括 CPU、内存、磁盘空间、IOPS 等。创建资源池时指定其资源规格，从而根据定义创建资源单元。
资源单元（Unit），Unit 是租户管理中非常重要的概念。OceanBase 按照 Unit 来管理物理资源，是 CPU、内存、存储空间、IOPS 等物理资源的集合。Unit 也是资源调度的基本单位，其具有节点、Zone、Region 等位置属性，节点是服务器的抽象，Zone 是机房的抽象，Region 是地域的抽象，通过调整 Unit 的位置属性从而调整租户的部署方式。
资源池，每个 Unit 都归属于一个资源池，每个资源池由若干个 Unit 组成，资源池是资源分配的基本单位，同一个资源池内的各个 Unit 具有相同的资源规格，即该资源池内 Unit 的物理资源大小都相同。
通过 Unit 的概念，我们将 OceanBase 数据库的物理概念和逻辑概念进行了关联。每个租户有若干 Unit ，分布于若干 Zone 的若干节点上。而每个节点上分布有若干个 Unit ，这些 Unit 归属于不同租户。概括的讲：集群由节点组成，节点是 Unit 的容器。租户由 Unit 组成，Unit 是数据库对象的容器。
5).PolarDB-X 租户能力
PolarDB-X 是阿里云旗下一款分布式数据库产品。它通过结合非模板化二级分区与Locality两项能力，来解决租户场景问题。
非模块化二级分区，是指 PolarDB-X 支持使用二级分区创建分区表。可在各个一级分区之下的二级分的分区数目及其边界值定义允许不一致。通过这种方式可以将大小租户的数据进行不同的数据存储策略，例如大租户可以将数据路由到一组数据分区中，小租户可以按哈希算法自动均衡到不同分区，从而避免访问热点。
Locality，PolarDB-X 通过这个关键字来指定数据库分区的实际存储资源位置（PolarDB分布式版中存储资源由多个数据节点（DN节点）组成，可以通过DN的ID进行位置分配），以实现数据隔离或数据的均匀分布。