Pinterest正经历了指数级曲线般的增长,每隔一个半月翻翻。在这两年里,Pinterest,从 每月PV量0增长到10亿,从两名成立者和一个工程师成长为四十个工程师,从一台MySQL 服务器增长到180台Web 服务器(Web Engine),240台接口服务器(API Engine), 88台MySQL 数据库 (cc2.8xlarge) ,并且每台DB有一个备份服务器,110台Redis 实例服务(Redis Instance),200台 Memcache 实例服务(Memcache Instance)。
令人叹为观止的增长。想一探Pinterest的传奇吗?我们请来了Pinterest的两位创立者Yashwanth Nelapati 和 Marty Weiner,他们将以 Scaling Pinterest为题讲述关于Pinterest架构的充满戏剧化的传奇故事。他们说如果能在一年半前飞速发展时能看到有人做类似题材的演讲的话,他们就会有更多的选择,以避免自己在这一年半里做出的很多错误的决定。
这是一个很不错的演讲,充满了令人惊讶的细节。同时这个演讲也是很务实的,归根结底,它带来了可让大家选择的策略。极度推荐!
这篇演讲中有两个我最为看重的经验:
1.强大的架构在处理增长时通过简单增加相同的东西(服务器)来应对,同时还能保证系统的正确性。当遇到某种(性能)问题时,你想通过砸钱来扩容指的是你可以简单增加服务器(boxes)。如果你的架构能够做到这一点,那它就如金子一般强大而珍贵!
2. 当某些(性能问题)快到极限时大多数技术都会以他们自己的方式失败。这导致他们在审核工具时要考虑以下一些特性:成熟,好且简单,有名气且用的人多,良好的支持,持续的优异性能,很少失败,开源。按照这样的标准,他们选择了:MySQL, Solr, Memcache, and Redis,放弃了Cassandra ,Mongo。
这两点经验是相互联系的。遵循(2)中提到的标准的工具可以在扩容时简单增加服务器(boxes).当负载增加了,成熟的产品更少会有问题。当你遇到问题时,你至少希望它的社区团队能够帮助解决。当你使用的工具过于技巧化和过于讲究时,你会发现你遇到一堵无法逾越的墙。
在这段演讲里,碎片化(sharding)优于集群(clusterting)的观点是我认为最好的一部分。为了应对增长,通过增加资源,更少失败的模式,成熟,简单,良好的支持,最终圆满完成。请注意他们选择的工具以sharding的方式增长,而不是clustering。关于他们为什么选择sharding和他们如何做sharding是很有趣的事,这很可能触及到你以前未考虑过的场景。
现在,让我们看看Pinterest如何扩容:
(本段有些术语黑话不是很明白,望纠错)
启动于2010年三月--自我发现时期
此时此刻,你甚至不知道你在做的这个产品将要做什么。你有想法,迭代开发更新产品的频率很高。最终因遇到一些在现实生活中永远不会遇到的奇怪的简短的MySQL查询而结束。
早期的一些数字:
2011年1月
扔在潜伏前进中,产品得到了一些用户反馈。以下是数据:
每一个半月翻翻的疯狂增长阶段。
评论删除后,数据将无法恢复
评论(38)
引用来自“我的她最美”的评论
集群 —— 所有事情都是自动化的
这下面的有点是否写错?
这下面的有点是否写错?
一个新的索引需要一个新的表
为什么?
针对对象,每个本地ID都映射成MySQL Blob。开始时Blob使用的是JSON格式,之后会给转换成序列化的Thrift。
这句话没看懂,高手指点下。