為什么postgrelsql的性能沒有mysql好

一、 PostgreSQL 的穩(wěn)定性極強(qiáng)， Innodb 等引擎在崩潰、斷電之類的災(zāi)難場景下抗打擊能力有了長足進(jìn)步，然而很多 MySQL 用戶都遇到過Server級的數(shù)據(jù)庫丟失的場景——mysql系統(tǒng)庫是MyISAM的，相比之下，PG數(shù)據(jù)庫這方面要好一些。

創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、二七網(wǎng)絡(luò)推廣、小程序開發(fā)、二七網(wǎng)絡(luò)營銷、二七企業(yè)策劃、二七品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供二七建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com

二、任何系統(tǒng)都有它的性能極限，在高并發(fā)讀寫，負(fù)載逼近極限下，PG的性能指標(biāo)仍可以維持雙曲線甚至對數(shù)曲線，到頂峰之后不再下降，而 MySQL 明顯出現(xiàn)一個(gè)波峰后下滑（5.5版本之后，在企業(yè)級版本中有個(gè)插件可以改善很多，不過需要付費(fèi)）。

三、PG 多年來在 GIS 領(lǐng)域處于優(yōu)勢地位，因?yàn)樗胸S富的幾何類型，實(shí)際上不止幾何類型，PG有大量字典、數(shù)組、bitmap 等數(shù)據(jù)類型，相比之下mysql就差很多，instagram就是因?yàn)镻G的空間數(shù)據(jù)庫擴(kuò)展POSTGIS遠(yuǎn)遠(yuǎn)強(qiáng)于MYSQL的my spatial而采用PGSQL的。

四、PG 的“無鎖定”特性非常突出，甚至包括 vacuum 這樣的整理數(shù)據(jù)空間的操作，這個(gè)和PGSQL的MVCC實(shí)現(xiàn)有關(guān)系。

五、PG 的可以使用函數(shù)和條件索引，這使得PG數(shù)據(jù)庫的調(diào)優(yōu)非常靈活，mysql就沒有這個(gè)功能，條件索引在web應(yīng)用中很重要。

六、PG有極其強(qiáng)悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸?。蟹浅ＸS富的統(tǒng)計(jì)函數(shù)和統(tǒng)計(jì)語法支持，比如分析函數(shù)（ORACLE的叫法，PG里叫window函數(shù)），還可以用多種語言來寫存儲過程，對于R的支持也很好。這一點(diǎn)上MYSQL就差的很遠(yuǎn)，很多分析功能都不支持，騰訊內(nèi)部數(shù)據(jù)存儲主要是MYSQL，但是數(shù)據(jù)分析主要是HADOOP+PGSQL。

七、PG 的有多種集群架構(gòu)可以選擇，plproxy 可以支持語句級的鏡像或分片，slony 可以進(jìn)行字段級的同步設(shè)置，standby 可以構(gòu)建WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調(diào)整方便，操作非常簡單。

八、一般關(guān)系型數(shù)據(jù)庫的字符串有限定長度8k左右，無限長 TEXT 類型的功能受限，只能作為外部大數(shù)據(jù)訪問。而 PG 的 TEXT 類型可以直接訪問，SQL語法內(nèi)置正則表達(dá)式，可以索引，還可以全文檢索，或使用xml xpath。用PG的話，文檔數(shù)據(jù)庫都可以省了。

九，對于WEB應(yīng)用來說，復(fù)制的特性很重要，mysql到現(xiàn)在也是異步復(fù)制，pgsql可以做到同步，異步，半同步復(fù)制。還有mysql的同步是基于binlog復(fù)制，類似oracle golden gate,是基于stream的復(fù)制，做到同步很困難，這種方式更加適合異地復(fù)制，pgsql的復(fù)制基于wal，可以做到同步復(fù)制。同時(shí)，pgsql還提供stream復(fù)制。

十，pgsql對于numa架構(gòu)的支持比mysql強(qiáng)一些，比MYSQL對于讀的性能更好一些，pgsql提交可以完全異步，而mysql的內(nèi)存表不夠?qū)嵱茫ㄒ驗(yàn)楸礞i的原因）

最后說一下我感覺 PG 不如 MySQL 的地方。

第一，MySQL有一些實(shí)用的運(yùn)維支持，如 slow-query.log ，這個(gè)pg肯定可以定制出來，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分優(yōu)化利用系統(tǒng)所有內(nèi)存，超大內(nèi)存下PG對內(nèi)存使用的不那么充分，

第三點(diǎn)，MySQL的復(fù)制可以用多級從庫，但是在9.2之前，PGSQL不能用從庫帶從庫。

第四點(diǎn)，從測試結(jié)果上看，mysql 5.5的性能提升很大，單機(jī)性能強(qiáng)于pgsql，5.6應(yīng)該會強(qiáng)更多.

第五點(diǎn)，對于web應(yīng)用來說,mysql 5.6 的內(nèi)置MC API功能很好用，PGSQL差一些。

另外一些：

pgsql和mysql都是背后有商業(yè)公司，而且都不是一個(gè)公司。大部分開發(fā)者，都是拿工資的。

