PolarDB-X 多租户的设计和思考

前言

近几年随着分布式数据库的蓬勃发展，越来越多的业务开始尝试分布式，随之而来的用户需求也多样化，整体总结概括下用户对于NewSQL的理解是数据库+分布式+云原生：

1. 首先，基本需求你是一个数据库，除了SQL兼容性以外，你还得有数据库的基本元素，比如用户权限、备份恢复、运维监控、容灾高可用、数据导入导出等。

2. 其次，需要体现分布式的特性，比如最常见的分布式的线性扩展能力(通常指高并发)，基于分布式多节点的MPP并行计算(通常指HTAP能力)，以及基于分布式多节点的多租户需求(资源隔离)。

3. 最后，云的本质的是虚拟化所带来的资源池化效应，基于云目前提供的基础设施(比如云存储：OSS/ESSD、S3/EBS)，实现降本增效的效果。比如数据库的存储计算分离、冷热分层存储等能力，这些都是基于云原生的技术创新.

PolarDB-X作为一款阿里云自主研发的云原生分布式数据库，具备了众多企业级特性，本文想重点讨论下PolarDB-X对于多租户的设计和思考。

多租户的典型场景

首先列举一下和用户交流多租户场景时，典型的几段对话：

场景对话1： 我们公司有多个部门，在装好一套数据库之后，期望后续可以动态申请一个数据库资源，期望不同的数据库实例做好资源隔离。继续深挖交流，期望不同部门在分配资源时，期望有部门预算配额的限制能力，比如A部门今年就申请了10台服务器作为独立资源池，用完了就没有了，除非借调资源池配额...

场景对话2：我作为数据库部门，人手有限，部署和维护了多套开源数据库实例，比如mysql、tidb，但每个实例单独维护监控，比较繁琐，期望有一个统一的多实例监控能力。除此以外，数据库备份恢复、容灾切换、参数优化、操作系统打补丁等常见的运维操作能有一个运维管理平台...

场景对话3：我这边有一个SAAS类的业务，面向用户提供了业务服务，刚开始业务量比较少，但随着时间的推移，单机越来越抗不住，期望有多租户的运维管理能力。比如，其中个别vip用户都说我的业务很重要，一定需要重点保障，资源要物理隔离，另外我也需要进行数据全局分析，需要满足多租户混部、vip租户独立、以及全局汇众分析的能力。

场景对话4：地方数字政务系统，目前面向省、市、县等多租户有数据大集中的诉求，但考虑权责分离，每个租户上期望做物理资源隔离以及权限隔离，确保数据安全。另外，业务上线是分阶段的过程，在数据割接过程中，需要有动态维护租户的能力，以及个别地市的数据规模人口基数比较大、以及个别地市的数据有特殊的反恐的数据分析需求等

我们对其中用户对于多租户的诉求做一些抽象和整理，大概分为两大类：

1. 多业务app，不同部门或业务之间，期望数据库一次安装后满足动态创建的诉求，以及统一批量的运维管理

2. 单业务app，一般面向核心业务，期望数据库内部能提供面向业务数据的多租户管理能力

我们下面来看一下，阿里针对这两大类场景的思考和实践。

阿里云PolarDB-X的实践

1. 全面拥抱DBaaS

PolarDB-X设计上全面拥抱了DBaaS(Database-As-A-Service)，将数据库以云服务模式交付给用户，就是数据库即服务DBaaS，也称云数据库。

各类云原生技术中最具代表性的一个就是 Kubernetes(后续简称k8s)，k8s是一个用于自动部署、管理容器化应用的系统。最初 k8s 是由 Google 公司主导开发的，后来 Google 将它捐献给了云原生计算基金会 CNCF。k8s 能够管理成百上千台机器，并为在上面运行容器应用提供强大而稳定的基础设施。

