最近在看mysql文檔,發(fā)現(xiàn)了很多好耍的東西,同時(shí)也發(fā)現(xiàn)了很多不好耍的東西.
想對(duì)比一下mysql和pgsql,于是到baidu上隨便搜了幾篇文章.其中有一篇文章寫的不錯(cuò).而且其中有一段話寫的很經(jīng)典:"沒有好的數(shù)據(jù)庫，只有合適的數(shù)據(jù)庫"

以下文章轉(zhuǎn)自:http://blog.chinaunix.net/u/553/showart.php?id=283310
Mysql與Postgresql數(shù)據(jù)性能比較
數(shù)據(jù)量今后會(huì)很大/你無法預(yù)測(cè) 數(shù)據(jù)量會(huì)多大，建議換postgresql.

mysql 在一定量數(shù)據(jù)后(一般觀點(diǎn)是 mysql 單表 200-300萬 時(shí)性能最好，數(shù)據(jù)再多性能就開始下降)，性能下降很快，且大數(shù)據(jù)量情況下，mysql 穩(wěn)定性/數(shù)據(jù)可靠性是問題。

postgresql 8.2 的官方說明如下：

http://www.postgresql.org/about/

QUOTE:
Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited
mysql 目前只是適合 跑 web 應(yīng)用，對(duì)于海量數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)倉庫 不合適。

postgresql 在國內(nèi)早有人做大型商業(yè)應(yīng)用。

QUOTE:
對(duì)于大型應(yīng)用，PostgreSQL 還是合適的。以下是PostgreSQL 中文官方手冊(cè)維護(hù)者 何偉平 laser 對(duì)于一個(gè) 大型應(yīng)用 的回復(fù)：

QUOTE:
怎么說呢，實(shí)際上，我現(xiàn)在手頭就有一個(gè)龐大的數(shù)據(jù)庫，
數(shù)據(jù)＋索引已經(jīng)超過500G了，數(shù)據(jù)總量超過30億行數(shù)據(jù)，
每天會(huì)忙12小時(shí)左右。

基本上，我覺得，首先：
檢查你的IO投資，不要在硬盤上吝嗇。
第二，仔細(xì)分析自己的瓶頸是什么，
很多事后，我們并不一定需要database replicate。
第三，適當(dāng)使用數(shù)據(jù)的切割。

簡單歸結(jié)一句話：
適當(dāng)?shù)挠布顿Y和規(guī)劃加上合適的軟件結(jié)構(gòu)。
具體的事情需要具體分析。

介紹一下我們那個(gè)500G的大庫：
單機(jī)HP DL385，16G內(nèi)存和6塊SCSI磁盤，20塊SATA磁盤盤陣，
盤陣是HP DL320S，（MSA1500），相當(dāng)便宜。
我們的構(gòu)造是SCSI是RAID5，跑XFS，SATA，RAID5，跑EXT3，
目前，性能非常滿意（我們的角度），有些update語句，一次
會(huì)更新幾百萬行數(shù)據(jù)，那么我們有些程序，一天要更新幾十次，
基本上也可以在1000s之內(nèi)完成。每天vacuum一次，在低負(fù)載的
時(shí)段，大概需要120min~200min，用slony做數(shù)據(jù)的備份，備份
到一臺(tái)大硬盤的IDE機(jī)器上（1.5T硬盤，別驚訝，現(xiàn)在750G硬盤
才3500塊錢。）。
這臺(tái)機(jī)器是數(shù)據(jù)挖掘的，并發(fā)數(shù)不多，所以我們沒有做負(fù)載方面
的均衡。

有問題可以繼續(xù)討論。
測(cè)試,mysql vs postgresql

QUOTE:
Mysql 不適應(yīng) 大量數(shù)據(jù)，密集運(yùn)算，重型負(fù)載應(yīng)用。

至少在目前，開源數(shù)據(jù)庫的質(zhì)量還不能與商業(yè)數(shù)據(jù)抗衡。

在 2006-11-29 有個(gè)國外第3方服務(wù)器機(jī)構(gòu)(Tweakers.net)做的 Mysql 4.1.20 ,Mysql 5.1.20a 與 PostgreSQL 8.2 的對(duì)比性能測(cè)試(在不同檔次配置的機(jī)器上運(yùn)行). 你可以參考.
Posted by fsluiter@gmail.com

Tweakers.net, a dutch community of online tweakers, benchmarked their potential new server with PostgreSQL 8.2 vs several versions of MySQL 4.1.20 and MySQL 5.1.20a

