MongoDB或Cassandra对于大型数据集来说比MySQL更好吗？

Question

在我们目前的MySQL数据库中，有超过1.2亿条记录，我们经常使用复杂的JOIN查询和PHP应用程序级别逻辑来操作数据库。我们是一家以数据挖掘为主要业务的市场营销公司，因此我们需要每天、每周或每月运行许多大型报告。

同时，客户服务部门在同一数据库的复制节点上操作。

我们希望能够实时在Web上生成这些报告，而不必手动生成电子表格。然而，我们的许多报告需要很长时间才能拉取数据（在某些情况下，超过一个小时）。

我们没有在云端运行，而是选择在我们的服务器房使用两台物理服务器。

鉴于这一切，对于我们来说，最好的数据库选项是什么？

- Ben Overmyer

---

NoSQL系统通常在数据连接方面非常薄弱。除非您对数据进行了不同的建模，否则我建议您仍然使用关系型数据库。这样可能会为您提供最佳的查询性能。 - Sam

你可能会遇到更多麻烦，例如使用Cassandra，因为你的数据被建模以符合关系结构。基本上，你将不得不重新建模一切，然后尝试优化NOSQL解决方案。考虑到你已经具有一些MySQL方面的专业知识，你可能会更容易地进行优化。此外，与MySQL相比，Cassandra有点不稳定。因此，像其他答案提到的那样尝试优化查询，并绝对选择SSD而不是机械硬盘。将大部分数据集保留在RAM中也将极大地帮助，因此请考虑使用InnoDB引擎来帮助你实现这一点。 - Igor Čordaš

还有一件简单的事情需要考虑，就是为了测试一些假设，可以将数据库复制到另一台机器上的RamDisk（甚至可以使用一些高端工作站而不是服务器），然后在其上运行一些查询。您甚至可以设置一些A/B测试，意味着某些报告生成（因为它们都是读取操作）将针对您的服务器，而其他报告将针对此测试机器。如果从测试机器读取时性能显著提高，则说明如果改善HDD I/O，您可以期望多大的改进。 - Igor Čordaš

Answer 1

我认为你在处理这个问题上走错了方向。

认为加入NoSQL会获得更好的性能并不完全正确。在最低层级别上，您需要写入和检索相当大量的数据。这意味着您的瓶颈很可能是HDD I/O（这是常见的瓶颈）。

暂时保持您所拥有的硬件，并使用单块数据存储是不可扩展的，正如您所注意到的，想要实时执行某些操作时会产生影响。

你有哪些选择呢？你需要扩展你的服务器和软件设置（这也是你必须做的任何NoSQL，换用更快的硬盘）。您还可以考虑其他存储引擎（除了MyISAM和InnoDB之外的引擎，例如，似乎将随机I/O转换为顺序I/O的更好的引擎之一是TokuDB）。

实施更快的HDD子系统也有助于满足您的需求（如果您有资源，则可以使用FusionIO）。

没有更多关于您的端的信息（服务器设置是什么，您正在使用什么MySQL版本以及您正在操作的存储引擎+数据大小），这都是猜测。

- N.B.

---

主服务器正在运行CentOS 5.4，Intel Xeon双核3GHz，32GB的RAM和500GB的硬盘空间，以RAID 5配置。MySQL版本为5.0.77。PHP版本为5.1.6。数据库几乎完全采用MyISAM。我们不使用blob类型，大部分字段为微小的varchar（小于64）或smallint/tinyint类型。有少量文本字段。 - Ben Overmyer

看起来你肯定可以从TokuDB存储引擎或者甚至InnoDB中受益。它们由于存储和操作数据的方式而表现更好，能够更好地扩展。MyISAM在处理大型数据集时性能会下降。32GB的RAM意味着如果使用InnoDB引擎，则整个工作数据集可能适合RAM，这绝对是您情况下的一个很好的解决方案。 - N.B.

有没有一种方法可以在不影响生产操作的情况下热插拔存储引擎？也许通过一些复制技巧？ - Ben Overmyer

RAID 10配置将使你获得大约比RAID 5配置高3倍的写入性能，以及略微提高的读取性能。你只需要两倍的磁盘！ :-/ - Dave Rix

我们计划使用新的服务器硬件进行RAID 10，包括在某些方面使用SSD而不是机械驱动器。 - Ben Overmyer

Answer 2

卡桑德拉仍需要使用Hadoop进行MapReduce，而MongoDB在MapReduce方面的并发性有限...因此...120百万条记录并不算太多，MySQL应该可以轻松处理。我猜是IO瓶颈，或者你正在进行大量随机读取而不是顺序读取。我宁愿雇用一个MySQL技术专家一个月左右来调整您的架构和查询，而不是投资于新解决方案。如果您提供有关集群的更多信息，我们可能能够更好地帮助您。 "NoSQL"本身并不能解决您的问题。

- Mario

Answer 3

尽管我不是MySQL的粉丝，但是当你的数据变得庞大时，我必须说，你还远没有需要转向NoSQL解决方案的地步。120M行数据并不算什么：我目前使用的数据库中单个表格就有约600M行数据，而我们可以高效查询。从运维角度管理这么多数据是个问题，但查询并不是。

关键在于适当的索引以及在连接时正确使用它们，其次是内存设置。找到慢查询（mysql慢查询日志万岁！），学会使用“explain”关键字来理解为什么它们很慢。然后调整索引使查询更加高效。此外，确保您了解MySQL的内存设置。文档中有很好的页面解释它们的工作原理，而且并不难理解。

如果您已经完成了以上两件事情，但仍然存在问题，请确保磁盘I/O不是问题所在。然后，如果是，您应该考虑另一种查询数据的解决方案。

像Cassandra这样的NoSQL解决方案有很多优点。Cassandra非常擅长写入数据。扩展写入非常容易——只需添加更多节点！但是，代价是更难取回数据。从成本的角度来看，如果您具备MySQl专业知识，最好利用它并扩展当前解决方案，直到它达到极限，然后再完全切换底层架构。

- paradoxbomb