PolarDB-X数据库在资源管理和调度是构建在 k8s 之上，基于k8s对于资源的抽象、以及自身开源开放的属性，可以很好地满足 PolarDB-X 的两种交付形态：On-Demand 和 On-Premise。通常来说，线下传统的电信、金融等行业有机器利旧的诉求，因此基于 k8s 的 On-Premise 标准轻量化模式将是一个很好的选择。

上表中详细展示了 PolarDB-X 在公有云和混合云的几个交付形态，整体All in Kubernetes 为资源底座，结合用户白屏化的用户交互，满足Database-As-A-Service的使用体验。

1.1 线下On-Premise体验

线下部署DBaas部署，一般要分四步走：

1. DBaas的一次性装机 PolarDB-X在面向线下轻量化输出，提供了DBStack的交付版本，可以基于最小3台机器进行快速部署基座。

2. 动态维护好机器资源列表

3. 不同部门租户的账号，可以创建不同规格的实例，限制CPU/MEM/Disk等

4. 每个实例，都有各自独立的监控报警和运维处理，方便操作

1.2 公有云On-Demand体验

PolarDB-X在公有云上，在地域开区售卖后，会部署一整套的k8s相关资源，提供了一键售卖能力，用户不直接对基座和主机资源做维护。另外，阿里云提供了主子账号的能力，可以方便业务按照部门进行分权限管理，配置不同账号可见的PolarDB-X资源权限。

一个简单直观的公有云体验的视频：

PolarDB-X公有云操作简介324 播放 · 1 赞同视频

2. 内核级SaaS多租户

SaaS厂商构建服务具有规模效应，尤其是规模越大后成本越低，对资源的合理复用是一个强诉求，合理利用云厂商提供的资源Paas的服务，同时对多租户的资源进行动态整合和分配，能进一步降低总成本。

为了实现资源复用和公用，在数据库层，通过一定的规则进行租户路由将租户映射到具体的业务数据库中，在数据库上实现多个租户共用和复用，从而提升使用率，降低单个租户的使用成本。

我们分析和归纳了常见的多租户场景，主要有几类：

1. 一层租户，比如餐饮SAAS，租户为餐厅，一般单个餐厅的数据单台物理机可满足，每个租户可以用单机模式

2. 二层租户，比如电商SAAS，典型的新零售模式，提供电商平台给公司，比如微信的朋友圈营销，公司会基于电商平台二次服务微信卖家和微信买家。此时头部的微信卖家的数据量可能会超过单台物理机的规模，需要对单个租户支持分布式。

3. 政务系统，支持省地市的多租户分模式，权责分离，根据不同的业务和数据模型，规模可大可小。

多租户的场景，抽象到数据库层面的诉：

1. 扩展性。扩展性包含多个层面，从租户层面来说，租户随着业务发展，小租户数据量逐步多，可能会发成大租户，对应商业上可能是购买更高级版本的服务，历史数据库是否能够持续使用，迁移期间服务是否可用/中断等

2. 租户成本。SaaS通过规模效应，相较于传统软件具有很大优势，在保证SLA前提下尽量降低资源持有和使用成本，在数据库层面保证一定的水位，防止突发大流量，同时支持横向扩展。另外，数据历史性缘故，历史数据查询和修改概率较低，通过合理设置冷热数据比例来减少热数据常用存储量。

3. 运维复杂性。作为标准化SaaS，服务的客户较多，面向多租户数据库实例的监控和运维需要尽量做到自动化，同时新租户加入和老租户的退出同样要做相应的生命周期管理，尽可能将DBA从繁杂的工作中解脱出来。

业界常见的数据库多租户设计

1. schema隔离

一般数据库支持schema/table的定义，多租户设计上可以将一个租户使用一个DB、或是一个instance，大小租户统一管理。另一种常见是多个租户公用一个DB，公共数据（例如国家地区代码）使用同一套表，每个租户的业务数据分别使用不通的表，业务表名一般会带上租户ID。

