Greenplum 是最出色的开源MPP数据库，经过15年的发展，从数据仓库发展成了云时代的理想大数据平台。

本系列文章将从各个方面介绍Greenplum对云的支持。本篇侧重多租户。

1. 什么是多租户

多租户指一套系统能够支撑多个租户。一个租户通常是具有相似访问模式和权限的一组用户，典型的租户是同一个组织或者公司的若干用户。

要实现多租户，首先需要考虑的是数据层面的多租户。数据层的多租户模型对上层服务和应用的多租户实现有突出影响。本文重点介绍数据层多租户及Greenplum数据库对各种多租户模型的支持。

权衡不同的多租户实现方式时，需要考虑如下因素：

• 扩展性：租户数量级别，以及未来发展趋势
• 安全性：租户之间数据隔离级别要求
• 资源共享：多租户通常有某种形式的资源共享，需要避免某个租户的糟糕SQL吃掉系统资源，影响其他租户的响应时间
• 灵活性：不同租户可能有不同的需求，对特定租户需求的扩展能力
• 跨租户分析和优化：对全部租户或者多个租户的数据和行为进行分析的能力
• 运维和管理：运维管理的复杂度和便宜性，包括监控、修改数据库模式、创建索引、收集统计数据、数据加载等
• 成本：总体拥有成本，包括方案实现成本、运维成本等

2. 多租户模型

多租户模型描述了租户和该租户的数据之间的映射关系。不同的多租户模型会影响数据库和应用程序的设计、管理和维护。

使用较多的多租户模型有三种。 Greenplum 对这三种模型都有出色的支持。

2.1 一租户一数据库

最简单的多租户实现方式是为每一个租户创建一个Greenplum集群，如下图所示。应用程序为每个租户分配一个租户id，并为每个租户配置相应的数据库连接信息（包括数据库ip、端口等）。应用程序根据租户id连接到为其分配的数据库。

这种模型中不同租户的数据物理隔离，安全级别高。如果每个租户的Greenplum集群使用不同的硬件，则他们之间的资源使用也是物理隔离的；如果租户的Greenplum集群共用同一套硬件，则需要对资源进行合理分配和管理，避免相互影响。由于不同租户使用独立的数据库，灵活性好，容易满足不同租户的特定需求（譬如需要额外的字段）。出现故障时影响面小。缺点是数据库数量大，维护复杂，拥有成本高。适合租户数目比较少的场景。

2.2 一租户一名字空间（Schema/Namespace）

多个租户共享同一个数据库，每个租户拥有独立的名字空间（或模式）。应用程序为每个租户分配一个id，并把每个租户的所有操作限制在为其分配的名字空间/模式之中。如下图所示。

这种多租户模型下，不同租户的数据逻辑上相互隔离，安全控制相对简单。不同租户有不同的模式，可以简便的满足不同租户的特定需求，灵活性高。对资源管理能力要求高，以避免不同租户竞争资源。结合 Greenplum 的 filepace 和 tablespace 特性，可以把不同租户的数据存储在不同的磁盘上，降低了对磁盘IO的竞争。运维和管理较复杂，不易实现大量租户的跨租户分析。适合租户数目适中的场景。

2.3 全共享方式

不同租户共享同一个数据库、同一个名字空间。不同租户的数据在同一组表中共存，通过租户id标记和访问不同租户的数据（应用需要调整访问数据的SQL以包含租户id）。如下图所示。

这种多租户模型中，不同租户的数据物理存储在一起，对系统的资源隔离和安全隔离要求很高。运维相对简单。扩展能力好，可以支持较多数量租户。由于租户数据存储在一起，跨租户数据分析和优化非常简单。成本低，可以较低的代价支持更多的租户。

全共享模型中，很多数据库采用添加大量自定义字段的方式满足不同租户的特定需求，以提高灵活性。这种方式有诸多局限性，譬如字段数目不能太多、管理复杂等。Greenplum 自 5.0 开始支持更多半结构化数据，包括JSON、Hstore 等，通过这种半结构化数据，可以更灵活、高效、便捷的满足不同租户的特定需求。

2.4 混合模型

这种模型不是一个新的实现方式，而是混合前面介绍的三种模型以满足不同用户的服务级别需求。譬如对于最大的少数几个租户采用一租户一数据库的模型，其他租户采用全共享方式。或者对资源隔离级别要求高、服务响应时间要求高的客户采用一租户一数据库的模型，其他租户采用一租户一名字空间方式或者全共享方式。

2.5 对比

下表列出了不同模式的特点。混合模型兼具不同模型的优缺点，不再单独列出。根据不同需求可以采用不同的实现方式。

特性	一租户一数据库	一租户一名字空间	全共享
扩展性、租户数量	低	中	高
安全隔离	物理隔离	逻辑隔离	依赖数据库和应用安全控制
资源隔离	若用不同集群，则高；否则依赖数据库资源管理特性	依赖数据库资源管理特性	依赖数据库资源管理特性
灵活性	高	高	通过JSON等半结构化数据类型提供较高灵活性
跨租户分析	很难，需要跨库查询	难，需要跨模式查询	容易
运维管理	复杂度高	复杂度中	复杂度低
对应用影响	低	低	较高
成本	高	中	低

3. Greenplum 资源管理

上面提到，不管使用何种多租户模型（除非是不同的物理集群），否则都涉及到资源管理的问题，以满足不同租户的不同资源使用需求，避免某个租户过度使用资源，影响其他租户。

Greenplum 5 设计实现了一个全新的基于资源组的资源管理器，相比之前的资源队列，可以做到灵活高效的资源管理。

下表对资源组和资源队列进行了对比：

特性	资源组(Resource Group)	资源队列(Resource Queue)
并发控制	事务级别	语句级别
死锁	无	极端情况下会出现
CPU 管理	基于比例、基于cgroup	基于粗粒度的优先级
CPU 空闲利用率	可以充分利用空闲CPU	部分利用
内存限制	精细	粒度粗
组内内存共享	是	否
动态修改资源配置	是	部分
排队	无并发槽位或者内存配额时	无并发槽位时
管理DDL、Utility语句	是	否
Segment级别监控管理	是	否
基于规则的资源管理	是	否

Greenplum 可以实现细粒度的资源管理，在云上多租户场景下，非常适合实现租户的资源隔离，避免某个租户过度占用资源，确保资源合理使用。

有关更多细节，请参考官方文档 https://gpdb.docs.pivotal.io/580/admin_guide/workload_mgmt_resgroups.html

4. 总结

多租户是云数据库的基本要求，本文介绍了Greenplum的四种多租户实现方式，并对之进行了对比。还介绍了 Greenplum 新的基于资源组的资源管理器，以实现多租户的资源共享和隔离。