說mysql的執(zhí)行速度比pgsql快很多是不對的，速度接近，而且很多時(shí)候取決于你的配置。

對于存儲過程，函數(shù)，視圖之類的功能，現(xiàn)在兩個(gè)數(shù)據(jù)庫都可以支持了。

另外多線程架構(gòu)和多進(jìn)程架構(gòu)之間沒有絕對的好壞，oracle在unix上是多進(jìn)程架構(gòu)，在windows上是多線程架構(gòu)。

很多pg應(yīng)用也是24/7的應(yīng)用，比如skype. 最近幾個(gè)版本VACUUM基本不影響PGSQL 運(yùn)行，8.0之后的PGSQL不需要cygwin就可以在windows上運(yùn)行。

至于說對于事務(wù)的支持，mysql和pgsql都沒有問題。

北大青鳥java培訓(xùn)：數(shù)據(jù)庫的種類有哪些？

很長時(shí)間以來，關(guān)系型數(shù)據(jù)庫一直是大公司的專利，市場被Oracle/DB2等企業(yè)數(shù)據(jù)庫牢牢把持。

但是隨著互聯(lián)網(wǎng)的崛起、開源社區(qū)的發(fā)展，上世紀(jì)九十年代MySQL1.0的發(fā)布，標(biāo)志著關(guān)系型數(shù)據(jù)庫的領(lǐng)域社區(qū)終于有可選擇的方案。

MySQL第一個(gè)介紹的單機(jī)RDBMS就是MySQL。

相信大多數(shù)朋友都已經(jīng)對MySQL非常熟悉，基本上MySQL的成長史就是互聯(lián)網(wǎng)的成長史。

我接觸的第一個(gè)MySQL版本是MySQL4.0，到后來的MySQL5.5更是經(jīng)典——基本所有的互聯(lián)網(wǎng)公司都在使用。

MySQL也普及了「可插拔」引擎這一概念，針對不同的業(yè)務(wù)場景選用不同的存儲引擎是MySQLtuning的一個(gè)重要的方式。

比如對于有事務(wù)需求的場景使用InnoDB;對于并發(fā)讀取的場景MyISAM可能比較合適;但是現(xiàn)在我推薦絕大多數(shù)情況還是使用InnoDB，畢竟5.6后已經(jīng)成為了官方的默認(rèn)引擎。

大多數(shù)朋友都基本知道什么場景適用MySQL(幾乎所有需要持久化結(jié)構(gòu)化數(shù)據(jù)的場景)，我就不贅述了。

另外值得一提的是MySQL5.6中引入了多線程復(fù)制和GTID，使得故障恢復(fù)和主從的運(yùn)維變得比較方便。

另外，5.7(目前處于GA版本)是MySQL的一個(gè)重大更新，主要是讀寫性能和復(fù)制性能上有了長足的進(jìn)步(在5.6版本中實(shí)現(xiàn)了SCHEMA級別的并行復(fù)制，不過意義不大，倒是MariaDB的多線程并行復(fù)制大放異彩，有不少人因?yàn)檫@個(gè)特性選擇MariaDB。

MySQL5.7MTS支持兩種模式，一種是和5.6一樣，另一種則是基于binloggroupcommit實(shí)現(xiàn)的多線程復(fù)制，也就是MASTER上同時(shí)提交的binlog在SLE端也可以同時(shí)被apply，實(shí)現(xiàn)并行復(fù)制)。

如果有單機(jī)數(shù)據(jù)庫技術(shù)選型的朋友，基本上只需要考慮5.7或者M(jìn)ariaDB就好了，而且5.6、5.7由Oracle接手后，性能和穩(wěn)定性上都有了明顯的提升。

PostgreSQLPostgreSQL的歷史也非常悠久，其前身是UCB的Ingres，主持這個(gè)項(xiàng)目的MichaelStronebraker于2015年獲得圖靈獎。

后來項(xiàng)目更名為Post-Ingres，項(xiàng)目基于BSDlicense下開源。

1995年幾個(gè)UCB的學(xué)生為Post-Ingres開發(fā)了SQL的接口，正式發(fā)布了PostgreSQL95，隨后一步步在開源社區(qū)中成長起來。

和MySQL一樣，PostgreSQL也是一個(gè)單機(jī)的關(guān)系型數(shù)據(jù)庫，但是與MySQL方便用戶過度擴(kuò)展的SQL文法不一樣的是，PostgreSQL的SQL支持非常強(qiáng)大，不管是內(nèi)置類型、JSON支持、GIS類型以及對于復(fù)雜查詢的支持，PL/SQL等都比MySQL強(qiáng)大得多，而且從代碼質(zhì)量上來看，PostgreSQL的代碼質(zhì)量是優(yōu)于MySQL的，另外相對于MySQL5.7以前的版本，PostgreSQL的SQL優(yōu)化器比MySQL強(qiáng)大很多，幾乎所有稍微復(fù)雜的查詢PostgreSQL的表現(xiàn)都優(yōu)于MySQL。

從近幾年的趨勢上來看，PostgreSQL的勢頭也很強(qiáng)勁，我認(rèn)為PostgreSQL的不足之處在于沒有MySQL那樣強(qiáng)大的社區(qū)和群眾基礎(chǔ)。

