一、 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),并发写入会导致频繁的磁头移动,效率奇差、损害硬盘寿命,降低稳定性。