数据损毁！250 亿美金的 Pinterest，在数据库选型上的翻车经历。

原文 https://read.engineerscodex.com/p/how-pinterest-scaled-to-11-million

Pinterest 是一个以图片为主的社交网络，用户可以将图片保存或 "钉 / pin" 在自己的图板上。Pinterest 在 2019 年上市，目前市值 250 亿美金。本文内容主要根据 2012 年 Scaling Pinterest 的分享 www.infoq.com/presentations/Pinterest/

2012 年 1 月，Pinterest 的月独立用户数量达到 1170 万，而当时只有 6 名工程师。

Pinterest 于 2010 年 3 月推出，是当时月活用户突破 1000 万最快的公司。

扩展 Pinterest 的经验教训

• 使用已知的成熟技术。Pinterest 当时涉足较新的技术，导致了数据损坏等问题。

• 保持简单。(反复出现的主题！）。

• 不要太有创意。团队采用的架构可以增加更多相同的节点来扩大规模。

• 限制选项。

• 数据库分片 > 集群。这减少了跨节点的数据传输，是件好事。

• 享受乐趣！新工程师能够在第一周内贡献代码。

2010 年 3 月：Closed beta 发布，1 名工程师

Pinterest 于 2010 年 3 月推出，当时只有一个小型 MySQL 数据库、一个小型 web server 和一名工程师（还有两位联合创始人）。

2011 年 1 月：10,000 名用户，2 名工程师

九个月后的 2011 年 1 月，Pinterest 的架构已经发展到可以处理更多用户。当时他们仍然只接受邀请，只有两名工程师。

他们拥有

• 基本的 web server 技术栈（亚马逊 EC2、S3 和 CloudFront）

• 用于后端的 Django（Python）

• 4 台 web server 作为冗余

• NGINX 作为反向代理和负载均衡。

• 1 个 MySQL 主数据库 + 1 个只读数据库

• 用于计数的 MongoDB

• 1 个任务队列和 2 个任务处理器，用于异步任务

2011 年 10 月：320 万用户，3 名工程师

从 2011 年 1 月到 2011 年 10 月，Pinterest 的增长速度极快，用户数量每隔一个半月就翻一番。

他们在 2011 年 3 月推出的 iPhone 应用程序是推动这一增长的因素之一。

当事物快速发展时，技术出现问题的频率会超出你的预期。

这时Pinterest 犯了一个错误：他们把架构弄得过于复杂了。

他们只有 3 名工程师，但却采用了 5 种不同的数据库技术来存放数据。

他们既要手动对 MySQL 数据库进行分片，又要使用 Cassandra 和 Membase（现在的 Couchbase）对数据进行集群。

他们 "过于复杂的技术栈"：

• Web server 栈（EC2 + S3 + CloudFront）

• Pinterest 开始使用 Flask（Python）作为后端服务器

• 16 台 web server

• 2 个 API 引擎

• 2 个 NGINX 代理服务器

• 5 个手动分片的 MySQL DB + 9 个只读

• 4 个 Cassandra 节点

• 15 个 Membase 节点（3 个独立集群）

• 8 个 Memcache 节点

• 10 个 Redis 节点

• 3 个任务路由器 + 4 个任务处理器

• 4 个 Elastic Search 节点

• 3 个 Mongo 集群

⚠️ 集群崩了

数据库集群 (Database Clustering) 是将多个数据库服务器连接起来作为一个系统共同工作的过程。

从理论上讲，集群可以自动扩展数据存储、提供高可用性、自由负载平衡，并且不会出现单点故障。

遗憾的是，在实践中，集群过于复杂，升级机制困难，而且存在一个大的单点故障 （SPOF）。

每个 DB 都有一个集群管理算法，在 DB 之间进行路由。

当一个数据库出现问题时，就会添加一个新的数据库来替代它。

理论上，集群管理算法应该可以很好地处理这个问题。

但实际上，Pinterest 的集群管理算法中存在一个 bug，破坏了所有节点上的数据，破坏了数据该如何重新平衡，并产生了一些无法修复的问题。

Pinterest 的解决方案是什么？从系统中移除所有集群技术（Cassandra、Membase）。全面采用 MySQL + Memcached（更成熟）。

MySQL 和 Memcached 都是久经考验的技术。Facebook 利用这两种技术创建了世界上最大的 Memcached 系统，每秒轻松处理数十亿次请求。

2012 年 1 月：1100 万用户，6 名工程师

2012 年 1 月，Pinterest 的月活跃用户约为 1100 万，日活跃用户在 1200 万到 2100 万之间。

此时，Pinterest 已经花时间简化了他们的架构。

他们删除了当时不太成熟的方案，如集群和 Cassandra，取而代之的是成熟的方案，如 MySQL、Memcache 和分片。

他们简化后的技术栈：

• 亚马逊 EC2 + S3 + Akamai（取代 CloudFront）

• AWS ELB（弹性负载平衡）

• 90 个 web servers + 50 个 API 引擎（使用 Flask）

• 66 个 MySQL DB + 66 个只读

• 59 个 Redis 实例

• 51 个 Memcache 实例

• 1 个 Redis 任务管理器 + 25 个任务处理器

• 分片式 Apache Solr（取代 Elasticsearch）

• 移除 Cassanda、Membase、Elasticsearch、MongoDB、NGINX

Pinterest 如何手动分片数据库

数据库分片 (Database Sharding) 是一种将单个数据集分割成多个数据库的方法。

优点：高可用性、负载平衡、数据放置算法简单、易于拆分数据库以增加容量、易于定位数据

Pinterest 首次对数据库进行分片时，需要冻结新功能发布。在几个月的时间里，他们以渐进和手动的方式对数据库进行了分片：

团队删除了数据库层中的表 Join 和复杂查询。他们添加了大量缓存。

由于跨数据库维护唯一约束需要额外的工作，他们将用户名和电子邮件等数据保存在一个巨大的、未分片的数据库中。

这个数据库下的所有表都存在于所有分片中。

手动分片的一个小例子

由于他们有数十亿个 "pin"，他们的数据库索引会耗尽内存。

他们会将数据库中最大的表转移到自己的数据库中。

然后，当数据库空间耗尽时，他们就会将其分片。

2012 年 10 月：2200 万用户，40 名工程师

2012 年 10 月，Pinterest 的月度用户约为 2200 万，但他们的工程团队却翻了两番，达到了 40 名工程师。

架构是一样的。他们只是增加了更多相同的系统。

• 亚马逊 EC2 + S3 + CDN（EdgeCast、Akamai、Level 3）

• 180 台 web servers + 240 个 API 引擎（使用 Flask）

• 88 个 MySQL DB + 88 个只读

• 110 个 Redis 实例

• 200 个 Memcache 实例

• 4 个 Redis 任务管理器 + 80 个任务处理器

• 分片式 Apache Solr

他们开始从 HDD 转向固态硬盘 SSD。

一个重要的教训是：有限的、经过验证的选择是件好事。

坚持使用 EC2 和 S3 意味着他们只有有限的配置可供选择，从而减少了麻烦，提高了简便性。

与此同时，新实例可以在几秒钟内准备就绪。这意味着他们可以在几分钟内添加 10 个 Memcache 实例。

Pinterest 的数据库结构 ID

和 Instagram 一样，Pinterest 也有一个独特的 ID 结构，因为他们有分片数据库。

他们的 64 位 ID 看起来像

分区 ID：哪个分区（16 位）

类型：对象类型，如针（10 位）

本地 ID：在表中的位置（38 位）

这些 ID 的查找结构是一个简单的 Python 字典。

数据库表

它们有对象表和映射表。

对象表适用于 pin、板块、评论、用户等。它们有一个映射到 MySQL blob（如 JSON）的本地 ID。

映射表用于对象之间的关系数据，如将板块映射到用户或将赞映射到 pin。它们有一个映射到完整 ID 和一个时间戳的完整 ID。

为了提高效率，所有查询都使用 PK（主键）或索引查找。他们删除了所有 JOIN。

---

译者语，Pinterest 高速发展的时期正好也出现了各种新数据库系统。尤其是 NoSQL 这块，除了 Pinterest 提到过的这些，还有 Riak, Tokyo Cabinet, Voldemort 等。

还是那句话，我们应该采用无聊的技术去构建创新的产品，而不是倒过来。