15

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

我需要实施一个解决方案来快速扩展这个应用程序，但我不确定我是否应该追求分片或集群，因为我不确定他们每个人的优缺点是什么，我正在考虑做一个分区/复制方法，但我认为如果负载在写入上，这无济于事吗？

4

4 回答 4

2

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

于 2017-06-05T11:20:49.537 回答
1

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

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

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

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

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

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

于 2011-01-04T14:45:55.403 回答
1

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

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

于 2011-01-04T17:09:49.427 回答
-2

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

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

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

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

于 2011-09-11T15:15:51.780 回答