易于扩展 mongodb 与 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 的写入次数最多只有两个框。您可以轻松配置 co-masters，但之后您必须开始处理各种分区，并且您基本上失去了进行连接的能力。

我认为现在切换到 mongodb 比“生产”更容易

应该会的。

想法？

从小处着手。让一件工作，看看你是否喜欢它的工作方式。如果您可以访问 EC2 帐户，那么很容易启动几台机器并进行游戏。 MongoDB 不是灵丹妙药，但它确实可以很好地解决许多现代 Web 问题。只需衡量您需要连接的严重程度:)