189 8069 5689
一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。
创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于成都网站建设、成都网站制作、二七网络推广、小程序开发、二七网络营销、二七企业策划、二七品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联公司为所有大学生创业者提供二七建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，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都没有问题。
很长时间以来，关系型数据库一直是大公司的专利，市场被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等。
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()输出可能变了，所以这边要修改一下。
创建主备的环境变量文件, 因为是在同一台机上起两个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工具。
打开 poetgresql.conf (GreenPlum里要搜搜max_appendonly_tables,看看到底在哪里）, 找到 max_appendonly_tables =
这一行，删除#注释，而后改大。这个错误是同时刻打开了2048个表写入，超过了限制造成的。
ps. 如果是在单机上运行，这是很不推荐的！！因为除非使用固态硬盘（SSD)，并发写入会导致频繁的磁头移动，效率奇差、损害硬盘寿命，降低稳定性。