mongodb 与 mysql 易于扩展

Question

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

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

如果没有太多扩展 mysql （或 mongodb ）的经验，扩展 mongodb 会更容易，因为它具有自动分片等功能。 （寻找做过这两种工作的人的想法）我认为现在切换到 mongodb 会比处于“生产”状态并不得不迁移更容易。

想法？

Answer 1

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

1. 通过副本集读取缩放 。
2. 通过分片写入缩放。

它们不是灵丹妙药，但都很容易设置。副本集具有自动故障转移功能，这在使用 EC2 时实际上是必不可少的（它们具有随机故障节点的良好历史）。当您需要写入扩展时，MongoDB 有记录的升级流程< /a> 您的副本集为一系列分片副本集。

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

一些重要的注意事项：

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

扩展 mongodb 会更容易吗

在某种程度上，扩展将是一个“难题”。 MongoDB 擅长的地方是提供了一种通过复制真正水平扩展大量盒子的方法。根据我的经验，MySQL 的写入确实达到了大约两个框。您可以轻松配置 co-masters，但之后您必须开始处理各种分区，并且基本上失去了进行连接的能力。

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

它可能会。

想法？

从小处开始。让一件作品发挥作用，看看您是否喜欢它的运作方式。如果您有权访问 EC2 帐户，则可以轻松启动几台机器并进行游戏。 MongoDB 不是万能药，但它确实可以很好地解决许多现代 Web 问题。只需衡量您需要连接的程度:)