本篇文章為大家展示了Instagram中怎么提升PostgreSQL性能，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

專(zhuān)注于為中小企業(yè)提供網(wǎng)站設(shè)計(jì)、網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)雄縣免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了成百上千家企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

1. 局部索引

如果我們經(jīng)常需要按某個(gè)固定的特征過(guò)濾數(shù)據(jù)，而且這個(gè)特征只存在于一小部分行里，在這種情況下，局部索引非常有效。

比方說(shuō)，Instagram搜索標(biāo)簽的時(shí)候，我們需要找出有許多照片的標(biāo)簽。我們一般會(huì)用ElasticSearch之類(lèi)的技術(shù)來(lái)進(jìn)行高級(jí)搜索，不過(guò)這里只靠數(shù)據(jù)庫(kù)的查詢(xún)能力就完全夠了。先來(lái)看一下，按標(biāo)簽查詢(xún)，并按照片數(shù)排序，Postgres是怎么做的:
 

EXPLAIN ANALYZE SELECT id from tags WHERE name LIKE 'snow%' ORDER BY media_count DESC LIMIT 10;   
QUERY PLAN 
---------                                 
 Limit (cost=1780.73..1780.75 rows=10 width=32) (actual time=215.211..215.228 rows=10 loops=1)
  -> Sort (cost=1780.73..1819.36 rows=15455 width=32) (actual time=215.209..215.215 rows=10 loops=1)
     Sort Key: media_count
     Sort Method: top-N heapsort Memory: 25kB
     -> Index Scan using tags_search on tags_tag (cost=0.00..1446.75 rows=15455 width=32) (actual time=0.020..162.708 rows=64572 loops=1)
        Index Cond: (((name)::text ~>=~ 'snow'::text) AND ((name)::text ~<~ 'snox'::text))
        Filter: ((name)::text ~~ 'snow%'::text)
 Total runtime: 215.275 ms
(8 rows)

有沒(méi)有看到，為了得到結(jié)果，Postgres不得不對(duì)15000行數(shù)據(jù)進(jìn)行排序。由于標(biāo)簽的分布滿(mǎn)足長(zhǎng)尾模式(譯者注: 根據(jù)百度百科，「我們常用的漢字實(shí)際上不多，但因出現(xiàn)頻次高，所以這些為數(shù)不多的漢字占據(jù)了上圖廣大的紅區(qū)；絕大部分的漢字難得一用，它們就屬于那長(zhǎng)長(zhǎng)的黃尾。」)，我們可以改為查詢(xún)超過(guò)100張照片的標(biāo)簽，先建局部索引:
 
CREATE INDEX CONCURRENTLY on tags (name text_pattern_ops) WHERE media_count >= 100
然后查詢(xún)，看一下新的查詢(xún)計(jì)劃:
 

EXPLAIN ANALYZE SELECT * from tags WHERE name LIKE 'snow%' AND media_count >= 100 ORDER BY media_count DESC LIMIT 10;
 
QUERY PLAN
 Limit (cost=224.73..224.75 rows=10 width=32) (actual time=3.088..3.105 rows=10 loops=1)
  -> Sort (cost=224.73..225.15 rows=169 width=32) (actual time=3.086..3.090 rows=10 loops=1)
     Sort Key: media_count
     Sort Method: top-N heapsort Memory: 25kB
     -> Index Scan using tags_tag_name_idx on tags_tag (cost=0.00..221.07 rows=169 width=32) (actual time=0.021..2.360 rows=924 loops=1)
        Index Cond: (((name)::text ~>=~ 'snow'::text) AND ((name)::text ~<~ 'snox'::text))
        Filter: ((name)::text ~~ 'snow%'::text)
 Total runtime: 3.137 ms
(8 rows)

可以看到，Postgres只需要訪問(wèn)169行，所以速度快得多。Postgres的查詢(xún)計(jì)劃器對(duì)約束的評(píng)估也很有效。如果以后想要查詢(xún)超過(guò)500張照片的標(biāo)簽，由于這個(gè)結(jié)果集是上面集合的子集，所以仍然會(huì)使用這個(gè)局部索引。

2. 函數(shù)索引

在某些表上，我們需要對(duì)一些很長(zhǎng)的字符串建立索引，比如說(shuō)，64個(gè)字符的base64記號(hào)。如果直接建索引的話，會(huì)造成大量的數(shù)據(jù)重復(fù)，這種情況下，可以用Postgres的函數(shù)索引:
 

CREATE INDEX CONCURRENTLY on tokens (substr(token), 0, 8)

