您的位置:首页 > 其它

Instagram 对 Postgres 性能调校的5个小技巧

2013-01-19 10:50 344 查看



Instagram对Postgres性能调校的5个小技巧


英文原文:Handling
GrowthwithPostgres:5TipsFromInstagram

随着Instagram的规模日益扩大,Postgres继续充当着Instagram的坚实基础,并存储着绝大部分的用户数据。不到一年之前,我们还曾在博客上说Instagram“存储着大量数据”,每秒增加90条数据,现在,这个数据已经增长到了峰值的10000条。而我们的基础存储技术依然保持不变。

在过去的两年半中,我们有一些关于Postgres扩展的经验和工具,想要分享出来。真希望在当初启动Instagram的时候就能有这些经验和工具呀。其中有些是Postgres独有的,有些是其它数据库也可以采用的。如果想要了解我们是如何水平分区的,可以看这篇文章。





AlfredCheung

翻译于昨天(11:31)


0人顶

顶翻译的不错哦!


1.局部索引

如果我们经常需要按某个固定的特征过滤数据,而且这个特征只存在于一小部分行里,在这种情况下,局部索引非常有效。

比方说,Instagram搜索标签的时候,我们需要找出有许多照片的标签。我们一般会用ElasticSearch之类的技术来进行高级搜索,不过这里只靠数据库的查询能力就完全够了。先来看一下,按标签查询,并按照片数排序,Postgres是怎么做的:

01
EXPLAIN
ANALYZE
SELECT
id
from
tags
WHERE
name
LIKE
'snow%'
ORDER
BY
media_count
DESC
LIMIT
10;
02
QUERY
PLAN
03
---------
04
Limit
(cost=1780.73..1780.75
rows
=10
width=32)(actual
time
=215.211..215.228
rows
=10
loops=1)
05
->
Sort(cost=1780.73..1819.36
rows
=15455
width=32)(actual
time
=215.209..215.215
rows
=10
loops=1)
06
Sort
Key
:
media_count
07
Sort
Method:
top
-N
heapsortMemory:25kB
08
->
Index
Scan
usingtags_search
on
tags_tag
(cost=0.00..1446.75
rows
=15455
width=32)(actual
time
=0.020..162.708
rows
=64572
loops=1)
09
Index
Cond:
(((
name
)::text
~>=~
'snow'
::text)
AND
((
name
)::text
~<~
'snox'
::text))
10
Filter:
((
name
)::text
~~
'snow%'
::text)
11
Total
runtime:215.275ms
12
(8
rows
)
有没有看到,为了得到结果,Postgres不得不对15000行数据进行排序。由于标签的分布满足长尾模式(译者注:根据百度百科,「我们常用的汉字实际上不多,但因出现频次高,所以这些为数不多的汉字占据了上图广大的红区;绝大部分的汉字难得一用,它们就属于那长长的黄尾。」),我们可以改为查询超过100张照片的标签,先建局部索引:

1
CREATE
INDEX
CONCURRENTLY
on
tags
(
name
text_pattern_ops)
WHERE
media_count
>=100
然后查询,看一下新的查询计划:

01
EXPLAIN
ANALYZE
SELECT
*
from
tags
WHERE
name
LIKE
'snow%'
AND
media_count
>=100
ORDER
BY
media_count
DESC
LIMIT
10;
02
03
QUERY
PLAN
04
Limit
(cost=224.73..224.75
rows
=10
width=32)(actual
time
=3.088..3.105
rows
=10
loops=1)
05
->
Sort(cost=224.73..225.15
rows
=169
width=32)(actual
time
=3.086..3.090
rows
=10
loops=1)
06
Sort
Key
:
media_count
07
Sort
Method:
top
-N
heapsortMemory:25kB
08
->
Index
Scan
usingtags_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)
09
Index
Cond:
(((
name
)::text
~>=~
'snow'
::text)
AND
((
name
)::text
~<~
'snox'
::text))
10
Filter:
((
name
)::text
~~
'snow%'
::text)
11
Total
runtime:3.137ms
12
(8
rows
)
可以看到,Postgres只需要访问169行,所以速度快得多。Postgres的查询计划器对约束的评估也很有效。如果以后想要查询超过500张照片的标签,由于这个结果集是上面集合的子集,所以仍然会使用这个局部索引。




AlfredCheung

翻译于昨天(11:15)


0人顶

顶翻译的不错哦!