这类schema隔离，对来说解决隔离性问题也较容易解决，但是这种管理方式带来的问题是元数据较多，例如ERP这种偏数据库重操作的应用，每个租户一套表，导致表的数目较大，因此会对后期运维，例如DDL等比较麻烦。同时租户迁移需要制定到具体库或表，迁移的自动化代码需要随着业务变化进行修改，运维成本偏高。

另外，这类大租户设计上也会面临二次拆分的诉求，解决超大租户的大表扩展性问题。

2. 数据行隔离

顾名思义是将多租户的数据按行级别进行混合存储，租户的每行记录都带上了租户ID，写入和读取都会针对一个租户数据进行操作。相对于schema隔离来看，最大的挑战在于多租户的数据扩展和运维问题，因为常见的schema的迁移可以借助于一些数据库的schema管控工具，而在行隔离模式下，需要有精细化管理，比如常见的业务就是ETL + canal增量同步的组合，对于普通业务来说有一定的开发门槛。

针对schema隔离中的大表扩展性问题，使用行隔离模式会比较有优势，以电商场景为例子，SaaS厂商可以通过建立一批订单表（例如基表数目table_base_number = 256），可以根据租户ID和订单号Hash方式(例如 MOD （table_base_number )写入到业务表，从一定程度上避免了大表，后续需要扩大表的数量时，修改对应的table_base_number即可。

阿里的多租户设计

PolarDB-X 作为分布式数据库，在解决Saas多租户隔离上，以数据行隔离为基础，内置租户新增和动态迁移的分配能力，另外引入支持大租户的locality定义特性，提供schema隔离的机制(大客户可独享库表结构，避免小租户的影响)，所有的租户运维变更带来的租户数据迁移、以及租户路由全部内置为数据库能力。同时PolarDB-X基于分布式多节点的模式可以很好的支持多租户的高并发、以及MPP并行查询的能力。

如上图所示，常见的Saas业务的设计，一般会在每张表中增加租户id的字段，查询和插入的时候都会带上对应的租户id。这个租户id映射到分布式里，等同于数据分区的字段，基于该多租户id的字段，可以非常容易实现多租户之间的线性扩展。

除了基础的线性扩展的需求外，Saas多租户的模式更强调数据隔离和数据安全的特性，期望有"动态"维护vip租户的能力，针对不同的租户配置不同的cpu/mem资源，从而满足资源隔离和数据安全的需求。

PolarDB-X在DBaaS的架构下，申请的资源物理上都通过cgroup进行隔离，考虑cgroup隔离毕竟还是一个纯软件的技术，在隔离的性能开销、以及隔离的精度上还是会有一些缺陷，会存在隔离不彻底的情况，比如CPU超线程下的物理核争抢、OS cache的影响、numa架构影响等，因此PolarDB-X在资源形态上包含多种规格类型：

用户可以按需付费选择不同的规格类型，在这个物理资源隔离的保障下，多租户的资源隔离问题就抽象成如何做好租户调度到不同节点上(租户对应的节点依赖DBaaS提供的资源隔离能力)，下面我们来实际分析下PolarDB-X内核是如何设计和支持Saas多租户？

2.1 租户负载均衡调度

多租户场景的基本诉求是低成本支持业务，通常一个SaaS化的业务会有一套APP进行服务业务，这套APP可以链接一个或者多个租户的数据库。随着业务的发展，期望数据库提供线性扩展的能力，满足百万~千万级别租户的数据库需求。

传统的基于单机数据库会面临一定的天花板，PolarDB-X作为分布式数据库，天生具备数据分区能力，基于租户id作为数据拆分字段，非常贴合分布式的诉求，随着租户数量和容量的增加，可以动态扩展数据库节点来提升数据库的性能。

如上图所示，PolarDB-X在新版本中引入了Auto模式，引入了一致性hash作为分区条件，可以更灵活的支持多租户的数据分区的数据均衡问题，减少数据迁移的成本。

