postgresql的存储方式有几种

A. pg数据库数据文件111代表什么

仅供参考
所有数据库对象都有各自的oid(object identifiers),oid是一个无符号的四字节整数，相关对象的oid都存放在相关的system catalog表中，比如数据库的oid和表的oid分别存放在pg_database,pg_class表中。
1、数据库集群-Database cluster
2、数据库-Database
3、表空间-tablespace
数据库在逻辑上分成多个存储单元，称作表空间。表空间用作把逻辑上相关的结构放在一起。数据库逻辑上是由一个或多个表空间组成。
新创建的数据库默认创建下面的表空间：
1)Catalog表空间 存放系统表信息2)System表空间 存放用户数据3)Temp表空间
4、模式-Schema
自动创建的系统模式如下：
1)PG_CATALOG2)PG_LARGEOBJECT3)PG_TOAST4)PG_PARTITION
默认的用户模式PUBLIC。
5、段-segment
6、区-extent
7、块-block
8、数据库对象-Database object
1)模式对象表、索引、序列、大对象、视图、函数、存储过程、触发器、包 … …2)非模式对象用户、数据库
9、数据表-Table
10、索引-Index
11、序列-Sequence
12、视图-View
二、物理存储结构
在执行initdb的时候会初始化一个目录，通常我们都会在系统配置相关的环境变量$PGDATA来表示，初始化完成后，会再这个目录生成相关的子目录以及一些文件。在postgresql中，tablespace的概念并不同于其他关系型数据库，这里一个tablespace对应的都是一个目录。如下图就是PG的物理结构：
.png
1、存储系统主要包括三个部分：
内存中：buffer，MemoryContext；
数据文件，临时文件；
日志文件，日志缓存。
2、文件和目录相关作用描述：
.png
.png
3、数据文件结构
.png
3.1、页
.png
将数据文件中的空间从逻辑上划分成一个个页面(数据块)。页面是数据库I/O的基本单位，即只能整页读写数据文件, 页面的大小默认是8K。
页面可以分成两种：
1)数据页面：数据页面是用来存储用户数据的。
2)控制页面：控制页面用来管理这些数据页面。
数据库共享缓存中的空间划分也是按页为基本单位, 一个页的大小与数据文件中页的大小一致, 这样便于整页读取数据文件,并放入到数据库Buffer中, 从Buffer写入数据文件也同理，保证了缓存与数据文件结构和内容上的一致性。
3.2、Block(块)
概念上基本等同于Page, 但Block更多用于说明DMS中对数据文件中Page的描述。
例如: 对文件的读写的操作, 文件读写位置的定位, 数据文件空间回收等操作, 单位均是以块进行。
数据块的大小在系统初始化时指定，默认是8K，可以取值4K,8K,16K,32K。
3.3、Extent(区)
把数据文件中8个连续的Page构成的空间称为一个Extent。Extent是数据库进行数据文件空间分配/释放的基本单位。每个表、索引、序列对象都是由若干个区组成。数据文件被创建后，除自动保留部分区作为控制区外，其他区全部处于未分配状态。表、索引、序列对象的所有数据都存放在Extent中，当向这些Extent中插入数据时，若该Extent的所有页面都已占满，系统就会自动在所属表空间的数据文件中寻找一个尚未分配的区，并将其状态修改为数据区。
3.4、控制页面
用于空间管理的控制页面：PFS/GAM/IAM。
用于增量备份的控制页面：DCM。
判断可见性的控制页面：VM。
预留的控制页面：BCM/SGAM。
3.5、PFS
Page Free Space,简称PFS页.
用于记录本数据文件中页面的空间使用情况。对文件中的每个页面，PFS中都有一个“字节”与之对应，该字节记录了该页面的状态。
PFS页前64bytes被预留为页头, 剩下81024-64=8128一共覆盖81288K=64MB空间.
故PFS页每隔8128个页面出现一次, 系统初始化把第一个PFS页放在数据文件的第二个页面位置,即:第1号数据页面, 由此可知,第N个PFS页的位置在8128*N+1.
.png
3.6、GAM
Global Allocation Map，简称GAM页。
功能:记录所在数据文件的Extent的分配情况，GAM页中除GAM头外,剩下空间的每一位(bit)均对应一个Extent的分配情况。若某bit位为1，则表明该bit位所关联的Extent已被分配出去,反之未被分配。
若一个GAM页面大小为8K,则除GAM头(64 bytes)外,一个GAM页面所能覆盖的文件范围是: (81024-64)8(88K),约4GB空间。此外，GAM页每隔881288个页面出现一个，系统要求第一个GAM页出现在文件的第3个页面位置(即:第2个索引位置),由此得知,第N个GAM页的出现位置是: 881288*N+2
.png
3.7、IAM
Index Allocation Map，简称IAM页。
功能：每个IAM页只隶属于一个数据库对象(例如:表),但一个数据库对象可包含多个IAM页,由此可见IAM页与数据库对象的关系是1对1，而数据库对象与IAM页的关系是1对多.
IAM的结构与GAM页类似,除IAM头外,剩下空间的每一位(bit)均对应着一个与IAM相关的Extent。若某bit位为1，则表明该bit位所关联的Extent已被分配给该IAM,反之未被分配。若一个IAM页面大小为8K,则除IAM头(64 bytes)外,一个IAM页面所能覆盖的文件范围是: (81024-64)8(88K),约4GB空间。
但与GAM也不同之处在于:IAM的出现位置不固定,只在在创建数据库对象的时候才分配。
.png
三、逻辑与物理存储关系
1、逻辑关系存在表空间；
2、表空间存在对应的数据文件中；
新创建的数据库对应的数据文件的名称:
Catalog表空间 – databasename.dbfSystem表空间 – Udatabasename.dbfTemp表空间-- Tdatabasename.dbf
前面加 “U” 前缀代表用户数据表空间，用于保存用户表的数据。
不带 U 代表 是系统表的表空间，用于保存系统表的数据。
U 前缀的数据文件代表的表空间名为PG。
不带U 的数据文件代表的表空间为 CATALOG。
四、数据库文件、表空间、其他文件之间的关系
1、关系图如下：
.png
说明：
1)每一个数据库具有一个或多个数据文件，用户存放数据库的所有数据。
2)数据库的数据文件有以下特征：
一个数据库文件只能与一个数据库的一个表空间相连。
一个表空间可以由多个数据文件组成。
3)数据库对象与文件关系：
数据库对象放到表空间中。
表空间有多个数据文件。
表空间中有多个数据库对象。
4)数据库对象逻辑上是存储在表空间中，物理上是存储在与表空间相关联的数据文件中。
2、数据库包含的文件种类：
1)数据库文件：data/DB
数据库对象，如：数据库、表，索引，序列等对象。
2)控制文件：data/CTL
用来记录数据库集群的状态信息，如：版本信息、集群所管理的各种文件信息、检查点信息、事务状态信息等。
3)日志文件：data/REDOLOG
记录数据修改操作的日志，用于系统发生故障时进行数据恢复。
4)临时文件：data/DB
存放数据库进行计算的过程中，生成的各种中间对象，如排序运算的外存归并单元。
5)参数文件：data目录下
五、Postgresql 底层存储管理方式：
Postgresql的每个数据库均存放在一个目录中，以db_oid命名，该目录中存放每个表对应的文件，文件名以该数据表对应的relfilenode_oid命名。当表中的数据量足够大，导致表文件的大小大于1GB的时候，postgresql会自动创建新的文件用于存放新插入的数据。新文件的名称为： relfilenode_iod.1, relfilenode_iod.2 等。使用该策略是为了防止在某些文件系统中，最大支持文件尺寸不能大于1GB的情形。
db_oid, relfilenode_oid可以从pg_class系统表中查询得出。