雖然這樣會(huì)造成許多行匹配相同的前綴，但我們可以在匹配的基礎(chǔ)上再用過(guò)濾，速度很快。而且索引很小，只有大概原來(lái)的十分之一。

3. 用pg_reorg來(lái)讓數(shù)據(jù)更緊湊

隨著時(shí)間的流逝，Postgres的表會(huì)變得越來(lái)越零碎(由MVCC并發(fā)模型等原因引起)。而且，數(shù)據(jù)行插入的順序往往也不是我們希望返回的順序。比如說(shuō)，如果我們經(jīng)常要按用戶(hù)來(lái)查詢(xún)照片等，那么最好是在磁盤(pán)上把這些東西放在一起，這樣就可以減少磁盤(pán)尋道的時(shí)間。

我們用pg_reorg來(lái)解決這個(gè)問(wèn)題，它用三個(gè)步驟來(lái)讓“壓緊”一個(gè)表:

1.     取得表的獨(dú)占鎖

2.     建一個(gè)記錄變更的臨時(shí)表，在原始表上加一個(gè)觸發(fā)器，把對(duì)原始表的變更復(fù)制到臨時(shí)表上

3.     用CREATE TABLE...SELECT FROM...ORDER BY建表，新表?yè)碛性急淼娜繑?shù)據(jù)，而且是按索引順序排序的

4.     將CREATE TABLE執(zhí)行時(shí)間點(diǎn)以后發(fā)生的變更從臨時(shí)表同步過(guò)來(lái)

5.     業(yè)務(wù)切換到新表

每一步都會(huì)有很多細(xì)節(jié)，不過(guò)大體上就是像上面這個(gè)樣子。我們先對(duì)這個(gè)工具進(jìn)行了一些審查，運(yùn)行了若干測(cè)試，然后再把它用到生產(chǎn)環(huán)境上。現(xiàn)在，我們已經(jīng)在幾百臺(tái)機(jī)器的環(huán)境上跑過(guò)幾十次pg_reorg，沒(méi)出現(xiàn)過(guò)任何問(wèn)題。

4. 用WAL-E進(jìn)行WAL(寫(xiě)前日志)的歸檔和備份

我們用WAL-E來(lái)歸檔WAL日志，它是Heroku寫(xiě)的一個(gè)工具，我們也向它貢獻(xiàn)了一部分代碼。WAL-E大大簡(jiǎn)化了數(shù)據(jù)備份和復(fù)制庫(kù)創(chuàng)建的過(guò)程。

WAL-E是利用Progres的archive_command，將PG產(chǎn)生的每個(gè)WAL文件都?xì)w檔到Amazon的S3。利用這些WAL文件和數(shù)據(jù)庫(kù)的基準(zhǔn)備份，我們可以將數(shù)據(jù)庫(kù)恢復(fù)到基準(zhǔn)備份后任何一個(gè)時(shí)間點(diǎn)的狀態(tài)。利用這個(gè)手段，我們也可以快速創(chuàng)建只讀的復(fù)制庫(kù)或故障備用庫(kù)。

我們?yōu)閃AL-E寫(xiě)了一個(gè)簡(jiǎn)單的封裝腳本，可以監(jiān)控歸檔時(shí)的重復(fù)故障，見(jiàn)GitHub。
 
5. psycopg2中的自動(dòng)提交模式和異步模式

我們也開(kāi)始用psycopg2中的一些高級(jí)功能(psycopg2是Postgres的Python驅(qū)動(dòng))。

一個(gè)是自動(dòng)提交模式。在這個(gè)模式里，psycopg2不會(huì)發(fā)出BEGIN/COMMIT，每個(gè)查詢(xún)跑在自己的單語(yǔ)句事務(wù)里。這對(duì)不需要事務(wù)的只讀查詢(xún)特別有用。開(kāi)啟很簡(jiǎn)單:

connection.autocommit = True

開(kāi)啟自動(dòng)提交后，我們的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)之間的對(duì)話大減，數(shù)據(jù)庫(kù)服務(wù)器的CPU用量也大減。而且，我們是用PGBouncer作為連接池，開(kāi)啟自動(dòng)提交后，連接的歸還也更快了。

與Django的交互細(xì)節(jié)可以看這里。

上述內(nèi)容就是Instagram中怎么提升PostgreSQL性能，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

新聞名稱(chēng)：Instagram中怎么提升PostgreSQL性能
轉(zhuǎn)載來(lái)源：http://chinadenli.net/article48/gspjep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、面包屑導(dǎo)航、小程序開(kāi)發(fā)、移動(dòng)網(wǎng)站建設(shè)、Google、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)