包含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: 北大青鸟java培训：数据库的种类有哪些？

很长时间以来，关系型数据库一直是大公司的专利，市场被Oracle/DB2等企业数据库牢牢把持。

但是随着互联网的崛起、开源社区的发展，上世纪九十年代MySQL1.0的发布，标志着关系型数据库的领域社区终于有可选择的方案。

MySQL第一个介绍的单机RDBMS就是MySQL。

相信大多数朋友都已经对MySQL非常熟悉，基本上MySQL的成长史就是互联网的成长史。

我接触的第一个MySQL版本是MySQL4.0，到后来的MySQL5.5更是经典——基本所有的互联网公司都在使用。

MySQL也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是MySQLtuning的一个重要的方式。

比如对于有事务需求的场景使用InnoDB;对于并发读取的场景MyISAM可能比较合适;但是现在我推荐绝大多数情况还是使用InnoDB，毕竟5.6后已经成为了官方的默认引擎。

大多数朋友都基本知道什么场景适用MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。

另外值得一提的是MySQL5.6中引入了多线程复制和GTID，使得故障恢复和主从的运维变得比较方便。

另外，5.7(目前处于GA版本)是MySQL的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。

MySQL5.7MTS支持两种模式，一种是和5.6一样，另一种则是基于binloggroupcommit实现的多线程复制，也就是MASTER上同时提交的binlog在SLE端也可以同时被apply，实现并行复制)。

如果有单机数据库技术选型的朋友，基本上只需要考虑5.7或者MariaDB就好了，而且5.6、5.7由Oracle接手后，性能和稳定性上都有了明显的提升。

PostgreSQLPostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的MichaelStronebraker于2015年获得图灵奖。

后来项目更名为Post-Ingres，项目基于BSDlicense下开源。

1995年几个UCB的学生为Post-Ingres开发了SQL的接口，正式发布了PostgreSQL95，随后一步步在开源社区中成长起来。

和MySQL一样，PostgreSQL也是一个单机的关系型数据库，但是与MySQL方便用户过度扩展的SQL文法不一样的是，PostgreSQL的SQL支持非常强大，不管是内置类型、JSON支持、GIS类型以及对于复杂查询的支持，PL/SQL等都比MySQL强大得多，而且从代码质量上来看，PostgreSQL的代码质量是优于MySQL的，另外相对于MySQL5.7以前的版本，PostgreSQL的SQL优化器比MySQL强大很多，几乎所有稍微复杂的查询PostgreSQL的表现都优于MySQL。

从近几年的趋势上来看，PostgreSQL的势头也很强劲，我认为PostgreSQL的不足之处在于没有MySQL那样强大的社区和群众基础。

MySQL经过那么多年的发展，积累了很多的运维工具和最佳实践，但是PostgreSQL作为后起之秀，拥有更优秀的设计和更丰富的功能。

电脑培训发现PostgreSQL9以后的版本也足够稳定，在做新项目技术选型的时候，是一个很好的选择。

另外也有很多新的数据库项目是基于PostgreSQL源码的基础上进行二次开发，比如Greenplum等。

Q2: 为什么PostgreSQL比MongoDB还快

PostgreSQL9.4带来了全新的NoSQL特性，并且根据EnterpriseDB的测试，其加载，插入和查询的性能都已经几倍于MongoDB了。

虽然我是PG的铁杆粉丝，但是关系数据库背负了ACID的重型装甲，在性能上居然能打败轻装上阵的NoSQL数据库总觉得有点离谱。

所以我在自己的环境里验证了一下EnterpriseDB的测试结果，并且小探一下PG取胜的原因。

1. EnterpriseDB的测试结果

以下是EnterpriseDB的测试结果(数据量为5000万)

（还可以参考这篇译文： ）

2. 我的验证结果

测试观点

为了使测试结果更加单纯，我准备单纯比拼CPU消耗(尽量排除IO和网络的干扰)，设定以下测试条件。

1）所有数据都要放进内存

2）C/S都跑在同一台单机上

所以，只在单机上进行10万条小数据量的测试。

注）EnterpriseDB的测试环境是32G内存的Amazon Web Services M3.2XLARGE实例，总数据量超过内存了。

测试环境

测试环境为个人PC上的VMware虚拟机

PC

CPU:Intel Core i5-3470 3.2G(4核)

MEM:6GB

SSD:OCZ-VERTEX4 128GB(VMware虚拟机所在磁盘，非系统盘)

OS:Win7

VMware虚拟机

CPU:4核

MEM:1GB

OS:CentOS 6.5

PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默认值)

MG:MongoDB 3.0.2

测试步骤

测试步骤非常简单,可以参考：

但是，在测试前，有些东西要改。

1)把数据量减小到10万

pg_nosql_benchmark-master/pg_nosql_benchmark:

declare -a json_rows=(10000000)

==

declare -a json_rows=(100000)

2)修改mongo的一处脚本(注)

pg_nosql_benchmark-master/lib/mongo_func_lib.sh:

collectionsize="$(echo ${output}|awk -F"," '{print $5}'|cut -d":" -f2)"

==

collectionsize="$(echo ${output}|awk -F"," '{print $6}'|cut -d":" -f2)"

注)pg_nosql_benchmark原来是基于MongoDB 2.6设计的，MongoDB 3.0的db.json_tables.stats()输出可能变了，所以这边要修改一下。

Q3: PostgreSQL部署 - 单机流复制

创建主备的环境变量文件, 因为是在同一台机上起两个PG实例, 环境变量要各自设置。

vi master.env

vi slave.env

新开一个shell终端(后续称为 terminal_master )

新开一个shell终端(后续称为 terminal_slave )

经过上面几步, 一个一主一备的集群就搭建好了, 下面开始验证流复制是否工作正常。

切换到 terminal_master 终端

切换到 terminal_slave 终端

一个false一个tree, 证明目前主备状态正常。

切换到 terminal_slave 终端

切换到 terminal_master 终端

切换到 terminal_slave 终端

DDL能顺利同步。

切换到 terminal_slave 终端

切换到 terminal_master 终端

切换到 terminal_slave 终端

切换到 terminal_master 终端

切换到 terminal_slave 终端

切换到 terminal_master 终端

主备切换完成, 且数据同步工作正常。

目前虽然工作正常, 但是角色是互换了的, 后续可以停掉 slave ,再做一次主备切换, 恢复成原始状态。

这个就作为练习了, 不再贴出操作步骤。

目前是靠手工切换主备的, 线上系统一般都要配置成自动切换, 这个时候就需要引入一些其他手段了, 譬如 patroni 之类的HA工具。

Q4: postgreSQL，遇到can't have more than 2048 different append-only tables open for writing data at the

打开 poetgresql.conf (GreenPlum里要搜搜max_appendonly_tables,看看到底在哪里）, 找到 max_appendonly_tables =

这一行，删除#注释，而后改大。这个错误是同时刻打开了2048个表写入，超过了限制造成的。

ps. 如果是在单机上运行，这是很不推荐的！！因为除非使用固态硬盘（SSD)，并发写入会导致频繁的磁头移动，效率奇差、损害硬盘寿命，降低稳定性。