B. PostgreSQL Oracle 兼容性之存储过程

 在oracle中，函数和存储过程是经常使用到的，并且有所区别；而postgresql中函数和存储过程都是相同定义的。

 1.定义：定义存储过程的关键字为procere。
 2.创建存储过程

例：
（无参数）

（有参有返）

总结 ：
 1.创建存储过程的关键字为procere。
 2.传参列表中的参数可以用in，out，in out修饰，参数类型一定不能写大小。列表中可以有多个输入输出参数。
 3.存储过程中定义的参数列表不需要用declare声明，声明参数类型时需要写大小的一定要带上大小。
 4.as可以用is替换。
 5.调用带输出参数的过程必须要声明变量来接收输出参数值。
 6.执行存储过程有两种方式，一种是使用execute，另一种是用begin和end包住。

 1.定义：定义函数的关键字为function。
 2.创建函数

总结 ：
 1.定义函数的关键字为function 。
 2.必须有返回值，且声明返回值类型时不需要加大小。
 3.函数中定义的参数列表不需要用declare声明，声明参数类型时需要写大小的一定要带上大小。
 4.as可以用is替换。
  5.执行存储过程有两种方式，一种是使用select，另一种是用begin和end包住。

不同点：
 1.存储过程定义关键字用procere，函数定义用function。
 2.存储过程中不能用return返回值，但函数中可以，而且函数中必须有return子句。
 3.执行方式略有不同，存储过程的执行方式有两种（1.使用execute2.使用begin和end），函数除了存储过程的两种方式外，还可以当做表达式使用，例如放在select中（select f1() form al;）。

 postgresql则将函数和存储过程合为一体，不再明确区分存储过程与函数。
 1.定义：定义函数（存储过程 ）的关键字为function。
 2.创建

例：

 1.必须有有returns（注意是returns不是return）子句，无返回值时returns viod
 2.执行时，有返回值用select，无返回值时用perform
 3.必须指定语言LANGUAGE

C. pgsql的主键存储方式

PostgreSQL的稳定性极强，Innodb等索引在崩溃，断电之类的灾难场景下 抗击打能力有了长足进步，然而很多 MqSQL用户 都遇到过 Server级的数据库丢失的场景 -- MySQL系统库是 MyISAM，相比之下，PG数据库这方面要更好一些。

任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以位置双曲线甚至对数曲线，到 顶峰之后不在下降，而MySQL明显出现一个波峰后下滑（5.5版本 之后，在企业级版本中有个插件可以改善很多，不过需要付费）。

PG多年来在 GIS（地理信息）领域处于优势地位，因为它有丰富的几何类型，PG有大量字典，数组，bitmap等数据类型，相比之下 MySQL就差很多， Instagram就是因为 PG的空间数据库 扩展 POSTGIS远远强于 MySQL的 my spatial 而采用 PgSQL的。

PG的“无锁定”特性非常突出，甚至包括 vacuum这样的整理数据空间的操作，这个和PGSQL的MVCC实现有关系。

PG可以使用函数 和 条件索引，这使得 PG数据库的调优非常灵活， MySQL就没有这个功能，条件索引在 web应用中 很重要。

PG有极其强悍的 SQL编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（Oracle的叫法，PG里叫Window函数），还可以用多种语言来写存储过程，对于 R的支持也很好。这一点MySQL就差很多，很多分析功能都不支持，腾讯内部的存储主要是 MySQL，但是数据分析主要是 Hadoop+ PgSQL。

PG的有多种集群架构可以选择，plproxy可以之hi语句级的镜像或分片，slony可以进行字段级的同步配置，standby 可以构建 WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便。

一般关系型数据库字符串有长度限制 8k 左右，无限长 TEXT类型的功能受限，只能作为外部大数据访问。而 PG 的 TEXT 类型 可以直接访问且无长度限制， SQL语法内置 正则表达式，可以索引，还可以全文检索，或使用 xml xpath。用 PG的话，文档数据库都可以省了。

