PostgreSQL的主要優(yōu)點:
成都創(chuàng)新互聯(lián)是一家專業(yè)提供忻城企業(yè)網(wǎng)站建設,專注與成都做網(wǎng)站、網(wǎng)站設計、外貿營銷網(wǎng)站建設、H5高端網(wǎng)站建設、小程序制作等業(yè)務。10年已為忻城眾多企業(yè)、政府機構等服務。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進行中。
1、對事務的支持與MySQL相比,經(jīng)歷了更為徹底的測試。對于一個嚴肅的商業(yè)應用來說,事務的支持是不可或缺的。
2、MySQL對于無事務的MyISAM表。采用表鎖定,一個長時間運行的查詢很可能會長時間地阻礙對表的更新。而PostgreSQL不存在這樣的問題。
3、PostgreSQL支持存儲過程,而目前MySQL不支持,對于一個嚴肅的商業(yè)應用來說,作為數(shù)據(jù)庫本身,有眾多的商業(yè)邏輯的存在,此時使用存儲過程可以在較少地增加數(shù)據(jù)庫服務器的負擔的前提下,對這樣的商業(yè)邏輯進行封裝,并可以利用數(shù)據(jù)庫服務器本身的內在機制對存儲過程的執(zhí)行進行優(yōu)化。此外存儲過程的存在也避免了在網(wǎng)絡上大量的原始的SQL語句的傳輸,這樣的優(yōu)勢是顯而易見的。
4、對視圖的支持,視圖的存在同樣可以最大限度地利用數(shù)據(jù)庫服務器內在的優(yōu)化機制。而且對于視圖權限的合理使用,事實上可以提供行級別的權限,這是MySQL的權限系統(tǒng)所無法實現(xiàn)的。
5、對觸發(fā)器的支持,觸發(fā)器的存在不可避免的會影響數(shù)據(jù)庫運行的效率,但是與此同時,觸發(fā)器的存在也有利于對商業(yè)邏輯的封裝,可以減少應用程序中對同一商業(yè)邏輯的重復控制。合理地使用觸發(fā)器也有利于保證數(shù)據(jù)的完整性。
6、對約束的支持。約束的作用更多地表現(xiàn)在對數(shù)據(jù)完整性的保證上,合理地使用約束,也可以減少編程的工作量。
--查詢是否鎖表了
1、select oid from pg_class where relname='可能被鎖掉的表的表名'
,會顯示一個oid
2、select pid from pg_locks where relation='剛剛查出來的oid'
--如果查詢到了結果(pid),表示該表被鎖 則需要釋放鎖定
select pg_cancel_backend(上面查到的pid)
是因為同時更新事物失誤。
通常在數(shù)據(jù)庫中最小粒度的鎖是行鎖,當一個事務正在更新某條記錄時,另一個事務如果要更新同一條記錄(或者申請這一條記錄的鎖),則必須等待鎖釋放。
通常持鎖的時間需要保持到事務結束,也就是說,如果一個長事務持有了某條記錄的鎖,其他會話要持有這條記錄的鎖,可能要等很久。
問題源自一個帥哥在建索引發(fā)生表鎖的問題。先介紹一下Postgresql的建索引語法: Version:9.1 CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name ] ON table [ USING method ] ( { column | ( expression ) } [ COLLATE collation ] [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] ) [ WITH ( storage_parameter = value [, ... ] ) ] [ TABLESPACE tablespace ] [ WHERE predicate ] 這里不解釋語法的諸多參數(shù)使用(排序,使用方法,填充因子等),主要說一下concurrently的使用場景。 正常情況下Postgresql建立普通btree索引時會阻塞DML(insert,update,delete)操作,直到索引完成,期間讀操作不受阻塞。當只有一個用戶操作這當然沒問題,但是在生產環(huán)境,并發(fā)比較高的情況下,特別是大表建索引就不能這么操作了,不然用戶要跳起來罵娘了,點個按鈕一天還沒反應過來。--使用 Postgresql提供了一個參數(shù),可以在線建立索引的時候避免因寫數(shù)據(jù)而鎖表,這個參數(shù)叫concurrently。使用很簡單,就是用create index concurrently來代替create index即可。--副作用 當然了,使用這個參數(shù)是有副作用的,不使用這個參數(shù)建索引時DB只掃描一次表,使用這個參數(shù)時,會引發(fā)DB掃兩次表,同時等待所有潛在會讀到該索引的事務結束,這么一來,系統(tǒng)的CPU和IO,內存等會受一點影響,所以綜合考慮,仍然讓用戶自行選擇,而不是默認。--失敗 在使用concurrently參數(shù)建索引時,有可能會遇到失敗的情況,比如建唯一索引索引發(fā)現(xiàn)數(shù)據(jù)有重復,又或者用戶發(fā)現(xiàn)建索引時建錯字段的,取消建索引操作了。此時該表上會存在一個索引,這是因為帶這個參數(shù)的建索引命令一經(jīng)發(fā)出,就首先會在系統(tǒng)的日志表里先插一個索引記錄進去,又因為這個索引最終建失敗了,所以會被標記一個INVALID的狀態(tài),如下: postgres=# \d t_kenyon Table public.t_kenyon Column | Type | Modifiers --------+---------+----------- col | integer |Indexes:idx btree (col) INVALID--重建 遇到上述失效的索引重建時兩個辦法,一個是drop index index_name,然后再執(zhí)行create index concurrently。還有一個是執(zhí)行reindex index_name命令,但是后者不支持concurrent參數(shù)。--總結
一、 PostgreSQL 的穩(wěn)定性極強, Innodb 等引擎在崩潰、斷電之類的災難場景下抗打擊能力有了長足進步,然而很多 MySQL 用戶都遇到過Server級的數(shù)據(jù)庫丟失的場景——mysql系統(tǒng)庫是MyISAM的,相比之下,PG數(shù)據(jù)庫這方面要好一些。
二、任何系統(tǒng)都有它的性能極限,在高并發(fā)讀寫,負載逼近極限下,PG的性能指標仍可以維持雙曲線甚至對數(shù)曲線,到頂峰之后不再下降,而 MySQL 明顯出現(xiàn)一個波峰后下滑(5.5版本之后,在企業(yè)級版本中有個插件可以改善很多,不過需要付費)。
三、PG 多年來在 GIS 領域處于優(yōu)勢地位,因為它有豐富的幾何類型,實際上不止幾何類型,PG有大量字典、數(shù)組、bitmap 等數(shù)據(jù)類型,相比之下mysql就差很多,instagram就是因為PG的空間數(shù)據(jù)庫擴展POSTGIS遠遠強于MYSQL的my spatial而采用PGSQL的。
四、PG 的“無鎖定”特性非常突出,甚至包括 vacuum 這樣的整理數(shù)據(jù)空間的操作,這個和PGSQL的MVCC實現(xiàn)有關系。
五、PG 的可以使用函數(shù)和條件索引,這使得PG數(shù)據(jù)庫的調優(yōu)非常靈活,mysql就沒有這個功能,條件索引在web應用中很重要。
六、PG有極其強悍的 SQL 編程能力(9.x 圖靈完備,支持遞歸!),有非常豐富的統(tǒng)計函數(shù)和統(tǒng)計語法支持,比如分析函數(shù)(ORACLE的叫法,PG里叫window函數(shù)),還可以用多種語言來寫存儲過程,對于R的支持也很好。這一點上MYSQL就差的很遠,很多分析功能都不支持,騰訊內部數(shù)據(jù)存儲主要是MYSQL,但是數(shù)據(jù)分析主要是HADOOP+PGSQL。
七、PG 的有多種集群架構可以選擇,plproxy 可以支持語句級的鏡像或分片,slony 可以進行字段級的同步設置,standby 可以構建WAL文件級或流式的讀寫分離集群,同步頻率和集群策略調整方便,操作非常簡單。
八、一般關系型數(shù)據(jù)庫的字符串有限定長度8k左右,無限長 TEXT 類型的功能受限,只能作為外部大數(shù)據(jù)訪問。而 PG 的 TEXT 類型可以直接訪問,SQL語法內置正則表達式,可以索引,還可以全文檢索,或使用xml xpath。用PG的話,文檔數(shù)據(jù)庫都可以省了。
九,對于WEB應用來說,復制的特性很重要,mysql到現(xiàn)在也是異步復制,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引擎,可以充分優(yōu)化利用系統(tǒng)所有內存,超大內存下PG對內存使用的不那么充分,
第三點,MySQL的復制可以用多級從庫,但是在9.2之前,PGSQL不能用從庫帶從庫。
第四點,從測試結果上看,mysql 5.5的性能提升很大,單機性能強于pgsql,5.6應該會強更多.
第五點,對于web應用來說,mysql 5.6 的內置MC API功能很好用,PGSQL差一些。
另外一些:
pgsql和mysql都是背后有商業(yè)公司,而且都不是一個公司。大部分開發(fā)者,都是拿工資的。
說mysql的執(zhí)行速度比pgsql快很多是不對的,速度接近,而且很多時候取決于你的配置。
對于存儲過程,函數(shù),視圖之類的功能,現(xiàn)在兩個數(shù)據(jù)庫都可以支持了。
另外多線程架構和多進程架構之間沒有絕對的好壞,oracle在unix上是多進程架構,在windows上是多線程架構。
很多pg應用也是24/7的應用,比如skype. 最近幾個版本VACUUM基本不影響PGSQL 運行,8.0之后的PGSQL不需要cygwin就可以在windows上運行。
至于說對于事務的支持,mysql和pgsql都沒有問題。
文章名稱:postgresql更新庫存鎖的簡單介紹
分享URL:http://www.rwnh.cn/article10/dscdcdo.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供外貿建站、網(wǎng)站內鏈、手機網(wǎng)站建設、搜索引擎優(yōu)化、品牌網(wǎng)站設計、做網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)