MySQL經(jīng)過那么多年的發(fā)展，積累了很多的運(yùn)維工具和最佳實(shí)踐，但是PostgreSQL作為后起之秀，擁有更優(yōu)秀的設(shè)計(jì)和更豐富的功能。

電腦培訓(xùn)發(fā)現(xiàn)PostgreSQL9以后的版本也足夠穩(wěn)定，在做新項(xiàng)目技術(shù)選型的時(shí)候，是一個(gè)很好的選擇。

另外也有很多新的數(shù)據(jù)庫項(xiàng)目是基于PostgreSQL源碼的基礎(chǔ)上進(jìn)行二次開發(fā)，比如Greenplum等。

為什么PostgreSQL比MongoDB還快

PostgreSQL9.4帶來了全新的NoSQL特性，并且根據(jù)EnterpriseDB的測試，其加載，插入和查詢的性能都已經(jīng)幾倍于MongoDB了。

雖然我是PG的鐵桿粉絲，但是關(guān)系數(shù)據(jù)庫背負(fù)了ACID的重型裝甲，在性能上居然能打敗輕裝上陣的NoSQL數(shù)據(jù)庫總覺得有點(diǎn)離譜。

所以我在自己的環(huán)境里驗(yàn)證了一下EnterpriseDB的測試結(jié)果，并且小探一下PG取勝的原因。

1. EnterpriseDB的測試結(jié)果

以下是EnterpriseDB的測試結(jié)果(數(shù)據(jù)量為5000萬)

（還可以參考這篇譯文： ）

2. 我的驗(yàn)證結(jié)果

測試觀點(diǎn)

為了使測試結(jié)果更加單純，我準(zhǔn)備單純比拼CPU消耗(盡量排除IO和網(wǎng)絡(luò)的干擾)，設(shè)定以下測試條件。

1）所有數(shù)據(jù)都要放進(jìn)內(nèi)存

2）C/S都跑在同一臺單機(jī)上

所以，只在單機(jī)上進(jìn)行10萬條小數(shù)據(jù)量的測試。

注）EnterpriseDB的測試環(huán)境是32G內(nèi)存的Amazon Web Services M3.2XLARGE實(shí)例，總數(shù)據(jù)量超過內(nèi)存了。

測試環(huán)境

測試環(huán)境為個(gè)人PC上的VMware虛擬機(jī)

PC

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

MEM:6GB

SSD:OCZ-VERTEX4 128GB(VMware虛擬機(jī)所在磁盤，非系統(tǒng)盤)

OS:Win7

VMware虛擬機(jī)

CPU:4核

MEM:1GB

OS:CentOS 6.5

PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默認(rèn)值)

MG:MongoDB 3.0.2

測試步驟

測試步驟非常簡單,可以參考：

但是，在測試前，有些東西要改。

1)把數(shù)據(jù)量減小到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設(shè)計(jì)的，MongoDB 3.0的db.json_tables.stats()輸出可能變了，所以這邊要修改一下。

PostgreSQL部署 - 單機(jī)流復(fù)制

創(chuàng)建主備的環(huán)境變量文件, 因?yàn)槭窃谕慌_機(jī)上起兩個(gè)PG實(shí)例, 環(huán)境變量要各自設(shè)置。

vi master.env

vi slave.env

新開一個(gè)shell終端(后續(xù)稱為 terminal_master )

新開一個(gè)shell終端(后續(xù)稱為 terminal_slave )

經(jīng)過上面幾步, 一個(gè)一主一備的集群就搭建好了, 下面開始驗(yàn)證流復(fù)制是否工作正常。

切換到 terminal_master 終端

切換到 terminal_slave 終端

一個(gè)false一個(gè)tree, 證明目前主備狀態(tài)正常。

切換到 terminal_slave 終端

切換到 terminal_master 終端

切換到 terminal_slave 終端

DDL能順利同步。

切換到 terminal_slave 終端

切換到 terminal_master 終端

切換到 terminal_slave 終端

切換到 terminal_master 終端

切換到 terminal_slave 終端

切換到 terminal_master 終端

主備切換完成, 且數(shù)據(jù)同步工作正常。

目前雖然工作正常, 但是角色是互換了的, 后續(xù)可以停掉 slave ,再做一次主備切換, 恢復(fù)成原始狀態(tài)。

這個(gè)就作為練習(xí)了, 不再貼出操作步驟。

目前是靠手工切換主備的, 線上系統(tǒng)一般都要配置成自動切換, 這個(gè)時(shí)候就需要引入一些其他手段了, 譬如 patroni 之類的HA工具。

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 =

這一行，刪除#注釋，而后改大。這個(gè)錯(cuò)誤是同時(shí)刻打開了2048個(gè)表寫入，超過了限制造成的。

ps. 如果是在單機(jī)上運(yùn)行，這是很不推薦的！！因?yàn)槌鞘褂霉虘B(tài)硬盤（SSD)，并發(fā)寫入會導(dǎo)致頻繁的磁頭移動，效率奇差、損害硬盤壽命，降低穩(wěn)定性。