我正在创建一个Grails应用程序,它是移动应用程序的后端.它目前部署在Amazon EC2上.它将数据持久保存到mysql数据库.一个实例当前指向数据库.我计划在负载均衡器后面部署应用程序的多个实例,并最终将读取请求发送到数据库的从属实例.我们计划在未来几个月内发布,并拥有一个拥有数千名用户的测试版.它比读写更密集.
我们已经研究过使用mongodb而不是sql,并将其视为一个很好的解决方案.
没有很多扩展mysql(或mongodb)的经验,因为它具有自动分片等功能,所以缩放mongodb会更容易.(寻找那些同时做过这些事情的人们的想法)我认为现在切换到mongodb会更容易,而不是"生产"并且不得不迁移.
思考？
MongoDB有两个版本的"缩放":
通过副本集读取缩放比例.
通过分片写入缩放.
它们不是银子弹,但它们都非常容易安装.副本集具有自动故障转移功能,这在使用EC2时几乎是必不可少的(它们具有随机故障节点的良好历史记录).当您需要写入扩展时,MongoDB已记录了将副本集升级为一系列分片副本集的过程.
不幸的限制是(最后我检查过),像scalr这样的东西并不真正支持自动缩放.因此,您必须推出自己的解决方案,以便从集合中添加和删除节点.
一些重要的考虑:
磁盘IO性能在云中是粗略的.良好的性能是关于你可以解决问题的RAM数量.
如果您正在使用副本集进行读取,请确保您的驱动程序/数据包装器能够处理读取的分发.就像MySQL一样,它目前不是"免费"的,你需要决定"写与读".
64位机器.MongoDB真的想在64位硬件上运行.这是一个成本问题,因为你可能不得不使用4GB机器而不是2GB机器(我不认为这是一个很大的限制,但我也知道成为一家初创公司是什么样的).
MongoDB仍然是新技术.这些列表非常活跃,人们在生产中使用它来处理非常大的数据集.但这仍然是一个新产品,您必须准备好从命令行工作并解析文档并提出问题.
是否更容易扩展mongodb
在某种程度上,缩放将是一个"困难"的问题.MongoDB做得很好,提供了一种通过复制水平扩展大量盒子的方法.根据我的经验,MySQL实际上大约有两个写入框.你可以很容易地配置共同主人,但在那之后你必须开始乱搞各种分区,你基本上失去了连接的能力.
我认为现在切换到mongodb会更容易,而不是'生产'
它可能会.
思考？
从小处开始.得到一件工作,看看你是否喜欢它的工作原理.如果您可以访问EC2帐户,那么可以轻松启动几台计算机并进行游戏.MongoDB不是灵丹妙药,但它适用于许多现代Web问题.只测量你需要加入多么糟糕:)
京公网安备 11010802040832号 | 京ICP备19059560号-6 