PgSQL对于 numa 架构的支持比 MySQL强一些，比 MySQL对于读的性能更好一些， PgSQL提交可以完全异步提交，而 MySQL的内存表不够实用（因为表锁的原因）。

pgsql除了存储正常的数据类型外，还支持存储
array，不管是一维数组还是多维数组均支持。
json和jsonb，相比使用 text存储要高效很多。
json和 jsonb在更高的层面上看起来几乎是一样的，但是存储实现上是不同的。
json存储完的文本，json列会每次都解析存储的值，它不支持索引，但 可以为创建表达式索引。
jsonb存储的二进制格式，避免了重新解析数据结构。它支持索引，这意味着 可以不使用指定索引就能查询任何路径。
当我们比较写入数据速度时，由于数据存储 的方式的原因，jsonb会比 json 稍微的慢一点。json列会每次都 解析存储的值，这意味着键的顺序要和输入的 时候一样。但是 jsonb不同，以二进制格式存储且不保证键的顺序。因此如果有软件需要依赖键的顺序，jsonb可能不是最佳选择。使用 jsonb的优势还在于可以轻易的整合关系型数据和非关系型 数据 ，PostgreSQL对于 mongodb这类数据库是一个不小的威胁，毕竟如果一个表中只有一列数据的类型是半结构化的，没有必要为了迁就它而整个表的设计都采用 schemaless的结构。

1. CPU限制
PGSQL
没有CPU核心数限制，有多少CPU核就用多少

MySQL
能用128核CPU，超过128核用不上
2. 配置文件参数
PGSQL
一共有255个参数，用到的大概是80个，参数比较稳定，用上个大版本配置文件也可以启动当前大版本数据库

MySQL
一共有707个参数，用到的大概是180个，参数不断增加，就算小版本也会增加参数，大版本之间会有部分参数不兼容情况
3. 第三方工具依赖情况
PGSQL
只有高可用集群需要依靠第三方中间件，例如：patroni+etcd、repmgr

MySQL
大部分操作都要依靠percona公司的第三方工具（percona-toolkit，XtraBackup），工具命令太多，学习成本高，高可用集群也需要第三方中间件，官方MGR集群还没成熟
4. 高可用主从复制底层原理
PGSQL
物理流复制，属于物理复制，跟SQL Server镜像/AlwaysOn一样，严格一致，没有任何可能导致不一致，性能和可靠性上，物理复制完胜逻辑复制，维护简单

MySQL
主从复制，属于逻辑复制，（sql_log_bin、binlog_format等参数设置不正确都会导致主从不一致）
大事务并行复制效率低，对于重要业务，需要依赖 percona-toolkit的pt-table-checksum和pt-table-sync工具定期比较和修复主从一致
主从复制出错严重时候需要重搭主从
MySQL的逻辑复制并不阻止两个不一致的数据库建立复制关系
5. 从库只读状态
PGSQL
系统自动设置从库默认只读，不需要人工介入，维护简单

MySQL
从库需要手动设置参数super_read_only=on，让从库设置为只读，super_read_only参数有bug，链接：https://jiahao..com/s?id=1636644783594388753&wfr=spider&for=pc
6. 版本分支
PGSQL
只有社区版，没有其他任何分支版本，PGSQL官方统一开发，统一维护，社区版有所有功能，不像SQL Server和MySQL有标准版、企业版、经典版、社区版、开发版、web版之分
国内外还有一些基于PGSQL做二次开发的数据库厂商，例如：Enterprise DB、瀚高数据库等等，当然这些只是二次开发并不算独立分支

MySQL
由于历史原因，分裂为三个分支版本，MariaDB分支、Percona分支 、Oracle官方分支，发展到目前为止各个分支基本互相不兼容
Oracle官方分支还有版本之分，分为标准版、企业版、经典版、社区版
7. SQL特性支持
PGSQL
SQL特性支持情况支持94种，SQL语法支持最完善，例如：支持公用表表达式（WITH查询）

MySQL
SQL特性支持情况支持36种，SQL语法支持比较弱，例如：不支持公用表表达式（WITH查询）

关于SQL特性支持情况的对比，可以参考：http://www.sql-workbench.net/dbms_comparison.html
8. 主从复制安全性
PGSQL
同步流复制、强同步（remote apply)、高安全，不会丢数据
PGSQL同步流复制：所有从库宕机，主库会罢工，主库无法自动切换为异步流复制（异步模式），需要通过增加从库数量来解决，一般生产环境至少有两个从库
手动解决：在PG主库修改参数synchronous_standby_names =''，并执行命令： pgctl reload ，把主库切换为异步模式
主从数据完全一致是高可用切换的第一前提，所以PGSQL选择主库罢工也是可以理解

MySQL
增强半同步复制 ，mysql5.7版本增强半同步才能保证主从复制时候不丢数据
mysql5.7半同步复制相关参数：
参数rpl_semi_sync_master_wait_for_slave_count 等待至少多少个从库接收到binlog，主库才提交事务，一般设置为1，性能最高
参数rpl_semi_sync_master_timeout 等待多少毫秒，从库无回应自动切换为异步模式，一般设置为无限大，不让主库自动切换为异步模式
所有从库宕机，主库会罢工，因为无法收到任何从库的应答包
手动解决：在MySQL主库修改参数rpl_semi_sync_master_wait_for_slave_count=0
9. 多字段统计信息
PGSQL
支持多字段统计信息

MySQL
不支持多字段统计信息
10. 索引类型
PGSQL
多种索引类型（btree , hash , gin , gist , sp-gist , brin , bloom , rum , zombodb , bitmap，部分索引，表达式索引）

MySQL
btree 索引，全文索引（低效），表达式索引(需要建虚拟列)，hash 索引只在内存表
11. 物理表连接算法
PGSQL
支持 nested-loop join 、hash join 、merge join

