运维postgresql的简单介绍

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

为什么postgrelsql的性能没有mysql好

一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过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 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。

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

九，对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。

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

最后说一下我感觉 PG 不如 MySQL 的地方。

第一，MySQL有一些实用的运维支持，如 slow-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，

第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。

第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.

第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。

另外一些：

pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。

说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。

对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。

另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。

很多pg应用也是24/7的应用，比如skype. 最近几个版本VACUUM基本不影响PGSQL 运行，8.0之后的PGSQL不需要cygwin就可以在windows上运行。

至于说对于事务的支持，mysql和pgsql都没有问题。

相关问答

Q1: mysql和postgresql的区别

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

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

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

最后说一下我感觉 PG 不如 MySQL 的地方。

第一，MySQL有一些实用的运维支持，如 slow-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，

第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。

第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.

第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。

另外一些：

pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。

说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。

对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。

另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。

很多pg应用也是24/7的应用，比如skype. 最近几个版本VACUUM基本不影响PGSQL 运行，8.0之后的PGSQL不需要cygwin就可以在windows上运行。

至于说对于事务的支持，mysql和pgsql都没有问题。

Q2: postgresql 查看表建立哪些索引

在数据库运维工作中，经常会有数据目录使用率较高需要调整的情况，通常会给数据库建立多个表空间，

并分别位于不同的盘上，这时需要做的工作就是调整库中现有表和索引的表空间，下面简单总结下这块维护

工作的内容，以下都是基于 PostgreSQL 9.0.1 做的测试。

一查询某个表所在表空间的简单方法

PostgreSQL 提供类似" \ "命令很方便得到相关信息，命令如下：

skytf= \d test_2

Table "skytf.test_2"

Column | Type | Modifiers

--------+-----------------------+-----------

id | integer |

obj_id | integer | not null

name | character varying(64) |

Indexes:

"idx_hash_name" hash (name)

"idx_test_2" btree (id, obj_id)

Tablespace: "tbs_skytf_idx"

备注：如果这个表的表空间为当前数据库的默认表空间，那么上面则不会显示 Tablespace 信息，

相反，则会显示这张有的表空间，例如上面的表 test_2 的表空间为 tbs_skytf_idx，而

表空间 "tbs_skytf_idx" 不是数据库 skytf 的默认表空间，那么如何查询数据库的默认

表空间呢，可以通过以下命令查询。

--1.1 查询数据库的默认表空间

skytf= select datname,dattablespace from pg_database where datname='skytf';

datname | dattablespace

---------+---------------

skytf | 14203070

(1 row)

skytf= select oid,spcname from pg_tablespace where oid=14203070;

oid | spcname

----------+-----------

14203070 | tbs_skytf

(1 row)

备注：通过以上查出数据库 skytf 的默认表空间为 tbs_skytf。

二批量查询数据库表和索引的表空间

--2.1 查询表和索引所在的表空间

select relname, relkind, relpages,pg_size_pretty(pg_relation_size(a.oid)), tb.spcname

from pg_class a, pg_tablespace tb

where a.reltablespace = tb.oid

and a.relkind in ('r', 'i')

order by a.relpages desc;

备注：上面只取了部分结果，这个查询能够查询表和索引所处的表空间，但是有一点需要注意，这个查询

仅显示表空间不是数据库默认表空间的数据库对像，而我们通常需要查出位于数据库默认表空间的

对像，显然上面的查询不是我们想要的，接下来看另一个查询。

--2.2 查询位于默认数据库表空间的对像

select relname, relkind, relpages,pg_size_pretty(pg_relation_size(a.oid)),reltablespace,relowner

from pg_class a

where a.relkind in ('r', 'i')

and reltablespace='0'

order by a.relpages desc;

备注：这个查询加入限制条件 reltablespace='0'，即可查找出位于当前数据库默认表空间的

数据库表和索引。通常这才是我们想要的结果，接下来可以把部分表转移到其它表空间上去，转移

的方法可以用 "ALTER TABLE move tablespace "或者重建索引移表空间等方法，这里不详细介绍。

--2.3 查询在某个表空间上的对像

select relname, relkind, relpages,pg_size_pretty(pg_relation_size(a.oid)),reltablespace,relowner

from pg_class a, pg_tablespace tb

where a.relkind in ('r', 'i')

and a.reltablespace=tb.oid

and tb.spcname='tablespace_name'

order by a.relpages desc;

--2.4 手册上对于 pgclass 视图的 reltablespace 字段解释

The tablespace in which this relation is stored. If zero, the database is default tablespace is

implied. (Not meaningful if the relation has no on-disk file.)

Q3: MySQL 和 PostgreSQL 哪个更适合做金融数据库

金融数据库的需求：

高效存储和检索大量时间序列数据和横截面数据

这两个数据库都能存储时间序列数据，但不是最高效的。

支持存储和检索大段文本数据

MySQL 和其他大部分关系型数据库的文本检索能力不强，用 LIKE 效率低，只能硬匹配，PgSQL 提供全文检索功能 ( PgSQL 数据类型包含 Text Search Types )，这是 PgSQL 很好的特性，可以充当轻量级搜索引擎。

对R和Python有稳定高效的接口

MySQL 和 PgSQL 这方面都没问题，但如果是 Python3， PgSQL 的 psycopg2（毫无争议的就是这个adapter）稳定高效，而MySQL的 Python3 adapter 比较多，相对没有 Python2 的稳定或高效。

具有一定存储和检索非结构化数据（例如图结构）的能力

一般情况下图形结构不做转换是很难直接存到数据库的吧，我猜你说的非结构化数据是树形结构吧，可以用 JSON 格式存储， MySQL 和 PgSQL 都提供 JSON 格式的存储功能，不同的是 MySQL 5.7 才有这个特性（当前最新版是5.7，也就是说近一两年才有的），而 PgSQL ( 当前最新版是9.6 ) 从 9.2 加入了 JSON Type，这个特性至今已经相当成熟了。另外 JSON 格式不能满足你的话， PgSQL 还提供 XML 格式。

有好用易上手的GUI

Navicat 和 DataGrip 都支持这两个数据库，愿意花钱这个不是问题。

提供远程访问功能

远程访问，这么基本的功能肯定都有，就不用多说了吧

安全性高

这个不好说了，看你们 DBA 和运维的实力咯（不过 MySQL 人好招）

数据库本身有能力处理复杂业务逻辑

MySQL 相对比较适合简单粗暴的业务逻辑

PgSQL 处理复杂业务逻辑有优势

综上， PgSQL 更适合。

Q4: 如何在Kubernetes中部署一个高可用的PostgreSQL集群环境

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。

1、业务流量入口的配置方式

传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。

2、容器隔离带来的监控视野问题

在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。

3、存储在 kubernetes 中，支持配置各种不同的存储。

如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。

4、高可用/备份恢复

kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。

Q5: PostgreSQL游标错误，pgpool和PHP问题，怎么解决

第一，MySQL有一些实用的运维支持，如 slow-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，

第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。

第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.

第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。