易于扩展mongodb vs mysql

Question

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

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

没有很多扩展mysql（或mongodb）的经验，因为它具有自动分片等功能，所以缩放mongodb会更容易。 （寻找那些同时做过这些事情的人们的想法）我认为现在切换到mongodb会更容易，而不是“生产”并且不得不迁移。

思想？

Answer 1

MongoDB有两个版本的“缩放”：

1. 通过replica sets了解扩展。
2. 通过sharding进行缩放。

它们不是银子弹，但它们都非常容易安装。副本集具有自动故障转移功能，这在使用EC2时几乎是必不可少的（它们具有随机故障节点的良好历史记录）。当您需要写入缩放时，MongoDB将您的副本documented processes for upgrading设置为一系列分片副本集。

不幸的限制是（最后我检查过），像scalr这样的东西并不真正支持自动缩放。因此，您必须推出自己的解决方案，以便从集合中添加和删除节点。

一些重要的考虑因素：

1. 磁盘IO性能在云端是粗略的。好的表现就是你可以解决这个问题的RAM量。
2. 如果您正在使用副本集进行读取，请确保您的驱动程序/数据包装器能够处理读取的分发。就像MySQL一样，它目前不是“免费”，你需要决定“写与读”。
3. 64位计算机。 MongoDB真的想在64位硬件上运行。这是一个成本问题，因为你可能不得不使用4GB机器而不是2GB机器（我不认为这是一个很大的限制，但我也知道成为一家初创公司是什么样的。）
4. MongoDB仍然是新技术。这些列表非常活跃，人们在生产中使用它来处理非常大的数据集。但这仍然是一个新产品，你必须准备好从命令行工作并解析文档并提出问题。

  

扩展mongodb会更容易吗

在某种程度上，缩放将成为一个“难”的问题。 MongoDB做得很好，提供了一种通过复制水平扩展大量盒子的方法。根据我的经验，MySQL实际上大约有两个写入框。您可以轻松配置共同主人，但之后您必须开始进行各种分区，并且您基本上无法进行连接。

  

我认为现在切换到mongodb会更容易，而不是'生产'

可能会。

  

思想？

从小处开始。得到一件工作，看看你是否喜欢它的工作原理。如果您可以访问EC2帐户，那么可以轻松启动几台计算机并进行游戏。 MongoDB不是灵丹妙药，但它适用于许多现代Web问题。只需衡量你需要加入的程度：）