MySQL
只支持 nested-loop join
12. 子查询和视图性能
PGSQL
子查询，视图优化，性能比较高

MySQL
视图谓词条件下推限制多，子查询上拉限制多
13. 执行计划即时编译
PGSQL
支持 JIT 执行计划即时编译，使用LLVM编译器

MySQL
不支持执行计划即时编译
14. 并行查询
PGSQL
并行查询（多种并行查询优化方法），并行查询一般多见于商业数据库，是重量级功能

MySQL
有限，只支持主键并行查询
15. 物化视图
PGSQL
支持物化视图

MySQL
不支持物化视图
16. 插件功能
PGSQL
支持插件功能，可以丰富PGSQL的功能，GIS地理插件，时序数据库插件， 向量化执行插件等等

MySQL
不支持插件功能
17. check约束
PGSQL
支持check约束

MySQL
不支持check约束，可以写check约束，但存储引擎会忽略它的作用，因此check约束并不起作用（mariadb 支持）
18. gpu 加速SQL
PGSQL
可以使用gpu 加速SQL的执行速度

MySQL
不支持gpu 加速SQL 的执行速度
19. 数据类型
PGSQL
数据类型丰富，如 ltree，hstore，数组类型，ip类型，text类型，有了text类型不再需要varchar，text类型字段最大存储1GB

MySQL
数据类型不够丰富
20. 跨库查询
PGSQL
不支持跨库查询，这个跟Oracle 12C以前一样

MySQL
可以跨库查询
21. 备份还原
PGSQL
备份还原非常简单，时点还原操作比SQL Server还要简单，完整备份+wal归档备份（增量）
假如有一个三节点的PGSQL主从集群，可以随便在其中一个节点做完整备份和wal归档备份

MySQL
备份还原相对不太简单，完整备份+binlog备份（增量）
完整备份需要percona的XtraBackup工具做物理备份，MySQL本身不支持物理备份
时点还原操作步骤繁琐复杂
22. 性能视图
PGSQL
需要安装pg_stat_statements插件，pg_stat_statements插件提供了丰富的性能视图：如：等待事件，系统统计信息等
不好的地方是，安装插件需要重启数据库，并且需要收集性能信息的数据库需要执行一个命令：create extension pg_stat_statements命令
否则不会收集任何性能信息，比较麻烦

MySQL
自带PS库，默认很多功能没有打开，而且打开PS库的性能视图功能对性能有影响（如：内存占用导致OOM bug）
23. 安装方式
PGSQL
有各个平台的包rpm包，deb包等等，相比MySQL缺少了二进制包，一般用源码编译安装，安装时间会长一些，执行命令多一些

MySQL
有各个平台的包rpm包，deb包等等，源码编译安装、二进制包安装，一般用二进制包安装，方便快捷
24. DDL操作
PGSQL
加字段、可变长字段类型长度改大不会锁表，所有的DDL操作都不需要借助第三方工具，并且跟商业数据库一样，DDL操作可以回滚，保证事务一致性

MySQL
由于大部分DDL操作都会锁表，例如加字段、可变长字段类型长度改大，所以需要借助percona-toolkit里面的pt-online-schema-change工具去完成操作
将影响减少到最低，特别是对大表进行DDL操作
DDL操作不能回滚
25. 大版本发布速度
PGSQL
PGSQL每年一个大版本发布，大版本发布的第二年就可以上生产环境，版本迭代速度很快
PGSQL 9.6正式版推出时间：2016年
PGSQL 10 正式版推出时间：2017年
PGSQL 11 正式版推出时间：2018年
PGSQL 12 正式版推出时间：2019年

MySQL
MySQL的大版本发布一般是2年~3年，一般大版本发布后的第二年才可以上生产环境，避免有坑，版本发布速度比较慢
MySQL5.5正式版推出时间：2010年
MySQL5.6正式版推出时间：2013年
MySQL5.7正式版推出时间：2015年
MySQL8.0正式版推出时间：2018年
26. returning语法
PGSQL
支持returning语法，returning clause 支持 DML 返回 Resultset，减少一次 Client <-> DB Server 交互

MySQL
不支持returning语法
27. 内部架构
PGSQL
多进程架构，并发连接数不能太多，跟Oracle一样，既然跟Oracle一样，那么很多优化方法也是相通的，例如：开启大页内存

MySQL
多线程架构，虽然多线程架构，但是官方有限制连接数，原因是系统的并发度是有限的，线程数太多，反而系统的处理能力下降，随着连接数上升，反而性能下降
一般同时只能处理200 ~300个数据库连接
28. 聚集索引
PGSQL
不支持聚集索引，PGSQL本身的MVCC的实现机制所导致

MySQL
支持聚集索引
29. 空闲事务终结功能
PGSQL
通过设置 idle_in_transaction_session_timeout 参数来终止空闲事务，比如：应用代码中忘记关闭已开启的事务，PGSQL会自动查杀这种类型的会话事务

MySQL
不支持终止空闲事务功能
30. 应付超大数据量
PGSQL
不能应付超大数据量，由于PGSQL本身的MVCC设计问题，需要垃圾回收，只能期待后面的大版本做优化

MySQL
不能应付超大数据量，MySQL自身架构的问题
31. 分布式演进
PGSQL
HTAP数据库：cockroachDB、腾讯Tbase
分片集群： Postgres-XC、Postgres-XL

