Skip to content

Latest commit

 

History

History
151 lines (116 loc) · 4.64 KB

20220620_01.md

File metadata and controls

151 lines (116 loc) · 4.64 KB
Raw

PostgreSQL能支持多少schema

作者

iihero

日期

2022-06-19

标签

PostgreSQL schema

背景

现如今，面向CLOUD的软件分发，提供的Service大都要提供面向multi-tenant的数据存储。
针对PG而言，基于schema进行切分也是其中的一种解决方案。在一些应用框架中，基于列(tablecolumn-discriminator)，基于基于表（使用<table>_<tenant>也是一种使用方式。
本文就尝试一下使用 schema来看看PG支持的如何。我们使用PostgreSQL-14.3来模拟环境。

一、模拟搭建环境

假设一个库支持100个schema, 每个schema下边有300张完全相同的表。 使用下边的SQL来创建。

\set VERBOSITY verbose  

do language plpgsql $$  
declare  
begin  
  for i in 1..100 loop  
    execute 'create schema customer' || i;
    for j in 1..300 loop
        execute 'create table customer' || i || '.tblxxx' || j || '(id int)'; 
    end loop;
    commit;
  end loop;  
end;  
$$;

我们挑customer100这个schema， 来看看其中的表。 注意上边，不要少了"commit"这一句，否则lock数量会不够用。

set search_path = "$user",customer100, public

\d
             List of relations
   Schema    |   Name    | Type  |  Owner
-------------+-----------+-------+----------
 customer100 | tblxxx1   | table | postgres
 customer100 | tblxxx10  | table | postgres
 customer100 | tblxxx100 | table | postgres
 customer100 | tblxxx101 | table | postgres
 customer100 | tblxxx102 | table | postgres
 customer100 | tblxxx103 | table | postgres
 customer100 | tblxxx104 | table | postgres
 customer100 | tblxxx105 | table | postgres
 customer100 | tblxxx106 | table | postgres
 customer100 | tblxxx107 | table | postgres
 customer100 | tblxxx108 | table | postgres
 customer100 | tblxxx109 | table | postgres
 customer100 | tblxxx11  | table | postgres

二、检查相关数据文件

以上是创建100个SCHEMA，每个SCHEMA下边有300张表，总共会有30000张表 。再看看对应的数据文件分布情况。总共有30296个文件，也还不错，符合预期。

[00:47:02-postgres@sean-rh1 ~/14/data/base/16384] ls -l | wc  30296  272657 1792664   
[00:47:10-postgres@sean-rh1 ~/14/data/base/16384] ls -l | wc -l 30296

三、清除所有的表

do language plpgsql $$  
declare  
begin  
  for i in 1..100 loop  
    execute 'drop schema customer' || i || ' cascade';
    commit;
  end loop;  
end;  
$$; 
output: 
drop cascades to table tblxxx92
drop cascades to table tblxxx93
drop cascades to table tblxxx94
drop cascades to table tblxxx95
drop cascades to table tblxxx96
drop cascades to table tblxxx97
drop cascades to table tblxxx98
drop cascades to table tblxxx99
drop cascades to table tblxxx100
and 200 other objects (see server log for list)
LOCATION:  reportDependentObjects, dependency.c:1216
DO
mydb=# \d
Did not find any relations.

  1. 清除后再次查看数据文件

    [00:47:49-postgres@sean-rh1 ~/14/data/base/16384] ls -l | wc -l
30302
[00:53:28-postgres@sean-rh1 ~/14/data/base/16384]

    发现文件还在那里。并没有真正的删除掉。

  2. 执行vacuum full看上

    mydb=# \d
Did not find any relations.
mydb=# vacuum full;
VACUUM
[00:54:46-postgres@sean-rh1 ~/14/data/base/16384] ls -l | wc -l
30441
[00:55:33-postgres@sean-rh1 ~/14/data/base/16384]

    遗憾的是，依然不会删掉。

  3. 直接drop database，再检查

    mydb=# \c postgres
You are now connected to database "postgres" as user "postgres".
postgres=# drop database mydb;
DROP DATABASE
postgres=#

检测文件个数： 
[01:01:15-postgres@sean-rh1 ~/14/data/base/16384] ls -l | wc -l
1

    最终发现，只有drop database的时候，才会真正把表对应的那些物理文件删掉。

四、总结

PG对于schema的支持，应该是可以支持的非常多的。同一个库下边，最后取决于物理文件个数。当然也要权衡最后的性能。文件多了以后，对于这么多表的访问，PG也需要更多的资源来进行BACKGROUND维护。比如archive之类的。
同时，drop table之类的调用，并不立即删除相对应的物理文件。只有在drop database的时候才清除掉。这个与MySQL数据库的行为似乎不太一样。这也意味着，PG在Drop Database能达到更快的速度。

Flag Counter