圖文測(cè)試統(tǒng)計(jì)報(bào)告：
http://tweakers.net/reviews/657/6


QUOTE:
如果要求更高，推薦使用性能優(yōu)異的 bizgres 集群。

參考:
http://bbs.chinaunix.net/viewthr ... page%3D1&page=1

QUOTE:
2億的單表，slect crount(*) from table; 來全表掃描。

同配置單主機(jī) 硬件: 內(nèi)存8G，每臺(tái)機(jī)器是兩個(gè)雙核的AMD86.磁盤Raid0+1

Oracle 10g用了50秒，postgresql的普通集群用來一分40秒.

改用Bizgers 這個(gè) PostgreSQL   高性能集群(使用)后，速度是 Oracle 的4倍。


mysql超過1億行慢得和蝸牛一樣。

你的要求恐怕最好是使用Oracle,DB2 強(qiáng)力商業(yè)數(shù)據(jù)庫才合適.

如果非要用開源的,在Mysql與PostgreSQL之間選,更合適的是PostgreSQL:

1."海量數(shù)據(jù)","復(fù)雜業(yè)務(wù)邏輯" 這兩條 PostgreSQL占絕對(duì)優(yōu)勢(shì),Mysql 的確快,但只是在小數(shù)據(jù)量時(shí)很快,但如果巨量數(shù)據(jù),性能下降很快比PostgreSQL快多了.

在巨量數(shù)據(jù)條件下Mysql可靠性成問題,今天就有朋友給我抱怨"我也就做DIscuz-BBS Mysql 庫也就10GB 大,數(shù)據(jù)時(shí)不時(shí)損壞,經(jīng)常需要mycheck修復(fù)數(shù)據(jù)才行.很想讓系統(tǒng)定期check";另一個(gè)朋友也插話說他的mysql數(shù)據(jù)庫到了100G后三天兩頭 數(shù)據(jù)損壞,搞的頭大.

Postgresql 我所知道的例子是有庫到了4TB 正常運(yùn)行.

2."頻繁的數(shù)據(jù)統(tǒng)計(jì)和分析，可能會(huì)運(yùn)用到不少商業(yè)智能、統(tǒng)計(jì)模型和預(yù)測(cè)的應(yīng)用" 這條也是 PostgreSQL占優(yōu)勢(shì).

Mysql 只在到了5.0 時(shí)引進(jìn)了,InnoBDB 數(shù)據(jù)表格式后 才具有初步的事務(wù)處理能力,目前還是很簡陋,且,InnoBDB 比 默認(rèn)的 MyISAM 性能差.

Mysql 如果只是查詢數(shù)據(jù)(數(shù)據(jù)不多)性能不錯(cuò),但其他操作就沒那么出色.如果用InnoBDB 和開啟 Mysql 5.0 以來添加的新的企業(yè)用途功能后,性能根本不能與PostgreSQL比.


PostgreSQL 功能很全,甚至有些功能商業(yè)數(shù)據(jù)庫也不具備,用于商業(yè)事物處理的功能很久以前就很成熟.


呵呵,我也是PostgreSQL新手,只是喜歡探索和看書,看資料.

你這種要求,最好去咨詢國內(nèi)最著名的PostgreSQL 大牛 何偉平 -->去他的 www.pgsqldb.org 找他,他是創(chuàng)辦人,有豐富的PostgreSQL商用經(jīng)驗(yàn),最近在 <<程序員雜志>>2006-6月號(hào)上發(fā)表一篇專門介紹 開源數(shù)據(jù)庫的文章(Mysql,Postgresql,FireBird),也簡單介紹了一個(gè)PostgreSQL商用案例.

[ 本帖最后由 likuku 于 2006-9-1 22:51 編輯 ]


gh.duowan.com，使用PostgreSQL。

27G的數(shù)據(jù)量，200W的日訪問量

下面是該網(wǎng)站維護(hù)者Chanix給我的回復(fù)，僅作參考：

---------------------------------

我的機(jī)房是電信線路，網(wǎng)通訪問比較慢。這幾天流量突漲，效率上正在進(jìn)行優(yōu)化。從最前端的 squid 到最后的 數(shù)據(jù)庫服務(wù)器都在不斷調(diào)整和優(yōu)化中。

我負(fù)責(zé)的站也有社會(huì)性軟件的思想設(shè)計(jì)的社區(qū)。可以看看 http://home.duowan.com。