MySQL
HTAP数据库：TiDB
分片集群： 各种各样的中间件，不一一列举
32. 数据库的文件名和命名规律
PGSQL
PGSQL在这方面做的比较不好，DBA不能在操作系统层面（停库状态下）看清楚数据库的文件名和命名规律，文件的数量，文件的大小
一旦操作系统发生文件丢失或硬盘损坏，非常不利于恢复，因为连名字都不知道
PGSQL表数据物理文件的命名/存放规律是： 在一个表空间下面，如果没有建表空间默认在默认表空间也就是base文件夹下，例如：/data/base/16454/3599
base：默认表空间pg_default所在的物理文件夹
16454：表所在数据库的oid
3599：就是表对象的oid，当然，一个表的大小超出1GB之后会再生成多个物理文件，还有表的fsm文件和vm文件，所以一个大表实际会有多个物理文件
由于PGSQL的数据文件布局内容太多，大家可以查阅相关资料
当然这也不能全怪PGSQL，作为一个DBA，时刻做好数据库备份和容灾才是正道，做介质恢复一般是万不得已的情况下才会做

MySQL
数据库名就是文件夹名，数据库文件夹下就是表数据文件，但是要注意表名和数据库名不能有特殊字符或使用中文名，每个表都有对应的frm文件和ibd文件，存储元数据和表/索引数据，清晰明了，做介质恢复或者表空间传输都很方便
33. 权限设计
PGSQL
PGSQL在权限设计这块是比较坑爹，抛开实例权限和表空间权限，PGSQL的权限层次有点像SQL Server，db=》schema=》object
要说权限，这里要说一下Oracle，用Oracle来类比
在ORACLE 12C之前，实例与数据库是一对一，也就是说一个实例只能有一个数据库，不像MySQL和SQL Server一个实例可以有多个数据库，并且可以随意跨库查询
而PGSQL不能跨库查询的原因也是这样，PGSQL允许建多个数据库，跟ORACLE类比就是有多个实例（之前说的实例与数据库是一对一）
一个数据库相当于一个实例，因为PGSQL允许有多个实例，所以PGSQL单实例不叫一个实例，叫集簇（cluster），集簇这个概念可以查阅PGSQL的相关资料
PGSQL里面一个实例/数据库下面的schema相当于数据库，所以这个schema的概念对应MySQL的database
注意点：正因为是一个数据库相当于一个实例，PGSQL允许有多个实例/数据库，所以数据库之间是互相逻辑隔离的，导致的问题是，不能一次对一个PGSQL集簇下面的所有数据库做操作
必须要逐个逐个数据库去操作，例如上面说到的安装pg_stat_statements插件，如果您需要在PGSQL集簇下面的所有数据库都做性能收集的话，需要逐个数据库去执行加载命令
又例如跨库查询需要dblink插件或fdw插件，两个数据库之间做查询相当于两个实例之间做查询，已经跨越了实例了，所以需要dblink插件或fdw插件，所以道理非常简单
权限操作也是一样逐个数据库去操作，还有一个就是PGSQL虽然像SQL Server的权限层次结构db=》schema=》object，但是实际会比SQL Server要复杂一些，还有就是新建的表还要另外授权
在PGSQL里面，角色和用户是一样的，对新手用户来说有时候会傻傻分不清，也不知道怎么去用角色，所以PGSQL在权限设计这一块确实比较坑爹

MySQL
使用mysql库下面的5个权限表去做权限映射，简单清晰，唯一问题是缺少权限角色
user表
db表
host表
tables_priv表
columns_priv表

1. 架构对比
Mysql：多线程
PostgreSql：多进程
多线程架构和多进程架构之间没有绝对的好坏，例如oracle在unix上是多进程架构，在windows上是多线程架构。

2. 对存储过程及事务的支持能力
MySql对于无事务的MyISAM表，采用表锁定，一个长时间运行的查询很可能会长时间的阻碍，而PostgreSQL不会尊在这种问题。
PostgreSQL支持存储过程，要比MySql好，具备本地缓存执行计划的能力。

3. 稳定性及性能
高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySql 明显出现一个波峰后下滑（5.5版本后Mysql企业版有优化，需要付费）
MySql的InnoDB引擎，可以充分优化利用系统的所有内存，超大内存下PG对内存使用的不那么充分（需要根据内存情况合理分配）。

4. 高可用
InnoDB的基于回滚实现的 MVCC 机制，对于 PG 新老数据一起放的基于 XID 的 MVCC机制，是占优的。新老数据一起存放，需要定时触发 VACUUM，会带来多余的 IO 和数据库对象加锁开销，引起数据库整理的并发能力下降。而且 VACUUM 清理不及时，还可能会引发数据膨胀

5. 数据同步方式：
Mysql到现在也是异步复制，pgsql可以做到同步、异步、半同步复制。
Mysql同步是基于binlog复制，属于逻辑复制，类似于oracle golden gate，是基于stream的复制，做到同步很困难，这种方式更加适合异步复制；
Pgsql的同是基于wal，属于物理复制，可以做到同步复制。同时，pgsql还提供stream复制。
Mysql的复制可以用多级从库，但是在9.2之前，PgSql不能用从库带从库。
Pgsql的主从复制属于物理复制，相对于Mysql基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。

6. 权限控制对比
MySql允许自定义一套不同的数据级、表级和列的权限，运行指定基于主机的权限
Mysql的merge表提供了 一个独特管理多个表的方法。myisampack可以对只读表进行压缩，以后仍然可以直接访问该表中的行。

7. SQL语句支持能力
PG有极其强悍的 SQL 编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，例如分析函数（Oracle的叫法，PG里叫window函数）
支持用多种语言来写存储过程，对于R的支持也很好。这一点上Mysql就差的很远，很多分析功能都不支持。
PgSql对表名大小写的处理，只有在Sql语句中，表明加双引号，才区分大小写。
在Sql的标准实现上要比Mysql完善，而且功能实现比较严谨。
对表连接支持比较完整，优化器的功能比较完整，支持的索引类型很多，复杂查询能力较强。
Mysql采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结果设计存在约束；
Mysql的Join操作的性能非常的差，只支持Nest Join，所以一旦数据量大，性能就非常的差。PostgresSQL除了支持 Nest Join 和 Sort Merge Join，PostgreSQL还支持正则表达式查询，MySql不支持。

