我试图找出可以用于未来项目的内容，我们计划在第一年每月存储大约50万条记录，而在接下来的几年中可能会更多，这是一个垂直应用程序所以＃39;不需要使用数据库，这就是我决定选择noSQL数据存储的原因。
我想到的第一个选择是mongo db，因为它是一个非常成熟的产品，得到了社区的大力支持，但另一方面我们得到了一个全新的产品，提供最佳性能的托管服务，我＆＃ 39;开发这个应用程序，但没有维护计划（至少现在），所以我认为这将是一个巨大的优势，因为亚马逊提供了一种弹性的扩展方式。
我主要担心的是查询结构，我还没有看过dynamoDB查询功能，但由于是k / v数据存储，我觉得这可能比mongo db更受限制。
如果有人有将项目从mongoDB迁移到DynamoDB的经验，那么任何建议都将完全受到赞赏。
答案 0 :(得分：159)
我知道这是旧的，但是当你搜索比较时它仍然会出现。我们使用Mongo，几乎完全移动到Dynamo，这是我们现在的第一选择。不是因为它有更多的功能，它不是。 Mongo有一个更好的查询语言，你可以在一个结构中索引，有很多小东西。 Dynamo的优势在于他在评论中所说的OP：它很容易。您不必处理任何服务器。当您开始设置Mongo分片解决方案时，它会变得复杂。你可以去一家托管公司，但这也不便宜。使用Dynamo，如果您需要更多吞吐量，只需单击一个按钮即可。您可以编写脚本以自动扩展。什么时候升级Dynamo，它就是为你完成的。这就是很多宝贵的压力和时间都没花。如果您没有专门的操作人员，Dynamo非常出色。
所以我们现在默认使用Dynamo。 Mongo也许，如果数据结构足够复杂以保证它，那么我们可能会回到SQL数据库。 Dynamo是愚蠢的，你真的需要考虑如何构建它，并且你可能会在Elasticcache中使用Redis来使它适用于复杂的东西。但是不必照顾它确实很好。你编码。而已。
答案 1 :(得分：55)
有500k文件，没有理由进行任何扩展。具有SSD和8GB内存的典型笔记本电脑可轻松完成数千万条记录，因此如果您因为扩展而尝试选择，那么您的选择并不重要。我建议你选择你最喜欢的，也许你可以在哪里找到最多的在线支持。
答案 2 :(得分：54)
我最近将我的MongoDB迁移到了DynamoDB，写了3篇博客来分享一些关于性能和成本的经验和数据。
Migrate from MongoDB to AWS DynamoDB + SimpleDB
答案 3 :(得分：21)
为了快速概览比较，我真的很喜欢这个有很多比较页面的网站，例如AWS DynamoDB和MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB
答案 4 :(得分：16)
简短回答：从SQL开始，仅在需要时添加NoSQL。 （除非你不需要除了非常简单的查询之外的任何事情）
我的个人经验：我还没有使用MongoDB进行查询，但截至2015年4月，DynamoDB在最基本的键/值查询之外仍然非常严重。我喜欢它的基本内容，但如果你想要查询语言，那么请查看真正的SQL数据库解决方案。
在DynamoDB中，您可以查询散列或散列和范围键，并且可以拥有多个辅助全局索引。我在具有4个可能的过滤器参数的单个表上进行查询并对结果进行排序，这通过使用带有过滤器表达式的全局二级索引得到支持（几乎没有）。当您尝试获得与过滤器匹配的总结果时出现问题，您不能仅搜索与过滤器匹配的前10个项目，而是检查10个项目，您可能会得到0个有效结果，这会导致您保持从继续键重新扫描 - 颈部疼痛，并消耗过多的表读取配额的简单方案。
要具体了解查询中过滤器的限制问题，请参阅文档（http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit）：
In a response, DynamoDB returns all the matching results within the scope of the Limit value. For example, if you issue a Query or a Scan request with a Limit value of 6 and without a filter expression, the operation returns the first six items in the table that match the request parameters. If you also supply a FilterExpression, the operation returns the items within the first six items in the table that match the filter requirements.
我的结论是涉及FilterExpressions的查询仅在非常罕见的情况下可用，并且不可扩展，因为每个查询都可以轻松读取您的大部分或全部表，这会消耗太多的DynamoDB读取单元。一旦你使用了太多的读取单元，你就会受到限制，并且会看到性能不佳。
专家意见：在2015年4月9日的AWS峰会上，AWS解决方案架构经理Brett Hollman在谈到你的第一个1000万用户时，主张从一个SQL数据库开始，然后只在使用NoSQL时使用NoSQL说得通。因为迟早你可能需要堆栈中的某个SQL服务器。他的幻灯片在这里：http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users 见幻灯片28.
答案 5 :(得分：14)
我们为医疗保健产品选择了Mongo / Dynamo的组合。基本上mongo允许更好的搜索，但托管的Dynamo很棒，因为它的HIPAA兼容，没有任何额外的工作。因此，我们在标准设置中托管没有个人数据的mongo部分，并允许亚马逊在基础设施方面处理HIPAA部分。我们可以从mongo查询某些项目，这些项目会显示可关联的Dynamo文档的指针（ID＆＃39; s）。
我们选择使用mongo而不是在发电机上托管整个应用程序的主要原因有两个原因。首先，我们需要预先形成基于位置的搜索，其中mongo非常棒，当时Dynamo不是，但他们现在确实有选择。
其次是一些文档是非结构化的，我们提前不知道数据是什么，所以例如让用户输入一个文档＆＃34; form＆＃34;像这样的集合：{＆＃34;用户名＆＃34;：＆＃34;用户1＆＃34;，＆＃34;电子邮件＆＃34;：＆＃34; me@me.com"}。另一个用户将其放在同一个集合中{＆＃34; phone＆＃34;：＆＃34; 813-555-3333＆＃34;，＆＃34; location＆＃34;：[28.1234，-83.2342]}。使用mongo，我们可以随时搜索这些动态和未知字段中的任何一个，使用Dynamo，您可以执行此操作，但每次添加您想要搜索的新字段时都必须创建索引。因此，如果您之前从未在Dynamo文档中有过电话字段，那么突然间，有人会添加它，它完全无法搜索。
现在这提出了你提到的另一点。有时为工作选择正确的解决方案并不总是意味着为工作选择最好的产品。例如，您可能有一个客户需要并将使用您创建的系统超过10年。使用足以完成工作的SaaS / IaaS解决方案可能是一个更好的选择，因为您可以依靠亚马逊来长期保持和维护他们的系统。
答案 6 :(得分：8)
我和两个人都有过合作，并且都很喜欢。
但是你需要了解何时使用什么以及用于什么目的。
我不认为将所有数据库移动到DynamoDB是一个好主意，因为除了主键和辅助键之外，查询很困难，索引有限并且在DynamoDB中扫描很痛苦。
我会选择混合类型的数据库，其中有广泛的可查询数据应该是MongoDB，具有所有功能，您永远不会觉得受限于提供增强或修改。
DynamoDB非常快（比MongoDB更快），因此DynamoDB通常用作可扩展应用程序中会话的替代方案。 DynamoDB最佳实践还表明，如果有大量数据使用较少，请将其移至其他表。
假设您有文章或供稿。人们更有可能寻找上周的东西或本月的东西。人们很少有机会访问两年前的数据。出于这些目的，DynamoDB更喜欢将数据按月或按年存储在不同的表中。
DynamoDB具有无缝可扩展性，您必须在MongoDB中手动完成。但是，如果您不了解吞吐量分区以及场景后缩放的工作方式，那么您将失去DynamoDB的性能。
应该在速度至关重要的地方使用DynamoDB，另一方面，MongoDB拥有太多的牌和功能，这是DynamoDB所缺乏的。
例如，您可以拥有MongoDB的副本集，其中一个副本保存8小时（或其他）小时的数据实例。非常有用，如果你在数据库中弄乱了很多时间，并希望获得之前的数据。这是我的看法。
答案 7 :(得分：7)
请记住，我只尝试过使用MongoDB ......
从我所读过的内容来看，DynamoDB在功能方面已经取得了很大进展。它曾经是一个超级基本的键值存储，具有极其有限的存储和查询功能。它已经增长，现在支持bigger document sizes + JSON support和global secondary indices。 DynamoDB和MongoDB在功能方面提供的差距每个月都在缩小。 DynamoDB的新功能在here上进行了扩展。
由于最近添加了DynamoDB功能，许多MongoDB与DynamoDB的比较都已过时。但是，this post提供了一些其他令人信服的选择DynamoDB，即它简单，低维护，通常成本低。数据库选择的Another discussion here很有意思，虽然有点旧。
我的看法：如果您正在进行严格的数据库查询或使用DynamoDB不支持的语言，请使用MongoDB。否则，坚持使用DynamoDB。