PG不是完美的數(shù)據(jù)庫，肯定是有缺點(diǎn)的。我認(rèn)為主要的缺點(diǎn)就是進(jìn)程模式，一個(gè)進(jìn)程處理一個(gè)連接，這樣的處理方式較消耗資源。不過從另外一方面來講，就是因?yàn)槭褂昧?#8220;落后的”進(jìn)程模式所以才能達(dá)到這么穩(wěn)定的效果。世上的東西總是雙刃劍。。。

MYSQL的確是快，呵呵，特別是ISAM。目前使用MYSQL做SNS類型網(wǎng)站的成功案例也不少。例如 mixi.jp myspace.com LiveJournal.com 等等，都是上T容量，上百臺(tái)數(shù)據(jù)庫服務(wù)器。。。而且MYSQL支持的表的類型比較多，ISAM INNODB HEAP。。。可以按照數(shù)據(jù)的使用狀態(tài)來進(jìn)行靈活的使用。

說說為什么我選擇PG吧。
我選擇PG是因?yàn)閺?系列開始我就一直在用，比較熟悉。而且我實(shí)在是不認(rèn)為沒有ACID的東西可以叫數(shù)據(jù)庫。。。當(dāng)時(shí)MYSQL還在3系列，連最基本的事 務(wù)功能也沒有，更加別說什么觸發(fā)器，函數(shù)了。插入記錄竟然還是表鎖，并發(fā)插入一多，整個(gè)系統(tǒng)馬上和紙搭的房子一樣坍塌掉（很不幸，當(dāng)時(shí)我做的那個(gè)應(yīng)用插入 比較多）。。。

MYSQL也有它的優(yōu)點(diǎn)，這個(gè)不是重點(diǎn)，我就不多說了。

我對(duì)PG比MYSQL熟悉的多。所以我選擇PG。這個(gè)是最主要的原因。到目前為止，PG還沒有讓我失望。我覺得你的選型也可以這樣考慮的，從實(shí)際中看兩者各有優(yōu)劣。也各有成功案例。很難說SNS只有PG能做，或者只有PG能做。

還是那句話，沒有好的數(shù)據(jù)庫，只有合適的數(shù)據(jù)庫。找到最合適你使用的數(shù)據(jù)庫才是最好的選擇 微笑 正如我雖然選擇PG，但沒有排斥MYSQL，在我負(fù)責(zé)的站點(diǎn)中，還是有很多應(yīng)用是使用MYSQL的。


順帶說一句：
MYSQL要4系列以后，使用INOODB才支持事務(wù)。而INOODB與PG之間的效率差別我測(cè)試的結(jié)果不是很大。

有空可以去看看源代碼。MYSQL支持事務(wù)的那段代碼比起PG比較起來，PG的清晰多了（雖然，我哪個(gè)都寫不出來 害羞 ）。

PG的確穩(wěn)定，我有個(gè)應(yīng)用我正準(zhǔn)備廢掉，所以不想花時(shí)間優(yōu)化了，那臺(tái)數(shù)據(jù)庫服務(wù)器每天UPTIME超100。我現(xiàn)在都懶的管了。反正只要訪問的人少了，肯定能恢復(fù)過來。換成MYSQL，已經(jīng)崩潰，數(shù)據(jù)庫受損了。

PG一旦出問題，那就是真的出問題了。MYSQL不是，出問題了，你可以通過 repair 來修，不過修理的結(jié)果是對(duì)是錯(cuò)，你就自己掌握吧。我是試過一個(gè)表，系統(tǒng)很高興的告訴我修理成功！結(jié)果發(fā)現(xiàn)唯一鍵字都出重復(fù)，害的我整了一通宵。

PG最大的問題我認(rèn)為在于一個(gè)連接一個(gè)進(jìn)程。一臺(tái)機(jī)器上最大的進(jìn)程數(shù)是有限制的，也就意味著可以同時(shí)處理的連接數(shù)比MYSQL小的多。

PG需要整理，雖然8系列以后出現(xiàn)了 auovaccum 但是還是很麻煩。這也是目前我比較頭痛的問題。因?yàn)榫W(wǎng)站是24*7對(duì)外開放的，所以不可能停機(jī)去VACCUM FULL，幸好機(jī)器硬盤夠大，呵呵。這個(gè)問題也是我一直想請(qǐng)教LARSER的。

PG的中文資料太少！用的人少，可以請(qǐng)教的人也不多。不象MYSQL，哪個(gè)書店里面都有什么XXX天精通MYSQL之類的書，到處都有人吹噓自己精通MYSQL（即使他只會(huì)SELECT + UPDATE）。