Instagram提升PostgreSQL效能的五個技巧，postgresql效能最佳化

Instagram提升PostgreSQL效能的五個技巧，postgresql效能最佳化

 隨著Instagram的規模日益擴大，Postgres繼續充當著Instagram的堅實基礎，並儲存著絕大部分的使用者資料。不到一年之前，我們還曾在部落格上說Instagram“儲存著大量資料”，每秒增加90條資料，現在，這個資料已經增長到了峰值的10000條。而我們的基礎儲存技術依然保持不變。

在過去的兩年半中，我們有一些關於Postgres擴充的經驗和工具，想要分享出來。真希望在當初啟動Instagram的時候就能有這些經驗和工具呀。其中有些是Postgres專屬的，有些是其它資料庫也可以採用的。如果想要瞭解我們是如何水平資料分割的，可以看這篇文章。

1. 局部索引

如果我們經常需要按某個固定的特徵過濾資料，而且這個特徵只存在於一小部分行裡，在這種情況下，局部索引非常有效。

比方說，Instagram搜尋標籤的時候，我們需要找出有許多照片的標籤。我們一般會用Elasticsearch之類的技術來進行進階搜尋，不過這裡只靠資料庫的查詢能力就完全夠了。先來看一下，按標籤查詢，並按照片數排序，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)

有沒有看到，為了得到結果，Postgres不得不對15000行資料進行排序。由於標籤的分布滿足長尾模式(譯者注: 根據百度百科，「我們常用的漢字實際上不多，但因出現頻次高，所以這些為數不多的漢字佔據了廣大的紅區；絕大部分的漢字難得一用，它們就屬於那長長的黃尾。」)，我們可以改為查詢超過100張照片的標籤，先建局部索引:
 
CREATE INDEX CONCURRENTLY on tags (name text_pattern_ops) WHERE media_count >= 100
然後查詢，看一下新的查詢計劃:
 

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只需要訪問169行，所以速度快得多。Postgres的查詢計劃器對約束的評估也很有效。如果以後想要查詢超過500張照片的標籤，由於這個結果集是上面集合的子集，所以仍然會使用這個局部索引。

2. 函數索引

在某些表上，我們需要對一些很長的字串建立索引，比如說，64個字元的base64記號。如果直接建索引的話，會造成大量的資料重複，這種情況下，可以用Postgres的函數索引:
 

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

雖然這樣會造成許多行匹配相同的首碼，但我們可以在匹配的基礎上再用過濾，速度很快。而且索引很小，只有大概原來的十分之一。

3. 用pg_reorg來讓資料更緊湊

隨著時間的流逝，Postgres的表會變得越來越零碎(由MVCC並行存取模型等原因引起)。而且，資料行插入的順序往往也不是我們希望返回的順序。比如說，如果我們經常要按使用者來查詢照片等，那麼最好是在磁碟上把這些東西放在一起，這樣就可以減少磁碟尋道的時間。

我們用pg_reorg來解決這個問題，它用三個步驟來讓“壓緊”一個表:

1.     取得表的獨佔鎖
2.     建一個記錄變更的暫存資料表，在原始表上加一個觸發器，把對原始表的變更複製到暫存資料表上
3.     用CREATE TABLE...SELECT FROM...ORDER BY建表，新表擁有原始表的全部資料，而且是按索引順序排序的
4.     將CREATE TABLE執行時間點以後發生的變更從暫存資料表同步過來
5.     業務切換到新表

每一步都會有很多細節，不過大體上就是像上面這個樣子。我們先對這個工具進行了一些審查，運行了若干測試，然後再把它用到生產環境上。現在，我們已經在幾百台機器的環境上跑過幾十次pg_reorg，沒出現過任何問題。

4. 用WAL-E進行WAL(寫前日誌)的歸檔和備份

我們用WAL-E來歸檔WAL日誌，它是Heroku寫的一個工具，我們也向它貢獻了一部分代碼。WAL-E大大簡化了資料備份和複製庫建立的過程。

WAL-E是利用Progres的archive_command，將PG產生的每個WAL檔案都歸檔到Amazon的S3。利用這些WAL檔案和資料庫的基底備份，我們可以將資料庫恢複到基底備份後任何一個時間點的狀態。利用這個手段，我們也可以快速建立唯讀複製庫或故障備用庫。

我們為WAL-E寫了一個簡單的封裝指令碼，可以監控歸檔時的重複故障，見GitHub。
 
5. psycopg2中的自動認可模式和非同步模式

我們也開始用psycopg2中的一些進階功能(psycopg2是Postgres的Python驅動)。

一個是自動認可模式。在這個模式裡，psycopg2不會發出BEGIN/COMMIT，每個查詢跑在自己的單語句事務裡。這對不需要事務的唯讀查詢特別有用。開啟很簡單:

connection.autocommit = True

開啟自動認可後，我們的應用伺服器和資料庫之間的對話大減，資料庫伺服器的CPU用量也大減。而且，我們是用PGBouncer作為串連池，開啟自動認可後，串連的歸還也更快了。

與Django的互動細節可以看這裡。

psycopg2還有一個很有用的功能，它可以通過註冊一個等待回調(wait callback)函數，提供協同程式(coroutine)支援。它可以支援跨串連查詢，對命中多個節點的查詢非常有用，當有資料時，socket會被喚醒(我們利用Python的select模組來處理喚醒)。它也可以與eventlet和gevent等多線程庫很好的協作，參考實現可見psycogreen。

總的來說，我們對Postgres的高效能和可靠性十分滿意。想在世界上最大之一的Postgres叢集上工作嗎？想跟一群基礎設施高手們一起幹活嗎？請聯絡infrajobs@instagram.com吧。