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