集群、分片或简单的分区/复制

Posted 2023-02-16

【中文标题】集群、分片或简单的分区/复制

【英文标题】：Clustering, Sharding or simple Partition / Replication

【发布时间】：2011-06-03 10:39:32

【问题描述】：

我们创建了一个 Facebook 应用程序，它获得了很多病毒式传播。问题是我们的数据库开始变得非常满（有些表现在有超过 2500 万行）。到了该应用程序刚刚停止工作的地步，因为有成千上万的写入队列要进行。

我需要实施一个解决方案来快速扩展这个应用程序，但我不确定我应该追求 Sharding 还是 Clustering，因为我不确定什么是他们每个人的优点和缺点，我正在考虑使用 Partition / Replication 方法，但我认为如果写入负载没有帮助？ p>

【问题讨论】：

从基础开始——你有索引吗？它们是应用程序的正确索引吗？

是的，我确实有很多索引，而且它们绝对是正确的，我们没有看到缓慢的查询，而是看到大量的写入指令。

【参考方案1】：

当单个节点达到其硬件无法承受负载的程度时，就会出现集群/分片/分区。但是您的硬件仍有扩展空间。 这是我开始被此类问题困扰时学到的第一课

【参考方案2】：

嗯，要理解这一点，您需要了解 mysql 如何处理集群。有两种主要方法可以做到这一点。您可以进行 Master-Master 复制或 NDB（网络数据库）集群。

Master-Master 复制对写入负载没有帮助，因为两个 master 都需要重放每一个发出的写入（所以你什么也得不到）。

当且仅当您主要进行主键查找时，NDB 集群才会非常适合您（因为只有使用 PK 查找才能使 NDB 比常规的主-主设置更有效地运行）。所有数据都在许多服务器之间自动分区。就像我说的那样，如果您的绝大多数查询只不过是 PK 查找，我只会考虑这一点。

---

所以剩下两个选择。分片并远离 MySQL。

分片是处理此类情况的好选择。但是，要充分利用分片，应用程序需要充分了解它。因此，您需要返回并重写所有数据库访问代码，以便为每个查询选择正确的服务器。并且根据您的系统当前的设置方式，可能无法有效地分片...

但我认为最适合您需求的另一个选择是从 MySQL 切换。由于无论如何您都需要重写您的数据库访问代码，因此切换到 NoSQL 数据库应该不会太难（同样，取决于您当前的设置）。那里有大量的 NoSQL 服务器，但我喜欢 MongoDB。它应该能够毫无顾虑地承受您的写入负载。请注意，您确实需要一个 64 位服务器才能正确使用它（使用您的数据量）。

【讨论】：

对不起......“最佳”选项正在完全脱离关系数据库？当您对他存储的内容一无所知时，您如何提出这样的建议？

共享时无需重写所有数据库访问代码。只需创建一个分发表，告诉您哪个用户在哪个服务器上，然后将它们发送到完成所有处理的服务器。换句话说，只有在身份验证时您才需要进行任何代码更改。

【参考方案3】：

复制是为了数据备份而不是为了性能，所以它没有问题。

嗯，8GB RAM 仍然不是那么多，你可以拥有数百 GB RAM 和相当大的硬盘空间，MySQL 仍然可以为你工作。

当单个节点达到其硬件无法承受负载的程度时，就会出现集群/分片/分区。但您的硬件仍有扩展空间。

如果您不想升级硬件，那么您需要提供有关数据库设计的更多信息，以及是否有很多连接，以便可以深入考虑上述选项。

【讨论】：

复制也是为了可靠性。

【参考方案4】：

2500 万行对于结构良好的关系数据库来说是一个完全合理的大小。但是，您应该记住的是，您拥有的索引越多（并且它们越全面），您的写入速度就会变慢。索引旨在以牺牲写入速度为代价来提高查询性能。确保您没有被过度索引。

什么样的硬件在为这个数据库提供动力？你有足够的内存吗？更改这些属性比尝试实现复杂的 RDBMS 负载平衡技术要容易得多，尤其是在时间紧迫的情况下。

【讨论】：

嘿亚当，我们在亚马逊使用一个 c1.xlarge 实例，它有大约 20 ECUS 和 8GB 内存，请记住，这 2500 万行在 4 天内插入！ :S 这就是为什么我认为即使我们优化了很多我们的数据库模式（我们现在正在处理），我们也需要尽快有一个解决方案来处理这么多的写入。