如何快速扩展MySQL数据量？

阅读原文请点击： http://click.aliyun.com/m/22991/
摘要： 在一些评估里，我们（Pinterest）的发展比先前任何初创公司都要快。大约在2011年9月份，我们的基础设施都超过负载。一些NoSQL技术导致灾难性的后果，同时大量用于读的MySQL从属服务器，产生了大量令人恼火的Bug，特别是缓存。

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



  1 业务需求


系统总体要非常稳定，便于操作，便于拓展。我们想让数据库能从开始小存储量，能随着业务发展而拓展；

Pin友生成的内容必须能永久访问；

（支持）请求的N个Pin在板块中以确定的顺序(像按照创建时间倒序，或是按照用户特定的排序)（显示）。对于喜欢的Pin友，发Pin的Pin友列表等，也必须以特定的顺序；

为了简单，更新一般而言要保证最好的性能，为了获取最终一致性，需要额外的东西，如分布式事物日志。这是一个有趣（但不太容易）的事情！



  2 设计原理与笔记


由于我们想要的这些数据是横跨多个数据库的，我们不能使用数据库的join，外键或者收集所有数据的索引，不过他们可以被用于不能横跨数据库的子查询。

我们也需要支持负载均衡我们的数据。我们厌恶来回移动数据，尤其是逐项移动，因为容易出错，也容易让系统变得不必要的复杂。如果我们必须移动数据，最好移动一整个虚拟节点到物理节点。



为了实现快速成型，我们需要一个简单可用的解决方案，并且在我们的分布式数据平台上，节点要非常稳定。



所有的数据都需要被备份到从节点进行高可用，并为 MapReduce 转存到 S3。 在生产中，我们只与主节点交互。在生产中，你不能在从节点上读/写。从节点是滞后的，它会引发奇怪的bug。如果你共享数据，一般来说在生产中与从节点交互是没有优势的。



最终，我们需要一个好的方式来生成一个统一且唯一的ID（UUID）分配给所有我们的对象。



  3 我们如何切分数据


无论我们如何构建系统，都需要满足我们的业务要求并保证系统稳定，具有高性能，易于维护。换言之，我们需要系统不糟糕 ，因此我们选择成熟的技术-MySQL作为我们构建系统的基础。我们有意避免使用具有自动扩展功能的新技术，例如MongoDB，Cassandra 和Membase等，因为他们还不够成熟（并且他们会以无法预知的方式崩溃）。



悄悄话：我依旧建议初创公司避免使用花哨的新事物——尝试使用完全能够正常运行的MySQL。相信我，我有很多错误的实践（创伤）来证明这一点。
阅读原文请点击： http://click.aliyun.com/m/22991/