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

digoal

2016-10-12

postgresql , daas , 模板 , schema , database , apply delay , standby

市面上有一些提供daas服务的厂商，例如heroku，可能有上百万的数据库服务；

又比如提供paas平台的服务商，数据库也会有很多，同事这些数据库可能也是模板化的，这些厂商并不一定是为每个客户都新建一个数据库集群来满足数据库的需求。

很有可能是使用数据库或者schema来隔离不同用户的。

1. 例如将模板存储在模板数据库中，根据一个模板数据库创建新的数据库提供服务。

2. 有或者将模板存储在sql文件中，使用sql文件构建新的schema提供服务。

两种方式构建模板的差别

1. 数据库的方式隔离比较彻底，共用的资源较少。

可以实现存储的隔离。

可以实现connection的隔离。

可以实现auth的隔离。

可以实现权限的隔离。

但是数据库与数据库之间是无法直接访问的，需要的话通过dblink或者fdw插件，当然也可以应用层面跨库访问。

2. schema的方式，共用资源较多，可以同时操作不同的schema之间的对象，事务都是本地事务。

简单来说是有schema更便捷，但是权限隔离没有使用数据库那么彻底，可以从pg_class等系统表窥探到没有权限的对象的定义。

从生成效率来讲，使用数据库模板的方式会高很多，因为它只需要copy dir，产生的redo很少，也不需要大量的变更元数据。

从删除效率来讲，差别也非常大，删除schema与创建schema一样，会产生大量的redo，甚至会导致standby剧烈的延迟，后面会有分析。而删除数据库很快，只产生少量的redo。

本文将要给大家分析的就是两者在创建和删除时的大幅差异。

用到两块pci-e ssd，分别存放主库和备库。

主库监听5289,备库监听5290

1. postgresql.conf

2. pg_hba.conf

3. recovery.done

进入template1数据库，准备schema。

主表建表语句如下，为了让schema尽量大一些，使用这种方法来建立。

100个字段，每个字段都有一个约束。

在数据库元数据中，也会产生一大批系统记录，例如

每个表至少会新增的元数据(没算序列的，算序列还更多)

同时还会产生很多数据文件，每个索引，表都会有一个数据文件，如果算上fork(vm, fsm, init)的话，就更多了。

使用test新建500张一样的表，会产生较多的元数据变动，同时会产生一堆数据文件。

建完表后，template1就变500多mb了。

等待drop schema结束，并记录当前xlog位点（很长一段时间后稳定（autovacuum）结束）

在主库执行

发现备库apply卡在一个redo rec上很久，如果接下来主库又产生了大量的redo，那么备库的apply就会延迟严重。

主机redo发送是没有延迟的，也就是说redo已经在备机那里了，但是还没有被apply。

备机apply延迟严重的话，另外一个问题就是备机的xlog会占用较大的空间。

使用pg_xlogdump分析 "堵塞" apply的redo rec

搜索1/13151e28

这笔redo很大，十几mb

备库apply卡住的地方，跟踪备库startup进程(用于recovery的进程)在干什么

查看一下template1下面有多少个文件，（200多个是系统自带的一些元表的数据文件）有50954多个文件。

unlink这些文件至少也要耗费10几分钟。

1. drop schema 产生了多少redo

本例的测试用例，约17mb的redo。

2. 为什么drop schema会导致standby apply的延迟严重

大量的文件操作，导致了apply的延迟。

未发现延迟

分析一下create 和 drop database产生的redo内容

分析从1/168ee5f8到1/168f20e0的内容全部如下

create 和 drop database并没有产生很多的日志，也没有那么多的文件操作。只有copy dir和drop dir。

文件操作少了，比drop schema快多了。

1. schema和database在物理结构上的差别

database是以目录的形式组织在表空间的目录下的，而schema是以文件的形式在数据库的目录下的，没有再细分独立的目录。

所以在drop database时系统调用变得更简单，而drop schema需要挨个文件来。

2. schema和database在元数据上的差别

简单来说就是比擦屁股的动作, drop database擦屁股很快，因为元数据很少只影响pg_databases。

drop schema擦屁股就很烦了，要挨个清理pg_class, pg_attribute, 等等元表。  元表清理完还需要vacuum。

3. create 和 drop schema的文件操作很多，是一个个文件进行的，而且都会记录在redo中，如果schema中有很对对象并且有很多文件的话，会非常慢。

4. create 和 drop database产生的日志少，系统调用也更少。

schema不建议作为daas的模板环境频繁(新增和删除时)使用，如果要频繁的创建和删除模板，建议使用database作为模板。  

database作为模板的一个缺点是连接复用的问题，因为连接复用需要基于user+database，如果有很多db的话，连接可能会消耗很多。

把schema放到database下，新增一个目录存放。删除的时候可以drop dir，但是清理元数据还是少不了的。

schema与其他schema之间的一些依赖关系也需要清理(可能涉及元数据的清理)。

<a href="http://info.flagcounter.com/h9v1">count</a>