群集，分片或简单分区/复制

Question

我需要您就这个问题向专家提出一些建议。问题是我们几天前创建了一个Facebook应用程序，幸运的是它得到了大量的病毒式传播，问题是我们的数据库开始变得非常满（一些表现在有超过2500万行）并且它达到了这一点该应用程序刚停止工作，因为有一个成千上万的写入队列。

我需要实现一个快速扩展这个应用程序的解决方案但是我不确定我是否应该进行Sharding或Clustering，因为我不确定他们每个人的专业人员和内容是什么，我正在考虑做一个分区/复制方法，但我认为如果负载在写入上会有帮助吗？

Answer 1

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

Master-Master复制对写入加载没有帮助，因为两个主人都需要重放每次发出的写入（因此你没有获得任何东西）。

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

---

因此，还有两个选项。分片并远离MySQL。

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

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

Answer 2

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

什么样的硬件为这个数据库供电？你有足够的内存吗？更改这些属性比尝试实现复杂的RDBMS负载平衡技术要容易得多，特别是如果您处于时间紧迫状态。

Answer 3

当单个节点达到其硬件无法承受负载的点时，就会出现群集/分片/分区。但是你的硬件还有扩展空间。 这是我开始遇到这些问题时学到的第一课

Answer 4

复制用于数据备份而非性能，因此无可置疑。

嗯，8GB内存仍然不是那么多，你可以拥有相当大的硬盘空间的数百GB RAM，MySQL仍然适合你。

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

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