8. 数据类型支持能力
PostgreSQL可以更方便的使用UDF（用户定义函数）进行扩展。
有丰富的几何类型，实际上不止集合类型，PG有大量的字典、数组、bitmap等数据类型，因此PG多年来在 GIS 领域处于优势地位。相比之下Mysql就差很多，instagram就是因为PG的空间数据扩展 PostGIS远远强于 MySql的 my spatial 而采用 PgSql的。Mysql中的空间数据类型有4种，分别是 CEOMETRY、POINT、LINESTRING、POLYGON，其空间索引只能在存储引擎为 MyiSam的表中创建，用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL。不同的存储亲情有差别。MyISAM和InnoDB 都支持 spatial extensions，但差别在于：如果使用MyISAM，可以建立 spatial index，而 InnoDB是不支持的。
pgsql对json支持比较好，还有很逆天的fdw功能，就是把别的数据库中的表当自己的用。
pgsql的字段类型支持的多，有很多mysql没有的类型，但是实际中有时候用到。
一半关系型数据库的字符串长度8k左右，无限长的 TEXT 类型的功能受限，只能作为外部带数据访问。而 PG 的 TEXT 类型可以直接访问，SQL 语法内置正则表达式，可以索引，还可以全文检索，或使用 xml xpath。用 PG 的话，文档数据库都可以省了。
postgresql 有函数，用于报表、统计很方便
PG支持 R-Trees这样可扩展的索引类型，可以方便的处理一些特殊数据。
PG可以使用函数和条件所以，使得数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。

9. 如可过程容错能力
大批量数据入库，PostgreSql要求所有的数据必须完全满足要求，有一条错误，整个数据入库过程失败。MySql无此问题。

10. 表组织方式
pgsql用继承的方式实现分区表，让分区表的使用不方便且性能差，这点比不上mysql。
pg主表采用堆表存放，MySQL采用索引组织表，能够支持比MySql更大的数据量。
MySql分区表的实现要优于PG的基于继承表的分区实现，主要体现在分区个数达到成千上万后的处理性能差异很大。

11. 开发结构
对于web应用来所，mysql 5.6 的内置 MC API 功能很好用，PgSQL差一些。
PG的“无锁定”特性非常突出，甚至包括 vacuum 这样的整理数据空间的操作，这个和 PGSQL的 MVCC 实现有关系。

好文要顶 关注我 收藏该文
茄子777
粉丝 - 0 关注 - 0
+加关注
00
« 上一篇： 多线程中的wait与join
» 下一篇： 负载均衡相关
posted @ 2022-11-02 16:20 茄子777 阅读(55) 评论(0) 编辑 收藏 举报
刷新评论刷新页面返回顶部
登录后才能查看或发表评论，立即 登录 或者 逛逛 博客园首页
【推荐】阿里云新人特惠，爆款云服务器2核4G低至0.46元/天
【推荐】双十一同价！腾讯云云服务器抢先购，低至4.2元/月
编辑推荐：
· 一个有趣的 nginx HTTP 400 响应问题分析
· 谁说.NET没有GC调优？只改一行代码就让程序不再占用内存
· 为什么标准库的模板变量都是 inline 的
· .net 如何优雅的使用 EFCore
· 在 C# 中使用 Halcon 开发视觉检测程序
阅读排行：
· Entity Framework Core 7中高效地进行批量数据插入
· 除了 filter 还有什么置灰网站的方式？
· 快速绘制流程图“GitHub 热点速览 v.22.47”
· 使用.NET7和C#11打造最快的序列化程序-以MemoryPack为例
· 私藏！资深数据专家SQL效率优化技巧 ⛵

D. 在postgresql中创建带游标的存储过程（function)

在postgresql中创建带游标的存储过程（function)
一般在plsql中执行存储过程的方式有两种，一种是带参数的 begin 存储过程名(参数1,参数2...); end; 另一种是不带参数的 begin 存储过程名; end; 注意标点的写法，都是英文写法的

E. 如何扩大postgresql存储空间

1. 概述
cstore_fdw实现了 PostgreSQL 数据库的列式存储。列存储非常适合用于数据分析的场景，数据分析的场景下数据是批量加载的。
这个扩展使用了Optimized Row Columnar (ORC)数据存储格式，ORC改进了Facebook的RCFile格式，带来如下好处:

压缩:将内存和磁盘中数据大小削减到2到4倍。可以扩展以支持不同压缩算法。
列投影:只提取和查询相关的列数据。提升IO敏感查询的性能。
跳过索引:为行组存储最大最小统计值，并利用它们跳过无关的行。
2. 使用
cstore_fdw的安装和使用都非常简单，可以参考官方资料。
thub.com/citusdata/cstore_fdw

注)注意cstore_fdw只支持PostgreSQL9.3和9.4 。

下面做几个简单的性能对比，看看cstore_fdw究竟能带来多大的性能提升。

2.1 数据加载
2.1.1 普通表
CREATE TABLE tb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
);

注:要和普通表的全表扫描作对比，所以不建主键和索引。

[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c " tb1 from STDIN with CSV"
COPY 10000000
1.56user 1.00system 6:42.39elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
776inputs+0outputs (17major+918minor)pagefaults 0swaps

real 6m42.402s
user 0m15.174s
sys 0m14.904s

postgres=# select pg_total_relation_size('tb1'::regclass);
pg_total_relation_size
------------------------
1161093120
(1 row)

postgres=# \timing
Timing is on.
postgres=# analyze tb1;
ANALYZE
Time: 11985.070 ms

插入1千万条记录，数据占用存储大小1.16G，插入耗时6分42秒，分析耗时12秒。

2.1.2 cstore表
$ mkdir -p /home/chenhj/data94/cstore

CREATE EXTENSION cstore_fdw;
CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;
CREATE FOREIGN TABLE cstb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
)
SERVER cstore_server
OPTIONS(filename '/home/chenhj/data94/cstore/cstb1.cstore',
compression 'pglz');

