我试图弄清楚我可以在未来的项目中使用什么，我们计划在第一年每月存储大约 50 万条记录，未来几年可能会更多，这是一个垂直应用程序，因此无需使用数据库为此，这就是我决定选择 noSQL 数据存储的原因。
我想到的第一个选项是 mongo db，因为它是一个非常成熟的产品，得到了社区的大力支持，但另一方面，我们得到了一个全新的产品，它提供了最高性能的托管服务，我会开发这个应用程序，但没有维护计划（至少现在是这样），所以我认为这将是一个巨大的优势，因为亚马逊提供了一种弹性的扩展方式。
我主要关心的是查询结构，我还没有研究过 dynamoDB 的查询功能，但由于是 ak/v 数据存储，我觉得这可能比 mongo db 更受限制。
如果有人有将项目从 mongoDB 迁移到 DynamoDB 的经验，任何建议都将不胜感激。
我知道这很旧，但是当您搜索比较时它仍然会出现。我们使用的是 Mongo，几乎完全迁移到了 Dynamo，这是我们现在的首选。不是因为它有更多的功能，它没有。Mongo 有更好的查询语言，你可以在一个结构中索引，有很多小东西。Dynamo 的优势在于 OP 在他的评论中所说的：这很容易。您不必照顾任何服务器。当您开始设置 Mongo 分片解决方案时，它会变得复杂。您可以去其中一家托管公司，但这也不便宜。使用 Dynamo，如果您需要更高的吞吐量，只需单击一个按钮。您可以编写脚本以自动扩展。当需要升级 Dynamo 时，它已经为您完成了。那是很多宝贵的压力和没有花费的时间。如果你不
所以我们现在默认使用 Dynamo。Mongo 可能，如果数据结构足够复杂以保证它的存在，那么我们可能会回到 SQL 数据库。Dynamo 是迟钝的，你真的需要考虑如何构建它，并且很可能你会在 Elasticcache 中使用 Redis 来使它适用于复杂的东西。但不必照顾它肯定很好。你编码。而已。
我最近将我的 MongoDB 迁移到 DynamoDB，并写了 3 个博客来分享一些关于性能、成本的经验和数据。
从 MongoDB 迁移到 AWS DynamoDB + SimpleDB
使用 500k 文档，没有理由进行任何扩展。具有 SSD 和 8GB 内存的典型笔记本电脑可以轻松完成数千万条记录，因此，如果您因为扩展而尝试选择，那么您的选择并不重要。我建议你选择你最喜欢的，也许你可以在哪里找到最多的在线支持。
对于快速概览比较，我真的很喜欢这个网站，它有很多比较页面，例如 AWS DynamoDB vs MongoDB；http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB
简短回答：从 SQL 开始，仅在需要时/如果需要添加 NoSQL。（除非您不需要非常简单的查询之外的任何内容）
我的个人经验：我没有使用 MongoDB 进行查询，但截至 2015 年 4 月，DynamoDB 在涉及最基本的键/值查询之外的任何事情时仍然非常糟糕。我喜欢它的基本内容，但如果您想要查询语言，那么请寻找真正的 SQL 数据库解决方案。
在 DynamoDB 中，您可以查询散列或散列和范围键，并且可以有多个二级全局索引。我正在使用 4 个可能的过滤器参数对单个表进行查询并对结果进行排序，这通过使用带有过滤器表达式的全局二级索引得到（几乎）支持。当您尝试获取与过滤器匹配的总结果时，问题就出现了，您不能只搜索与过滤器匹配的前 10 个项目，而是检查 10 个项目，您可能会得到 0 个有效结果，迫使您继续重新-从继续键进行扫描 - 在一个简单的场景中，颈部疼痛并消耗过多的表读取配额。
要具体说明查询中过滤器的限制问题，这来自文档（http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit）：
在响应中，DynamoDB 会返回其中的所有匹配结果 限值的范围。例如，如果您发出查询 或限制值为 6 且没有过滤器的扫描请求 表达式，该操作返回前六项 与请求参数匹配的表。如果您还提供 FilterExpression，该操作返回 表中与过滤器要求匹配的前六个项目。
我的结论是，涉及 FilterExpressions 的查询仅在极少数情况下可用并且不可扩展，因为每个查询都可以轻松读取您的大部分或全部表，而这会消耗太多 DynamoDB 读取单元。一旦使用过多的读取单元，您将受到限制并看到性能不佳。
专家意见：在 2015 年 4 月 9 日的 AWS 峰会上，AWS 解决方案架构经理 Brett Hollman 在他关于向您的前 1000 万用户扩展的演讲中提倡从 SQL 数据库开始，然后仅在有意义的情况下才使用 NoSQL。因为迟早您可能会在堆栈中的某个位置需要一个 SQL 服务器。他的幻灯片在这里：http ://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users 见幻灯片 28。
我们为医疗保健产品选择了 Mongo/Dynamo 的组合。基本上 mongo 允许更好的搜索，但托管的 Dynamo 非常棒，因为它符合 HIPAA 标准，无需任何额外工作。因此，我们在标准设置上托管没有个人数据的 mongo 部分，并允许亚马逊在基础设施方面处理 HIPAA 部分。我们可以从 mongo 查询某些项目，这些项目会显示带有相关 Dynamo 文档的指针（ID）的文档。
我们选择使用 mongo 而不是在 dynamo 上托管整个应用程序的主要原因有两个。首先，我们需要执行 mongo 擅长的基于位置的搜索，当时 Dynamo 不擅长，但他们现在确实有一个选择。
其次是一些文档是非结构化的，我们事先不知道数据是什么，所以例如让用户 a 在“表单”集合中输入一个文档，如下所示：{“username”：“user1”，“电子邮件”：“me@me.com”}。另一个用户把它放在同一个集合中 {"phone": "813-555-3333", "location": [28.1234,-83.2342]}。使用 mongo，我们可以随时搜索这些动态和未知字段中的任何一个，使用 Dynamo，您可以这样做，但每次添加您希望可搜索的新字段时都必须创建索引。因此，如果您之前从未在 Dynamo 文档中包含电话字段，然后突然之间，有人添加了它，它完全无法搜索。
现在这提出了你提到的另一点。有时为工作选择正确的解决方案并不总是意味着为工作选择最好的产品。例如，您可能有一个客户需要并将使用您创建的系统 10 年以上。使用足以完成工作的 SaaS/IaaS 解决方案可能是更好的选择，因为您可以依靠亚马逊来长期维护和维护他们的系统。
我曾在这两者上工作过，并且是两者的粉丝。
但是您需要了解何时使用什么以及用于什么目的。
我不认为将所有数据库移动到 DynamoDB 是一个好主意，因为除了主键和辅助键之外查询很困难，索引是有限的，在 DynamoDB 中扫描很痛苦。
我会选择一种混合类型的数据库，其中应该有大量可查询的数据，而 MongoDB 具有它的所有功能，您永远不会感到受限于提供增强或修改。
DynamoDB 速度快如闪电（比 MongoDB 快），因此 DynamoDB 通常用作可扩展应用程序中会话的替代方案。DynamoDB 最佳实践还建议，如果有大量使用较少的数据，请将其移至其他表。
因此，假设您有文章或提要。人们更有可能寻找上周的东西或本月的东西。人们访问两年前的数据的机会真的很少。出于这些目的，DynamoDB 倾向于将数据按月或按年存储在不同的表中。
DynamoDB 具有完美的可扩展性，您必须在 MongoDB 中手动完成。但是，如果您不了解吞吐量分区以及扩展如何在幕后工作，您将失去 DynamoDB 的性能。
DynamoDB 应该用于速度至关重要的地方，另一方面，MongoDB 有太多的手和功能，这是 DynamoDB 所缺乏的。
例如，您可以拥有一个 MongoDB 副本集，其中一个副本保存 8 小时（或其他任何时间）的数据实例。真的很有用，如果你在你的数据库中搞砸了一些重要的事情，并且想要像以前一样获取数据。
这是我的意见。
请记住，我只尝试过 MongoDB ......
根据我的阅读，DynamoDB 在功能方面取得了长足的进步。它曾经是一个超级基础的键值存储，存储和查询能力极其有限。它已经发展壮大，现在支持更大的文档大小 + JSON 支持和全球二级索引。DynamoDB 和 MongoDB 在功能方面的差距每个月都在缩小。DynamoDB 的新功能在此处展开。
由于最近添加了 DynamoDB 功能，大部分 MongoDB 与 DynamoDB 比较已经过时。但是，这篇文章提供了一些其他令人信服的观点来选择 DynamoDB，即它简单、维护成本低且通常成本低。这里关于数据库选择的另一个讨论读起来很有趣，虽然有点旧。
我的收获：如果您正在执行严肃的数据库查询或使用 DynamoDB 不支持的语言工作，请使用 MongoDB。否则，请坚持使用 DynamoDB。