2.2 租户locality调度

多租户场景面向vip用户场景的高级诉求，就是可以针对租户设置资源隔离，PolarDB-X引入了分区级locality的能力，一个租户可以是一个或者多个分区，举一个实际的例子来看，假如政务系统的租户id是城市，期望每个城市的数据单独存储到一个独立的节点上。

从上图的例子中，可以看到PolarDB-X支持按照list做分区，同时在每个分区上支持指定locality属性，该属性的标签定义了当前分区需要放置到哪个物理节点上.

PolarDB-X的locality设计上支持库、表、分区等多个层次，同时支持运行时动态变更、迁移、合并等，这样更有利于业务在前期规划不足时的动态调优的能力。比如，杭州市政府的行政区域规划调整，导致租户数据的动态合并和迁移。

2.3 租户热点分裂

多租户场景面向vip用户场景，单个vip租户从扩展的需求来看，也需要支持分布式多节点的扩展性。

如上图，举一个实际的例子来看，阿里巴巴的电商平台对于卖家来说是一个SaaS化的系统，其中的天猫超市是一个超级卖家，其所产生的订单销售额非常高，单节点无法支撑这个天猫超市作为租户的能力，此时就需要有一个多租户的热点分裂能力。

PolarDB-X的热点租户分裂操作：

# 单张orders表做热点租户的分布式分裂
alter table orders extract to partition by hot value('天猫超市');
or
# 单个租户的多张表一起做热点租户的分布式分裂
alter tablegroup tentat_group extract to partition by hot value('天猫超市');

2.4 租户数据安全

多租户虽然主要面向业务app系统提供服务，但难免会有直连数据库的查询和运维操作，不同租户之间的数据安全也需要重点考虑，举一个政务系统的例子来看，不同省市县的账号不应该互相可见对方的数据，除非是超级账号的权限。

# 多租户授权例子：
# 单业务app下的多租户，一般会在数据集上冗余租户id字段，PolarDB-X将租户映射到分布式的数据分区
# 通过对数据分区进行授权，可以控制不同用户仅可见自己关联的租户
grant select,insert,update,delete on `db`.`table` partition `zhejiang` to 'zhejiang'@'%' 
grant select on `db`.`table` partition `beijing` to 'beijing'@'%'

租户级权限，相比于传统的库表级权限会提供更细粒度的管理能力，但相比于细粒度的行级权限、label权限控制不需要额外扩展业务表字段，结合分布式带来更一体化的体验，这部分的功能会在后续版本中提供。

总结

回顾下PolarDB-X对于用户多租户场景的支持情况：

1. 场景对话1和2，PolarDB-X按照Database-As-A-Service装好后，可以满足不同部门按需申请多实例，并支持资源隔离，同时每个多实例支持独立的监控和运维能力。基于主机维度的运维，可以满足多实例的批量运维。

2. 场景对话3和4，PolarDB-X提供内核级Saas多租户能力，满足业务发展过程中数据库的线性扩展，同时针对不同租户下的精细化运维能力，更好的满足业务Saas化的诉求。

如上图所示，最后梳理和总结下现有数据库的常见多租户支持的设计，总结下新一代的NewSQL分布式数据库：

1. 在面向多业务app，普遍选择了基于云架构的DBaaS模式(cloud模式 或 serverless模式)，用户可以不用关系数据库的物理模式，由DBaaS架构实现物理机的管理，提供单物理机多实例共享的方式来满足用户按实际使用付费，降低业务使用成本。随着Kubernetes理念的不断普及和更新，基于Kubernetes的DBaaS模式同样适用于线下部署模式。

2. 在面向单业务app，针对用户多租户的核心业务，需要结合分布式的数据分片，结合locallity数据精细化调度、以及分布式热点优化的能力，才可以更好满足日益增长的SaaS多租户的场景。

文章来源：阿里云社区