[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text, www.hnne.com id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c " cstb1 from STDIN with CSV"
COPY 10000000
1.53user 0.78system 7:35.15elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
968inputs+0outputs (20major+920minor)pagefaults 0swaps

real 7m35.520s
user 0m14.809s
sys 0m14.170s

[postgres@node2 chenhj]$ ls -l /home/chenhj/data94/cstore/cstb1.cstore
-rw------- 1 postgres postgres 389583021 Jun 23 17:32 /home/chenhj/data94/cstore/cstb1.cstore

postgres=# \timing
Timing is on.
postgres=# analyze cstb1;
ANALYZE
Time: 5946.476 ms

插入1千万条记录，数据占用存储大小390M，插入耗时7分35秒，分析耗时6秒。
使用cstore列存储后，数据占用存储大小降到普通表的3分之1。需要说明的是，由于所有TEXT列填充了随机数据，压缩率不算高，某些实际的应用场景下压缩效果会比这更好。

2.2 Text列的like查询性能对比
2.2.1 普通表
清除文件系统缓存，并重启PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart

[root@node2 ~]# free
total used free shared buffers cached
Mem: 2055508 771356 1284152 0 9900 452256
-/+ buffers/cache: 309200 1746308
Swap: 4128760 387624 3741136
[root@node2 ~]# echo 1 > /proc/sys/vm/drop_caches
[root@node2 ~]# free
total used free shared buffers cached
Mem: 2055508 326788 1728720 0 228 17636
-/+ buffers/cache: 308924 1746584
Swap: 4128760 381912 3746848

对Text列执行like查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.42 0.00 95.40

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.55 330.68 212.08 7351441 4714848

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)

real 0m7.051s
user 0m0.001s
sys 0m0.004s

[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.39

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.90 381.53 211.90 8489597 4714956

耗时7.1秒，产生IO读1.14G,IO写108K。

不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.6秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.39

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.81 332.20 213.06 7350301 4714364

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)

real 0m1.601s
user 0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.43 0.00 95.38

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.80 332.12 213.01 7350337 4714364

2.2.2 cstore表
清除文件系统缓存，并重启PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 > /proc/sys/vm/drop_caches

对Text列执行like查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.38 0.00 95.45

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.12 376.42 209.04 8492017 4716048

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)

real 0m2.786s
user 0m0.002s
sys 0m0.003s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.38 0.00 95.44

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 58.12 378.75 208.89 8550761 4716048

耗时2.8秒，产生IO读59M,IO写0K。执行时间优化的虽然不是太多，但IO大大减少，可见列投影起到了作用。

不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.4秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.36 0.00 95.47

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.75 376.33 207.58 8550809 4716524

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)

real 0m1.424s
user 0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.38 3.36 0.00 95.47

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.70 375.96 207.38 8550809 4716588

2.3 对Int列执行=查询
2.3.1 普通表
清除文件系统缓存，并重启PostgreSQL后
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 > /proc/sys/vm/drop_caches

对Int列执行=查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.33 0.00 95.50

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.25 373.21 205.67 8560897 4717624

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------
1
(1 row)

real 0m6.844s
user 0m0.002s
sys 0m0.006s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.34 0.00 95.49

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.60 422.57 205.54 9699161 4717708

耗时6.8秒，产生IO读1.14G,IO写84K
不清缓存，再执行一次。消耗时间降到1.1秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.79 0.00 0.37 3.33 0.00 95.50

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
dm-2 57.44 421.37 204.97 9699177 4718032

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------

F. 三分钟！彻底搞懂PostgreSQL 和 MySQL 区别之分

PostgreSQL 和 MySQL 是将数据组织成表的关系数据库。这些表可以根据每个表共有的数据链接或关联。关系数据库使您的企业能够更好地了解可用数据之间的关系，并帮助获得新的见解以做出更好的决策或发现新的机会。

PostgreSQL 和 MySQL 都依赖于 SQL（结构化查询语言），这是与管理系统交互的标准语言。SQL 允许使用具有简单结构的几行源代码连接表，大多数非技术员工可以快速学习。

使用 SQL，分析师不需要知道订单表在磁盘上的位置、如何执行查找以查找特定订单或如何连接订单表和客户表。数据库编译查询并计算出正确的数据点。

MySQL 和 PostgreSQL 都支持 JavaScript Object Notation (JSON) 存储和传输数据，尽管 PostgreSQL 也支持 JSONB，这是 JSON 的二进制版本，它消除了键的重复和无关的空格。

除了传统的支持机制外，这两个数据库都提供强大的社区支持。

PostgreSQL，也称为 Postgres，是一种开源关系数据库，因其可靠性、灵活性和对开放技术标准的支持而享有盛誉。PostgreSQL 支持非关系和关系数据类型。它被称为当今可用的最兼容、最稳定和最成熟的关系数据库之一，并且可以轻松处理复杂的查询。

PostgreSQL 的特性包括：

PostgreSQL 这是一个“一刀切”的解决方案，适用于许多寻求经济高效的方法来改进其数据库管理系统 (DBMS) 的企业。它具有足够的可扩展性和多功能性，可以通过强大的扩展生态系统快速支持各种专业用例，涵盖时间序列数据类型和地理空间分析等工作。作为开源数据库解决方案构建的 PostgreSQL 完全不受许可限制、供应商锁定的可能性或过度部署的风险。PostgreSQL 通过对象关系数据库管理系统 (ORDBMS) 进行管理。

PostgreSQL 负责管理业务活动的在线事务处理 (OLTP)协议的企业数据库管理员提供了理想的解决方案，包括电子商务、客户关系管理系统 (CRM) 和财务分类帐。它也是管理接收、创建和生成的数据分析的理想选择。