2.函数索引

在某些表上,我们需要对一些很长的字符串建立索引,比如说,64个字符的base64记号。如果直接建索引的话,会造成大量的数据重复,这种情况下,可以用Postgres的函数索引:

1
CREATE
INDEX
CONCURRENTLY
on
tokens
(substr(token),0,8)
虽然这样会造成许多行匹配相同的前缀,但我们可以在匹配的基础上再用过滤,速度很快。而且索引很小,只有大概原来的十分之一。




AlfredCheung

翻译于昨天(10:54)


0人顶

顶翻译的不错哦!


3.用pg_reorg来让数据更紧凑

随着时间的流逝,Postgres的表会变得越来越零碎(由MVCC并发模型等原因引起)。而且,数据行插入的顺序往往也不是我们希望返回的顺序。比如说,如果我们经常要按用户来查询照片等,那么最好是在磁盘上把这些东西放在一起,这样就可以减少磁盘寻道的时间。

我们用pg_reorg来解决这个问题,它用三个步骤来让“压紧”一个表:

取得表的独占锁
建一个记录变更的临时表,在原始表上加一个触发器,把对原始表的变更复制到临时表上
用CREATETABLE...SELECTFROM...ORDERBY建表,新表拥有原始表的全部数据,而且是按索引顺序排序的
将CREATETABLE执行时间点以后发生的变更从临时表同步过来
业务切换到新表

每一步都会有很多细节,不过大体上就是像上面这个样子。我们先对这个工具进行了一些审查,运行了若干测试,然后再把它用到生产环境上。现在,我们已经在几百台机器的环境上跑过几十次pg_reorg,没出现过任何问题。





AlfredCheung

翻译于昨天(13:49)


0人顶

顶翻译的不错哦!


4.用WAL-E进行WAL(写前日志)的归档和备份

我们用WAL-E来归档WAL日志,它是Heroku写的一个工具,我们也向它贡献了一部分代码。WAL-E大大简化了数据备份和复制库创建的过程。

WAL-E是利用Progres的archive_command,将PG产生的每个WAL文件都归档到Amazon的S3。利用这些WAL文件和数据库的基准备份,我们可以将数据库恢复到基准备份后任何一个时间点的状态。利用这个手段,我们也可以快速创建只读的复制库或故障备用库。

我们为WAL-E写了一个简单的封装脚本,可以监控归档时的重复故障,见GitHub。





AlfredCheung

翻译于昨天(14:12)


0人顶

顶翻译的不错哦!


5.psycopg2中的自动提交模式和异步模式

我们也开始用psycopg2中的一些高级功能(psycopg2是Postgres的Python驱动)。

一个是自动提交模式。在这个模式里,psycopg2不会发出BEGIN/COMMIT,每个查询跑在自己的单语句事务里。这对不需要事务的只读查询特别有用。开启很简单:
connection.autocommit=True


开启自动提交后,我们的应用服务器和数据库之间的对话大减,数据库服务器的CPU用量也大减。而且,我们是用PGBouncer作为连接池,开启自动提交后,连接的归还也更快了。

与Django的交互细节可以看这里。





AlfredCheung

翻译于昨天(14:25)


0人顶

顶翻译的不错哦!
psycopg2还有一个很有用的功能,它可以通过注册一个等待回调(waitcallback)函数,提供协同程序(coroutine)支持。它可以支持跨连接查询,对命中多个节点的查询非常有用,当有数据时,socket会被唤醒(我们利用Python的select模块来处理唤醒)。它也可以与eventlet和gevent等多线程库很好的协作,参考实现可见psycogreen。

总的来说,我们对Postgres的高性能和可靠性十分满意。想在世界上最大之一的Postgres集群上工作吗?想跟一群基础设施高手们一起干活吗?请联系infrajobs@instagram.com吧。





AlfredCheung

翻译于昨天(14:39)


0人顶

顶翻译的不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接

我们的翻译工作遵照CC协议,如果我们的工作有侵犯到您的权益,请及时联系我们
原文作者:http://instagram-engineering.tumblr.com/post/40781627982/handling-growth-with-postgres-5-tips-from-instagram

原文出处:http://instagram-engineering.tumblr.com/post/40781627982/handling-growth-with-postgres-5-tips-from-instagram

译文作者:AlfredCheung

译文出处:http://www.oschina.net/translate/handling-growth-with-postgres-5-tips-from-instagram
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: