3

我们正在构建一个带有 Rails CMS 的移动应用程序来管理它。

我们的应用是什么样的？

该应用程序的每个管理员用户都可以设置一个具有非常少量数据的私人频道 - 大约 50 个短字符串。

然后，用户可以下载应用程序并注册几个不同的频道，并将数据从服务器获取到他们的设备。数据将存储在本地，除非管理员用户更新数据，否则不会再次获取数据（但我们假设它不会经常发生）。每个频道将可供不超过 500 台设备使用。

用户可以为频道做出贡献，但这些数据将存储在 S3 而不是数据库中。

2个要点：

  1. 大多数频道将活动 5 个月，而不是 500 个用户 +-。但大部分活动将在同一两天发生。
  2. 每个频道都适用于少量用户 (500) 但我们希望 :) 能够接触到数百名管理员用户。

使用 Rails 构建 CMS 我们看到使用 SimpleDB 比使用 DynamoDB 更加严格。但是，由于我们不是服务器专家，我们看到了 SimpleDB 的局限性，我们不知道 SimpleDB 是否可以处理我们将拥有的数据传输量（如果我们的应用程序成功的话）。另一个重要的一点是 DynamoDb 的成本要高得多，并且不取决于使用情况，而 SimpleDb 开始时会便宜得多。

问题是：

  1. simpleDB 能满足我们的需求吗？
  2. 如果我们的服务将来会增长，我们可以稍后迁移到 dynamoDB 吗？
4

1 回答 1

3

从一个新项目开始，并且真的不知道从使用中会发生什么，我会说更好的选择是使用 SimpleDB。听起来您的使用率不会很高，SimpleDB 应该能够处理这个问题。当你真的有很多负载时，dynamoDB 的真正威力就会出现。你似乎不属于那个类别。

如果您正确地设计了您的应用程序，如果您在某个时候决定 SimlpeDB 无法正常工作，那么在 SimpleDB 和 DynamoDB 之间切换应该是一项简单的任务。我一直在使用软件中的其他组件进行此类切换。由于这两个数据库都是 NoSQL，因此在两者之间转换应该没有问题。只需确保您在 SimpleDB 中使用的任何功能在 DynamoDB 中都可用。确保为两者设计数据库设计 DynamoDB 对使用索引有更严格的要求，确保两者兼容。

话虽如此。很多人一直在将 SimpleDB 用于他们的应用程序，我认为除非您的产品真正起飞，否则您不会看到任何性能问题，届时您可以投资资源以迁移到 DynamoDB。

除了我们有定价之外，就像你已经提到的那样。SimpleDB 是您用例的明显解决方案。

于 2012-03-17T19:48:46.343 回答