如何快速扩展MySQL数据量？

很多时候由于MySQL技术导致的灾难性的后果，同时大量用于读的MySQL从属服务器，产生了大量令人恼火的Bug，特别是缓存。为了解决这个问题我们就需要重新架构整个存储模型，今天和大家分享的就是如何快速扩展MySQL数据容量的相关操作，希望可以帮助大家更好的学习MySQL ，一起来看看吧。

1 业务需求

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

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

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

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

2 设计原理与笔记

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

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

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

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

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

3 我们如何切分数据

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

悄悄话：我依旧建议初创公司避免使用花哨的新事物——尝试使用完全能够正常运行的MySQL。相信我，我有很多错误的实践（创伤）来证明这一点。

MySQL是成熟的，稳定的并且能够正常运行的。不仅我们使用MySQL，还有大量公司在广泛的使用。MySQL支持我们所需要的数据排序、范围查询功能并且具备行级事务等功能。它还有很多的特性，但是我们不需要或使用这些。尽管MySQL非常适合我们，但MySQL是单一解决方案，因此需要我们对数据进行分片。下面是我们的解决方案：

　　最开始时我们有8个EC2 服务,每个服务对应一个MySQL实例：