Pinterest 数据切分：解惑快速扩展 MySQL 的数据量

Posted 2020-08-06

这是一个探讨怎样在多个mysql服务器之间切分数据的技术问题。早在2012年我们就完成了这样分片方案，我们现在仍在使用这套方案存储核心数据。
在讨论怎样切分数据之前，我们不妨先与数据亲密接触。机舱里的灯光，附在草莓上的巧克力，星际迷航开始..
Pinterest是一个发现引擎，寻找所有你所感兴趣的（入门基础教程qkxue.net）。从数据的角度来看，Pinterest是世界上一大型的人类构建的的兴趣图。有超过500亿的Pin被Pin友保存到10亿的板块上，用户再次Pin，喜欢其它人的Pin（简单的浅拷贝），关注其它Pin友、板块和兴趣，然后查看主页上所订阅Pin友的所有资讯、画板和他们关注的兴趣。太棒了，现在来拓展吧。

成长的痛

2011年我们公司获得大家的认同。 在一些评估里，我们的发展比先前任何初创公司都要快（手机app开发ty300.com）。大约在2011年9月份，我们的基础设施都超过负载。一些NoSQL技术导致灾难性的后果，同时大量用于读的MySQL从属服务器，产生了大量令人恼火的Bug，特别是缓存。我们重新架构了整个存储模型。令人欣喜的是，新架构还是比较有效果的，基本满足了我们的要求。
业务需求

系统总体要非常稳定，便于操作，便于拓展。我们想让数据库能从开始小存储量，能随着业务发展而拓展
Pin友生成的内容必须能永久访问
(支持）请求的N个Pin在板块中以确定的顺序(像按照创建时间倒序，或是按照用户特定的排序)（显示）。对于喜欢的Pin友，发Pin的Pin友列表等，也必须以特定的顺序.
为了简单，更新一般而言要保证最好的性能，为了获取最终一致性，需要额外的东西，如分布式事物日志。这是一个有趣（但不太容易）的事情!

设计原理与笔记

由于我们想要的这些数据是横跨多个数据库的，我们不能使用数据库的join，外键或者收集所有数据的索引，不过他们可以被用于不能横跨数据库的子查询。
我们也需要支持负载均衡我们的数据。我们厌恶来回移动数据，尤其是逐项移动，因为容易出错，也容易让系统变得不必要的复杂。如果我们必须移动数据，最好移动一整个虚拟节点到物理节点。
为了实现快速成型，我们需要一个简单可用的解决方案，并且在我们的分布式数据平台上，节点要非常稳定。
所有的数据都需要被备份到从节点进行高可用，并为 MapReduce 转存到 S3。 在生产中，我们只与主节点交互。在生产中，你不能在从节点上读/写。从节点是滞后的，它会引发奇怪的bug。如果你共享数据，一般来说在生产中与从节点交互是没有优势的。
最终，我们需要一个好的方式来生成一个统一且唯一的ID（UUID）分配给所有我们的对象。

无论我们如何构建我们的系统，都需要满足我们的业务要求并保证系统稳定，具有高性能，易于维护。换言之，我们需要我们的系统不糟糕 ，因此我们选择成熟的技术，MySQL作为我们构建系统的基础。我们有意避免使用具有自动扩展功能的新技术，例如MongoDB,Cassandra 和Membase等，因为他们还不够成熟（并且他们会以无法预知的方式崩溃）。
悄悄话：我依旧建议初创公司避免使用花哨的新事物——尝试使用完全能够正常运行的MySQL.相信我,我有很多错误的实践（创伤）来证明这一点。