mongodb与mysql的易扩展性

Question

我正在创建一个Grails应用程序，它是一个移动应用程序的后端。它目前部署在亚马逊EC2上。它将数据持久化到mysql数据库中。一个当前指向数据库的实例。我计划在负载均衡器后面部署应用程序的多个实例，并最终将读请求发送到数据库的从实例。我们计划在未来几个月发布，并拥有几千名用户的测试组。它的读操作比写操作更密集。

我们已经研究过使用mongodb而不是sql，并认为这是一个很好的解决方案。

没有太多扩展mysql (或mongodb )的经验，扩展mongodb会更容易，因为它有自动分片等特性。(寻找两个都做过的人的想法)我认为现在切换到mongodb会更容易，而不是处于“生产”状态并不得不迁移。

有什么想法？

Answer 1

MongoDB有两个版本的"scaling"：

1. Read scaling通过sharding.

实现的

1. Read scaling

它们不是银弹，但它们都很容易设置。副本集具有自动故障转移功能，这在使用EC2时非常重要(它们具有随机故障节点的良好历史记录)。当你需要写伸缩时，MongoDB会将你的副本集documented processes for upgrading到一系列分片的副本集。

不幸的是(据我所知)，像scalr这样的东西并不真正支持自动伸缩。因此，您必须使用自己的解决方案来添加和删除集合中的节点。

一些重要的考虑因素：

云中的

1. 磁盘IO性能很差。
2. 如果你使用副本集进行读操作，请确保你的驱动程序/数据包装器能够处理读操作的分布。就像现在的read".
3. 64-bit还不是“免费的”一样，你需要决定"write还是MySQL机器“。MongoDB真的很想在64位硬件上运行。这是一个成本限制，因为你可能不得不增加4 2GB的机器，而不是2 2GB的机器(我不认为这是一个很大的限制，但我也知道作为一个startup).
4. MongoDB是什么样的仍然是新的技术。这些列表非常活跃，人们在生产中使用它来处理非常大的数据集。但这仍然是一个新产品，你必须准备好从命令行开始工作，解析文档并提出问题。

扩展mongodb会更容易吗

在某种程度上，扩展将是一个“困难”的问题。MongoDB做得很好的是提供了一种方法，可以通过复制向外横向扩展许多盒子。根据我的经验，MySQL最多只能写两个盒子。你可以很容易地配置co-master，但在那之后，你必须开始搞各种分区，你基本上就失去了连接的能力。

我在想，现在切换到mongodb会比在‘生产’中更容易

很可能会这样。

的想法？

从小事做起。让其中的一块工作，看看你是否喜欢它的工作方式。如果你有一个EC2帐户，那么就很容易启动几台机器来玩游戏。MongoDB并不是万能的，但它确实很好地解决了许多现代网络问题。只需测量一下您有多需要连接:)