PostgreSQL 多租户

PostgreSQL 多租户

作者

digoal

日期

2016-11-07

标签

PostgreSQL , 多租户 , schema , DATABASE , PDB , Oracle 12c


背景

Oracle 12c提出了数据库多租户的概念,即PDBs(私有数据库),因为早期Oracle的设计是以schema为隔离的,schema的隔离不够彻底,原因是通过赋权就很容易获得不同SCHEMA下的数据。

PDB的设计与PostgreSQL的Database概念非常相似,所以PostgreSQL实际上很适合用来实现类似PDB的场景,也即是多租户的场景。

用户可以参考我写的《PostgreSQL 逻辑结构 和 权限体系 介绍》

实际上如果不需要彻底的隔离,可以考虑继续使用schema。

使用数据库或SCHEMA作为多租户的基础,各有优劣。

基于数据库的多租户

1. 优点

数据库隔离较为彻底,从认证层面就开始隔离了,数据库与数据库之间也无法直接访问,必须要登陆到对方的数据库中才能访问对方的数据(即使使用fdw, dblink也是有登陆的过程的)。

登陆时可以通过pg_hba.conf控制来源IP,用户是否有权限登陆目标库。

同时在数据库中的权限体系中还可以配置是否允许用户访问目标库,或者在目标库创建SCHEMA。

2. 缺点

因为每个数据库对应了各自的元信息,大概有几百个文件,所以如果租户比较多,数据库也会比较多。

基于schema的多租户

1. 优点

单个数据库,多个SCHEMA的方式,比较轻巧,如果是企业私有的多租户,可以这样使用。

通过数据库的权限体系隔离用户,访问不同SCHEMA。

2. 缺点

无法通过pg_hba.conf控制schema的权限,权限隔离可能不够彻底。

用户可通过查看元表,观察到其他schema的对象,定义等信息,不安全。如果是企业内部私有的,并且这部分缺陷不敏感时可以使用。

创建租户和删除租户需要产生大量元数据,或删除大量元数据,可能导致STANDBY长时间延迟。详见

《PostgreSQL DaaS设计注意 - schema与database的抉择》

例子

基于database

创建用户
create role 租户名 login ...;

配置防火墙
pg_hba.conf
host 数据库 用户 来源IP md5

从模板创建数据库
create database db with template templatexxx;

回收权限
revoke all on database db from public;

赋权
grant all on database db to 租户;

基于schema

创建用户
create role 租户名 login ...;

创建schema
create schema xx;

回收权限
revoke all on schema xx from public;

赋权
grant all on schema xx to 租户;

以schema为例的多租户路由选择

例如通过客户端application_name或者客户端IP地址,区分不同的租户。

每个租户的模板完全一样,只是使用了不同的schema。

客户使用search_path修改路径,完成对路由的选择。

一套程序,完成多租户的方法:

建立会话后,首先选择路由(即根据客户端IP或设置的application_name,设置对应的路由)。

也可以每次设置路由(开销大,较浪费)。

后续的操作则会自动匹配对应的schema.

路由函数举例

以application_name为schema命名

create or replace function public.route() returns void as $$
declare
begin
  execute 'set search_path='||current_setting('application_name')||', "$user", public' ;
end;
$$ language plpgsql strict;
postgres=# select public.route();
 route
-------

(1 row)

postgres=# show search_path ;
      search_path
-----------------------
 psql, "$user", public
(1 row)

接下来的SQL都会首先搜索psql中的对象。

如果schema很多,而且要经常调用,建议写成C function,使用更高效的匹配算法,例如hash search。

在业务函数中封装选择函数的例子。

create or replace function 业务函数(参数) returns  xx as $$
declare
  xx;
begin
  perform 路由函数(影响路由选择的参数);
  业务SQL;
  ////
end;
$$ language plpgsql strict;
时间: 2024-08-28 00:48:24

PostgreSQL 多租户的相关文章

数据库选型十八摸 之 PostgreSQL - 致 架构师、开发者

标签 PostgreSQL , 数据库特性 , 数据库应用场景分析 , 数据库选型 背景 数据库对于一家企业来说,相比其他基础组件占据比较核心的位置. 有很多企业由于最初数据库选型问题,导致一错再错,甚至还有为此付出沉痛代价的. 数据库的选型一定要慎重,但是这么多数据库,该如何选择呢? 我前段时间写过一篇关于数据库选型的文章,可以参考如下 <数据库选型思考> 另外,PostgreSQL这个数据库这些年的发展非常的迅猛,虽然国内还跟不上国外的节奏,但是相信国人逐渐会融合进去. 所以我专门针对Po

PgSQL · 案例分享 · PostgreSQL+HybridDB解决企业TP+AP混合需求