这些是 PostgreSQL 的一些主要优点：

MySQL — 一种快速、可靠、可扩展且易于使用的开源关系数据库系统 — 旨在处理关键任务、高负载的生产应用程序。它是一种常见且易于启动的数据库，内存、磁盘和 CPU 利用率较低，有关系数据库管理系统 (RDMS) 管理。MySQL Community Edition 是一个由活跃的在线社区支持的免费下载版本。

MySQL 功能包括所有 SQL 标准命令以及事务和 ACID 合规性（代表原子性、一致性、隔离性和持久性）。

两个最常见的关系数据库是什么 MySQL 和 Oracle。MySQL 不是 SQL Server 的同义词，SQL Server 是 Microsoft 许可产品，与 MAC OS X 缺乏兼容性。

MariaDB 经常与 MySQL 混淆，它是 MySQL 的一个开源分支，速度更快，提供更多存储引擎 (12)，但功能有限。MySQL 和 MariaDB 使用的存储引擎都是 InnoDB。InnoDB 提供标准的 ACID 兼容特性。与 MySQL 不同，MariaDB 不支持数据屏蔽或动态列表。

MySQL 通常用作 Web 数据库来存储各种信息类型，从单个信息数据点到为组织提供的产品或服务的完整列表。它是LAMP（Linux 操作系统、Apache HTTP 服务器、MySQL RDBMS 和 PHP 编程语言）的基础组件，这是一种有助于创建API、Web 应用程序和网站的软件堆栈模型。

MySQL Workbench 是一个单一的、集成的可视化 SQL 平台，用于 MySQL 数据库的创建、开发、设计和管理。

MySQL 为市场提供了许多好处，包括：

PostgreSQL 和 MySQL 之间有很多不同之处。特性、功能和优势方面的一些差异如下：

总之，PostgreSQL 和 MySQL 都有不同的用途，它们之间的选择取决于企业目标和资源。一般来说，PostgreSQL 是一个更强大、更高级的数据库管理系统，非常适合需要在大型环境中快速执行复杂查询的组织。但是，对于预算和空间更受限制的公司来说，MySQL 是一个理想的解决方案。

G. 四、PostgreSQL常用数据类型（精简）

备注：
（1）numeric 不指定长度，可以保留的整数位和小数位很大；
（2）numeric(6,4)表示精度（precision，所有数字位的个数）为6，标度（scale，小数点右边所有小数位的个数）为4，例如23.5141

备注：varchar不指定长度，可以存储最大长度（1GB）

备注：保留两位小数，超过位数采用四舍五入法进行截断

1. https://www.yii.com/postgresql/postgresql-datatypes.html

H. Postgresql存储二进制大数据文件

title: "Postgresql存储二进制大数据文件"
date: 2021-02-02T20:46:31+08:00
draft: true
tags: ['postgres','binary']
author: "dadigang"
author_cn: "大地缸"
personal: " http://www.real007.cn "

http://www.real007.cn/about

如果想把整个文件或图片存储在数据表的一个字段内，该字段可以选择二进制类型，然后将文件按二进制存储起来，文本文件也可以存在text字段内。

示例如下：

二进制类型bytea的操作（在最大值内，有内存限制）

1、 创建表

2、 将文件放到coordinator目录下/mnt/postgresql/coord

通过pg_read_binary_file()函数，插入一张图片- 目录：/mnt/postgresql/coord/1.jpg

3、 也可以调用pg_read _file()将一个文本文件存储在一个text字段内

注意：函数pg_read_binary_file()和pg_read_file()中的路径必须是相对路径，默认路径是coordinator目录下，并且必须在coordinator目录下或者coordinator目录的子目录下。

Name

Return Type

Description

pg_read_file(filename text [, offset bigint, length bigint])

text

Return the contents of a text file

pg_read_binary_file(filename text [, offset bigint, length bigint])

bytea

Return the contents of a file

I. postgresql 查看有哪些表

1. 查询表名称

在psql状态下查询表名称：dt

SQL方式查看表名称：

SELECTtablenameFROMpg_tables;

SELECT viewname FROM pg_views
WHERE schemaname ='public'

PostgreSQL获取数据库中所有view名视图

SELECT viewname FROM pg_views

WHERE schemaname ='public'

2. 查询表结构

在psql状态下查询表结构 dtablename

SQL方式查看表结构

SELECT a.attnum,

a.attname AS field,

t.typname AS type,

a.attlen AS length,

a.atttypmod AS lengthvar,

a.attnotnull AS notnull,

b.description AS comment

FROM pg_class c,

pg_attribute a

LEFT OUTER JOIN pg_description b ON a.attrelid=b.objoid AND a.attnum = b.objsubid,
pg_type t

WHERE c.relname = 'udoc_saldiscount'

and a.attnum > 0

and a.attrelid = c.oid

and a.atttypid = t.oid

ORDER BY a.attnum;

(9)postgresql的存储方式有几种扩展阅读：

PostgreSQL存储系统是由以下几个子模块所构成的：

1）页面管理子模块：对PostgreSQL缓冲区页面的组织结构进行定义以及提供页面操作的方法。

2）缓冲区管理子模块：管理PostgreSQL的缓冲区，包括本地缓冲区和共享缓冲区。

3）存储设备管理子模块：数据库记录是存储在存储介质上的，存储设备管理子模块将屏蔽不同物理存储设备（块设备，流设备）接口函数的差异，向上层缓冲区管理子模块提供统一的访问接口函数。

4）文件管理子模块：一般的操作系统对一个进程允许打开的文件数是有限制的，而PostgreSQL服务器有些时候需要打开的文件数是很多的，因此PostgreSQL文件管理子模块自身为了突破这个瓶颈，封装了文件的读写操作。