在我们的（当前MySQL）数据库中有超过1.2亿条记录，并且我们经常使用PHP中的复杂JOIN查询和应用程序级逻辑来触摸数据库。我们是一家以数据挖掘为主要关注点的营销公司，因此我们有许多大型报告需要每天，每周或每月运行。对于大型数据集，mongoDB或Cassandra比MySQL更好吗？
同时，客户服务在相同数据库的复制从服务器上运行。
我们希望能够在网络上实时发布这些报告，而不必为他们手动生成电子表格。但是，我们的许多报告都需要大量时间来提取数据（有些情况下超过一小时）。
我们不在云中运行，而是选择在我们的服务器机房中使用两台物理服务器进行操作。
考虑到这一切，我们最好的数据库选择是什么？
我认为你会错误地解决问题。
想想如果你放弃NoSQL，你会得到更好的性能并不是真的。在最底层，你正在写和检索一大块数据。这意味着你的瓶颈是（最有可能的）HDD I/O（这是常见的瓶颈）。
坚持使用硬件，暂时使用单片数据存储器是不可扩展的，正如您注意到的 - 在想要实时执行某些操作时会产生影响。
你有什么选择？您需要扩展您的服务器和软件设置（无论如何，这是您必须处理的任何NoSQL，在某些时刻坚持更快的硬盘驱动器）。 您也可能想要查看其他存储引擎（MyISAM和InnoDB除外 - 例如，看似将随机I/O转换为顺序I/O的更好引擎之一为TokuDB）。
实施更快的HDD子系统也将有助于您的需求（FusionIO，如果您有资源获得它）。
没有关于您的最终信息（服务器设置是什么，您使用的是什么MySQL版本以及您使用的存储引擎+数据大小），这都是猜测。
卡桑德拉仍然需要对Hadoop的MapReduce的，和MongoDB限制了并发关于MapReduce的...
...所以...
... 120条MIO记录不算多，和MySQL应该很容易处理。我的猜测是一个IO瓶颈，或者你正在做大量的随机读取而不是顺序读取。我宁愿雇用一个月左右的MySQL技术人员来调整模式和查询，而不是投资于新的解决方案。
如果您提供有关群集的更多信息，我们可能会帮助您更好地完成工作。 “NoSQL”本身并不是解决您的问题的方法。
尽管我不是MySQL的粉丝，但一旦数据量变大，我不得不说，你远远不需要迁移到NoSQL解决方案。 120M行并不是什么大问题：我目前正在使用的数据库在单个表中有600M左右，我们对其进行了有效的查询。从运营角度管理这么多数据是问题所在;质疑它不是。
这是关于正确的索引和加入时正确使用它们，其次是内存设置。找到你的慢查询（mysql慢查询日志FTW！），并学习使用解释关键字来了解它们的速度慢。然后调整您的索引，以便您的查询高效。此外，确保你了解MySQL的内存设置。文档中有很多页面解释他们如何工作，而且他们不太难理解。
如果你已经完成了这两件事情，但仍然有问题，请确保磁盘I/O不是问题。 然后如果有数据，您应该查看另一个查询数据的解决方案。
像Cassandra这样的NoSQL解决方案有很多好处。卡桑德拉擅长写数据。缩放写入操作非常简单 - 只需添加更多节点即可！但是，这种折衷是让数据很难恢复。从成本的角度来看，如果您在MySQl方面拥有专业知识，那么在完全切换您的底层架构之前，利用它并扩展您当前的解决方案，直至达到极限，可能会更好。
NoSQL系统在连接数据方面通常很薄弱。除非您对数据进行不同的建模，否则我会坚持使用RDBMS。它可能会给你最好的运行查询。 – Sam 2011-12-15 14:40:52
您可能最终会遇到更多麻烦，例如使用Cassandra，因为您的数据已建模为确认关系结构。基本上你必须重新编码一切，然后尝试优化NOSQL解决方案。考虑到你已经有了一些MySQL的专业知识，你可能会更容易地优化它。与MySQL相比，Cassandra也有点儿bug。所以请尝试优化您的查询作为其他答案提及，绝对是SSD而不是板驱动器。将大部分数据集保存在RAM中也将极大地帮助您，因此可以考虑使用InnoDB引擎来为您提供帮助。 – PSIXO 2014-07-17 11:25:23