背景 随着IT行业在更多的传统行业渗透,我们正逐步的在进入DT时代,让数据发挥价值是企业的真正需求,否则就是一堆废的并且还持续消耗企业人力,财力的数据. 传统企业可能并不像互联网企业一样,有大量的开发人员.有大量的技术储备,通常还是以购买IT软件,或者以外包的形式在存在. 数据的核心 - 数据库,很多传统的行业还在使用传统的数据库. 但是随着IT向更多行业的渗透,数据类型越来越丰富(诸如人像.X光片.声波.指纹.DNA.化学分子.图谱数据.GIS.三维.多维 等等-- ),数据越来越多,怎么处理

云端海量任务调度系统数据库设计 - 阿里云RDS PostgreSQL案例

标签 PostgreSQL , 任务调度系统 , 数据库设计 , schemaless 背景 任务调度系统中的任务状态管理,通常会用到数据库来存储任务调度的过程状态,控制任务的锁等. <advisory lock 实现高并发非堵塞式 业务锁> 如果是小量任务,是挺好实现的,但是每小时处理几十亿或者几亿的任务,如何设计这样的任务状态管理数据库呢? 挑战 对于一个面向多个用户的任务调度平台(例如云端的任务调度平台,将面向所有租户使用). 较大的挑战是任务数据的写入(海量),另一个是任务状态的更新(

PostgreSQL、Greenplum 日常监控 和 维护任务

标签 PostgreSQL , Greenplum , Recommended Monitoring and Maintenance Tasks , 监控 , 维护 背景 Greenplum的日常监控点.评判标准,日常维护任务. 展示图层 由于一台主机可能跑多个实例,建议分层展示. 另外,即使是ON ECS虚拟机(一个虚拟机一个实例一对一的形态)的产品形态,实际上也建议分层展示,以示通用性. 主机级图层 1.全局 2.以集群分组 展示图形 1.饼图(正常.警告.严重错误.不可用,占比,数量) 2

We can ignore the performance influence when use sync replication in PostgreSQL 9.1

PostgreSQL 9.1 提供了同步复制的能力,但是我一直担心同步复制必将带来较大的性能影响. 下面从单节点,多个异步复制节点,多个复制节点(含同步复制节点):以及同步事务,本地事务,异步事务这几个方面来测试一下同步复制带来的性能影响. 下面是测试过程和测试结果. 首先是测试环境如下 :  服务器配置 :  主库:   8核, 24G, 1块本地SAS10K转硬盘, 1块1GB网卡, x86服务器 standby库1:  8核, 8G,  1块本地SAS10K转硬盘, 1块1GB网卡, x8

空间|时间|对象 圈人 + 目标人群透视 - 暨PostgreSQL 10与Greenplum的对比和选择

标签 PostgreSQL , PostGIS , geohash , brin , gist索引 , Greenplum , HybridDB for PostgreSQL 背景 通常一个人的常驻地可能会包括:家.儿女家.双方父母家.情人.异性伴侣家.公司.商圈若干等. 通过对这些数据的运营,可以实现很多业务需求.例如: 1.寻人 <海量用户实时定位和圈人 - 团圆社会公益系统(位置寻人\圈人)> 2.线下广告投放人群圈选,选址,商圈人群画像. <数据寻龙点穴(空间聚集分析) - 阿里

PostgreSQL 助力企业打开时空之门 - 阿里云(RDS、HybridDB) for PostgreSQL最佳实践

标签 PostgreSQL , Greenplum , 时间 , 空间 , 对象 , 多维透视 , 多维分析 背景 时空数据无处不在,未来空间数据的占比会越来越高,在TP与AP场景的需求也会越来越旺盛. 选址.网格运营 空间数据自动聚集分析:时间+多边形圈人:驻留时间分析:舆情分析:... 室内定位 3D坐标:相对坐标系:+以上:运营活动效果分析报表: 科研 太空探索.测绘.气象.地震预测.溯源 无人驾驶 点云:动态路径规划: 空间调度(菜鸟.饿了么.滴滴.高德.快递...) 实时位置更新:多边

PostgreSQL 电商小需求 - 凑单商品的筛选

标签 PostgreSQL , 电商 , 凑单 , 最佳凑单 , 任意字段组合 背景 电商的促销活动非常多,规则可能比较复杂,要薅羊毛的话,数学可能要比较好才行.因此也出现了大量的导购网站,比如SMZDM. 但是实际上电商里面也有类似的应用,可以智能的分析买家的需求,根据买家的需求.已有的券.购物车,向用户推荐凑单品. 凑单的需求,本质上是多个字段组合搜索的需求. 1.购物车总金额 2.用户标签 3.用户优惠券 4.店铺活动标签 5.商品本身的多种标签 等. 根据规则计算出一些条件,根据这些条件

PostgreSQL 流式统计 - insert on conflict 实现 流式 UV(distinct), min, max, avg, sum, count ...

标签 PostgreSQL , 流式统计 , insert on conflict , count , avg , min , max , sum 背景 流式统计count, avg, min, max, sum等是一个比较有意思的场景,可用于实时大屏,实时绘制统计图表. 比如菜鸟.淘宝.阿里游戏.以及其他业务系统的FEED日志,按各个维度实时统计输出结果.(实时FEED统计,实时各维度在线人数等) PostgreSQL insert on conflict语法以及rule, trigger的功