隨著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來解決這個問題,它用三個步驟來讓“壓緊”一個表:
每一步都會有很多細節,不過大體上就是像上面這個樣子。我們先對這個工具進行了一些審查,運行了若干測試,然後再把它用到生產環境上。現在,我們已經在幾百台機器的環境上跑過幾十次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集群上工作嗎?想跟一群基礎設施高手們一起干活嗎?請聯系[email protected]吧。