Ben*_*yer 6 mysql database mongodb cassandra
在我们(当前的MySQL)数据库中有超过1.2亿条记录,我们经常在PHP中使用复杂的JOIN查询和应用程序级逻辑来触摸数据库.我们是一家以数据挖掘为主要营销公司,因此我们有许多大型报告需要每天,每周或每月运行.
同时,客户服务在同一数据库的复制从属上运行.
我们希望能够在网络上实时发布这些报告,而不必为他们手动生成电子表格.但是,我们的许多报告都需要花费大量时间来提取数据(在某些情况下,超过一小时).
我们不在云中运行,而是选择在我们的服务器机房中使用两台物理服务器进行操作.
鉴于这一切,我们对数据库的最佳选择是什么？
N.B*_*.B. 11
我认为你对问题的看法是错误的.
想想如果你使用NoSQL,你将获得更好的性能并不是真的.在最低级别,您正在编写和检索大量数据.这意味着你的瓶颈是(很可能)HDD I/O(这是常见的瓶颈).
坚持使用硬件并使用单片数据存储是不可扩展的,正如您所注意到的那样 - 在想要实时执行某些操作时会产生影响.
你有什么选择？你需要扩展你的服务器和软件设置(无论如何你都要使用任何NoSQL,在某些时候坚持使用更快的硬盘).您还可能希望研究替代存储引擎(MyISAM和InnoDB除外) - 例如,似乎将随机I/O转换为顺序I/O的更好的引擎之一是TokuDB.
实现更快的HDD子系统也可以满足您的需求(FusionIO, 如果您有资源获得它).
如果没有关于您的最终信息(服务器设置是什么,您正在使用的MySQL版本以及您正在使用的存储引擎+数据大小),这都是猜测.
Cassandra仍然需要Hadoop用于MapReduce,而MongoDB在MapReduce方面的并发性有限......
......所以......
... 120兆的记录并不多,MySQL应该能够轻松处理.我的猜测是IO瓶颈,或者您正在进行大量随机读取而不是顺序读取.我宁愿雇佣MySQL技术人员一个月左右来调整您的架构和查询,而不是投资到新的解决方案.
如果您提供有关群集的更多信息,我们可能会为您提供更好的帮助."NoSQL"本身并不是解决问题的方法.
小智 5
一旦你的数据变得庞大,我就不会成为MySQL的粉丝,我不得不说你无需转向NoSQL解决方案.120M行并不是什么大问题:我目前正在使用的数据库在一个表中只有600M,我们可以高效地查询它.从操作角度管理那么多数据是问题所在; 查询它不是.
这一切都与正确的索引以及加入时正确使用它们有关,其次是内存设置.找到你的慢查询(mysql慢查询日志FTW!),并学习使用explain关键字来理解它们的速度很慢.然后调整索引,以便查询有效.此外,请确保您了解MySQL的内存设置.文档中有很多页面解释它们是如何工作的,并且它们并不难理解.
如果您已经完成了这两件事并且仍然遇到问题,请确保磁盘I/O不是问题.然后,您应该查看另一个查询数据的解决方案.
像Cassandra这样的NoSQL解决方案有很多好处.Cassandra在编写数据方面非常出色.缩放您的写入非常简单 - 只需添加更多节点!但权衡的是,将数据退出更难.从成本角度来看,如果您具有MySQl的专业知识,那么最好利用它并扩展当前的解决方案,直到它完全切换您的底层架构之前达到限制.