找回密码
 骑士注册

QQ登录

微博登录

搜索
❏ 站外平台:

Linux中国开源社区 技术 查看内容

Pinterest架构:两年内月PV从零到百亿

2013-04-23 21:59    收藏: 1 分享: 2    

Solr

  • 只需要几分钟的安装时间,就可以投入使用
  • 不能扩展到多于一台的机器上(最新版本并非如此)
  • 尝试弹性搜索,但是以Pinterest的规模来说,可能会因为零碎文件和查询太多而产生问题。
  • 选择使用Websolr,但是Pinterest拥有搜索团队,将来可能会开发自己的版本。 

集群vs.分片

  • 在迅速扩展的过程中,Pinterest认识到每次负载的增加,都需要均匀的传播他们的数据。
  • 针对问题先确定解决方案的范围,他们选择的范围是集群和分片之间的一系列解决方案。

集群 —— 所有事情都是自动化的

  • 示例: Cassandra, MemBase, HBase
  • 结论: 太可怕了,不是在现在,可能在将来,但现在太复杂了,有非常多的故障点
  • 属性:
    • 自动化数据分布
    • 可移动数据
    • 可重新进行分布均衡
    • 节点间可通讯,大量的握手、对话
  • 有点:
    • 自动伸缩数据存储,至少白皮书上是这么说的
    • 安装简单
    • 在空间中分布存储你的数据,可在不同区域有数据中心
    • 高可用性
    • 负载均衡
    • 没有单点故障
  • 缺点 (来自用户一手的体验):
    • 还是相当年轻不成熟
    • 还是太复杂,一大堆节点必须对称的协议,这是一个在生产环境中难以解决的问题。
    • 很少的社区支持,有一个沿着不同产品线的分裂社区会减少每个阵营的支持。
    • 很少工程师有相关的知识,可能是很多工程师都没用过 Cassandra.
    • 复杂和和可怕的升级机制
    • 集群管理算法是一个 SPOF 单点故障,如果有个 bug 影响每个节点,这可能会宕机 4 次。
    • 集群管理器编码复杂,有如下一些失败的模式:
      • 数据重新均衡中断:当一个新机器加入然后数据开始复制,它被卡住了。你做什么工作?没有工具来找出到底发生了什么。没有社会的帮助,所以他们被困。他们又回到了MySQL。
      • 所有节点的数据损坏. What if there’s a bug that sprays badness into the write log across all of them and compaction or some other mechanism stops? Your read latencies increase. All your data is screwed and the data is gone.
      • 均衡不当而且很难修复. 非常常见,如果你有10个节点,你会注意到所有节点都在一个节点上,有一个手工处理方式,但会将所有负载分布到一个单节点上
      • 权威数据失效. 集群方案是很智能的。In one case they bring in a new secondary. At about 80% the secondary says it’s primary and the primary goes to secondary and you’ve lost 20% of the data. Losing 20% of the data is worse than losing all of it because you don’t know what you’ve lost.

分片(sharding) - 全凭人手

  • 裁决: 分片是赢家。我觉得他们分片的方案与Flicker非常相似。
  • 特点:
    • 如果去掉集群方式下所有不好的特点,就得到了分片。
    • 人工对数据进行分布。
    • 不移动数据。
    • 通过切分数据来分担负荷。
    • 节点不知道其它节点的存在。某些主节点控制一切。
  • 优点:
    • 可以通过切分数据库来扩大容量。
    • 在空间上分布数据。
    • 高可用。
    • 负载均衡。
    • 放置数据的算法十分简单。这是最主要的原因。虽然存在单点(SPOF),但只是很小的一段代码,而不是复杂到爆的集群管理器。过了第一天就知道有没有问题。
    • ID的生成很简单。
  • 缺点:
    • 无法执行大多数连接。
    • 没有事务功能。可能会出现写入某个数据库失败、而写入其它库成功的情况。
    • 许多约束只能转移到应用层实现。
    • schema的修改需要更多的规划。
    • 如果要出报表,必须在所有分片上分别执行查询,然后自己把结果合起来。
    • 连接只能转移到应用层实现。
    • 应用必须应付以上所有的问题。

何时选择分片?

  • 当有几TB的数据时,应该尽快分片。
  • 当Pin表行数达到几十亿,索引超出内存容量,被交换到磁盘时。
  • 他们选出一个最大的表,放入单独的数据库。
  • 单个数据库耗尽了空间。
  • 然后,只能分片。

分片的过渡

  • 过渡从一个特性的冻结开始。
  • 确认分片该达到什么样的效果——希望尽少的执行查询以及最少数量的数据库去呈现一个页面。
  • 剔除所有的MySQL join,将要做join的表格加载到一个单独的分片去做查询。
  • 添加大量的缓存,基本上每个查询都需要被缓存。
  • 这个步骤看起来像:
  • 1 DB + Foreign Keys + Joins
  • 1 DB + Denormalized + Cache
  • 1 DB + Read Slaves + Cache
  • Several functionally sharded DBs+Read Slaves+Cache
  • ID sharded DBs + Backup slaves + cache
  • 早期的只读奴节点一直都存在问题,因为存在slave lag。读任务分配给了奴节点,然而主节点并没有做任何的备份记录,这样就像一条记录丢失。之后Pinterest使用缓存解决了这个问题。
  • Pinterest拥有后台脚本,数据库使用它来做备份。检查完整性约束、引用。
  • 用户表并不进行分片。Pinterest只是使用了一个大型的数据库,并在电子邮件和用户名上做了相关的一致性约束。如果插入重复用户,会返回失败。然后他们对分片的数据库做大量的写操作。

如何进行分片?

  • 可以参考Cassandra的ring模型、Membase以及Twitter的Gizzard。
  • 坚信:节点间数据传输的越少,你的架构越稳定。
  • Cassandra存在数据平衡和所有权问题,因为节点们不知道哪个节点保存了另一部分数据。Pinterest认为应用程序需要决定数据该分配到哪个节点,那么将永远不会存在问题。
  • 预计5年内的增长,并且对其进行预分片思考。
  • 初期可以建立一些虚拟分片。8个物理服务器,每个512DB。所有的数据库都装满表格。
  • 为了高有效性,他们一直都运行着多主节点冗余模式。每个主节点都会分配给一个不同的可用性区域。在故障时,该主节点上的任务会分配给其它的主节点,并且重新部署一个主节点用以代替。
  • 当数据库上的负载加重时:
  • 先着眼节点的任务交付速度,可以清楚是否有问题发生,比如:新特性,缓存等带来的问题。
  • 如果属于单纯的负载增加,Pinterest会分割数据库,并告诉应用程序该在何处寻找新的节点。
  • 在分割数据库之前,Pinterest会给这些主节点加入一些奴节点。然后置换应用程序代码以匹配新的数据库,在过渡的几分钟之内,数据会同时写入到新旧节点,过渡结束后将切断节点之间的通道。
查看其它分页:

最新评论

我也要发表评论

收藏

返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。