我正在尝试找出未来项目可以使用什么，我们计划在第一年存储约 500k 条记录，可能在接下来的几年中还会有更多，这是一个垂直应用程序，因此无需为此使用数据库，这就是我决定选择 NoSQL 数据存储的原因。
我脑海中首先想到的选择是 MongoDB，因为它是一个非常成熟的产品，得到了社区的大力支持，但另一方面，我们也有一个全新的产品，提供了顶级性能的托管服务，我将开发这个应用程序，但暂时没有维护计划，所以我认为这将是一个巨大的优势，因为亚马逊提供了弹性扩展的方式。
我最担心的是查询结构，我还没有看过 DynamoDB 的查询功能，但由于它是一个 k/v 数据存储，我觉得它可能比 MongoDB 更加有限。
如果有人有从 MongoDB 迁移到 DynamoDB 的经验，请提供建议，将不胜感激。
我知道这个问题很老了，但当你搜索比较时它仍然会出现。我们曾经使用Mongo，现在几乎完全转向Dynamo，它是我们的首选。不是因为它有更多功能，事实上它没有。Mongo有更好的查询语言，你可以在结构内进行索引，还有许多细节。 Dynamo的优越性在于OP在他的评论中所述：它很容易上手。你不必去管任何服务器。当你开始设置Mongo分片解决方案时，情况变得复杂。你可以去其中一个托管公司，但那也不便宜。对于Dynamo，如果你需要更高的吞吐量，你只需要点击一个按钮。你可以编写脚本自动扩展。当需要升级Dynamo时，它会为你完成。这样可以省下很多宝贵的精力和时间。如果没有专门的运维人员，Dynamo是非常好的选择。
所以我们现在默认使用Dynamo。如果数据结构足够复杂，可能会用到Mongo，但那样的话我们可能会回到SQL数据库。 Dynamo很难理解，你真的需要考虑如何去构建它，而且很可能你会使用Elasticcache中的Redis来处理复杂的内容。但是不必担心维护它，你只需要关注编码就可以了。
有 50 万份文件，没有理由进行任何扩展。一台配备 SSD 和 8GB 内存的典型笔记本电脑可以轻松处理数千万条记录，因此如果选择是为了扩展，您的选择并不重要。我建议您选择您最喜欢的，并可能在哪里可以找到最多的在线支持。
对于快速的概览比较，我非常喜欢这个网站，它有许多比较页面，例如AWS DynamoDB和MongoDB的比较：http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB
在响应中，DynamoDB返回在Limit值范围内的所有匹配结果。例如，如果您发出带有Limit值为6且没有过滤表达式的查询或扫描请求，则操作将返回与请求参数匹配的表中的前六个项目。如果还提供了FilterExpression，则操作将返回表中前六个项目中符合过滤要求的项目。我的结论是，涉及FilterExpressions的查询仅在非常罕见的情况下可用，并且不可扩展，因为每个查询都可以轻松读取大部分或全部表格，这会消耗过多的DynamoDB读取单位。一旦使用了太多的读取单位，您将被限制并看到性能不佳。
我既用过MongoDB也用过DynamoDB。
但你需要了解什么时候使用哪个以及出于什么目的。
我认为全部转移到DynamoDB并不是一个好主意，因为DynamoDB查询除了主键和次键外很困难，索引有限且在DynamoDB中扫描非常痛苦。
我会选择一种混合类型的数据库，在其中包含应该使用MongoDB的广泛可查询数据，凭借其所有功能，您永远不会感到受到限制以提供增强或修改。
DynamoDB非常快速（比MongoDB更快），因此在可扩展的应用程序中，DynamoDB通常被用作会话的替代方案。 DynamoDB最佳实践还建议，如果有大量不常使用的数据，请将其移动到其他表中。
因此，假设您有文章或信息源。人们更有可能寻找上周或本月的内容。访问两年前的数据的机会非常罕见。为这些目的，DynamoDB更喜欢按月或年在不同表格中存储数据。
DynamoDB无需缝扩展，这是您必须在MongoDB中手动完成的操作。但是，如果不了解吞吐量分区和缩放背后的工作原理，您将损失DynamoDB的性能。
DynamoDB应该用于速度至关重要的地方，而MongoDB则具有太多的特点和功能，这是DynamoDB所缺乏的。
例如，您可以在MongoDB中拥有一个副本集，其中一个副本保存8（或其他）小时旧的数据实例。如果您在数据库中出了大问题并且想要获取之前的数据，则非常有用。
这就是我的意见。
