我们正在构建一个带有rails CMS的移动应用程序来管理它。
我们的应用程序是什么样子的
该应用程序的每个管理员用户都可以用非常少量的数据设置一个私人频道-大约50根短绳。
然后，用户可以下载该应用程序，注册几个不同的频道，并将数据从服务器提取到他们的设备上。数据将存储在本地，除非管理员用户更新数据，否则不会再次提取（但我们认为这种情况不会经常发生）。每个频道最多可供500台设备使用。
用户可以为频道做出贡献，但这些数据将存储在S3上，而不是数据库上。
2个要点：
- 大多数频道的活跃期为5个月，而不是500名用户但大多数活动都会在同一天进行
- 每个频道都是为少量用户（500），但我们希望：）获得数十万管理员用户
使用rails构建CMS，我们发现使用SimpleDB比使用DynamoDB更为困难。但是，由于我们不是服务器专家，我们看到了SimpleDB的局限性，我们不知道SimpleDB是否能够处理我们将要处理的数据传输量（如果我们的应用程序能够成功）。另一个重要的点是DynamoDb的成本要高得多，并且不依赖于使用，而SimpleDb一开始会便宜得多。
问题是：
- simpleDB能满足我们的需求吗
- 如果我们的服务在未来增长，我们可以稍后迁移到dynamoDB吗
从一个新项目开始，并不知道使用会带来什么，我认为更好的选择是使用SimpleDB。听起来你的使用率不会很高。SimpleDB应该能够处理这个问题。当你真的有很多负载时，发电机数据库的真正力量就来了。你似乎不属于那一类。
如果您正确地设计了应用程序，那么如果您在某个时刻决定SimlpeDB不起作用，那么在SimpleDB和DynamoDB之间切换应该是一项简单的任务。我一直在用软件中的其他组件进行这种切换。由于这两个数据库都是NoSQL，所以在两者之间转换应该不会有问题。只要确保您在SimpleDB中使用的任何功能都可以在DynamoDB中使用。确保为这两个数据库设计数据库。DynamoDB使用索引有更严格的要求。确保两者兼容。
话虽如此。很多人一直在为他们的应用程序使用SimpleDB，我不认为你会看到任何性能问题，除非你的产品真正起飞，届时你可以投资资源转移到DynamoDB。
除此之外，我们还有价格，就像你已经提到的。SimpleDB是您的用例的明显解决方案。