DynamoDB与MongoDB NoSQL [关闭]

我正在尝试弄清楚我可以为将来的项目使用什么，我们计划在第一年每月存储大约50万条记录，在接下来的几年中可能会更多，这是一个垂直应用程序，因此不需要使用为此，这就是为什么我决定选择noSQL数据存储的原因。

我想到的第一个选择是mongo db，因为它是一个非常成熟的产品，得到了社区的大力支持，但另一方面，我们得到了一个全新的产品，该产品以最高的性能提供托管服务，我将开发此产品应用程序，但没有维护计划（至少目前是这样），所以我认为这将是一个巨大的优势，因为亚马逊提供了一种灵活的扩展方式。

我主要关心的是查询结构，我还没有研究过dynamoDB查询功能，但是由于是ak / v数据存储，所以我觉得这可能比mongo db有更多限制。

如果有人有将项目从mongoDB迁移到DynamoDB的经验，则任何建议将不胜感激。

我最近将MongoDB迁移到DynamoDB，并写了3个博客来分享一些有关性能和成本的经验和数据。

从MongoDB迁移到AWS DynamoDB + SimpleDB

在DynamoDB上使用MongoDB的7个理由

在MongoDB上使用DynamoDB的3个理由

我知道这很旧，但是当您搜索比较时它仍然会出现。我们使用的是Mongo，现在几乎完全迁移到了Dynamo，这是我们现在的首选。不是因为它具有更多功能，而是没有。Mongo具有更好的查询语言，您可以在结构内建立索引，其中有很多小事情。Dynamo的优势在于OP在他的评论中指出的：这很容易。您不必照顾任何服务器。当您开始设置Mongo分片解决方案时，它变得很复杂。您可以去托管公司之一，但这也不便宜。使用Dynamo，如果需要更高的吞吐量，只需单击一个按钮。您可以编写脚本以自动缩放。当需要升级Dynamo时，它已为您完成。这就是很多宝贵的压力和时间。如果你不

因此，我们现在默认情况下使用Dynamo。也许Mongo，如果数据结构足够复杂，足以保证它的安全，那么我们可能会回到SQL数据库。Dynamo太钝了，您确实需要考虑如何构建它，并且可能会在Elasticcache中使用Redis使其适用于复杂的东西。但是不必去照顾它肯定很好。您编码。而已。

对于50万个文档，没有任何理由可以扩展。带有SSD和8GB内存的典型笔记本电脑可以轻松地完成数千万条记录，因此，如果您由于扩展而试图选择，那么选择实际上并不重要。我建议您选择最喜欢的软件，也许在哪里可以找到最在线的支持。

对于快速的概览比较，我非常喜欢这个网站，该网站有很多比较页面，例如AWS DynamoDB与MongoDB；http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

简短的答案：从SQL开始，仅在/需要时添加NoSQL。（除非您不需要非常简单的查询即可）

我的个人经验：我尚未使用MongoDB进行查询，但截至2015年4月，在涉及最基本的键/值查询之外的任何事情时，DynamoDB仍然非常残缺。我喜欢它的基本知识，但是如果您要查询语言，那么可以考虑使用真正的SQL数据库解决方案。

在DynamoDB中，您可以查询散列或散列和范围键，并且可以有多个二级全局索引。我正在使用4个可能的过滤器参数对单个表进行查询，并对结果进行排序，这是（很少）通过使用带有过滤器表达式的全局二级索引来支持的。当您尝试获得与过滤器匹配的总结果时，就会出现问题，您不仅可以搜索与过滤器匹配的前10个项目，还可以检查10个项目，并且您可能会得到0个有效结果，从而迫使您继续从继续键进行扫描-颈部疼痛，在一个简单的情况下会消耗过多的表读取配额。

要具体说明查询中过滤器的限制问题，请参见docs（http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit）：

在响应中，DynamoDB返回内部的所有匹配结果
极限值的范围。例如，如果您发出查询
或限制值为6且没有过滤器的扫描请求
表达式，该操作将返回 
符合要求参数的表格。如果您还提供
FilterExpression，该操作返回内部的项目 
表格中的前六个项目符合过滤器要求。

我的结论是，涉及FilterExpression的查询仅在极少数情况下可用，并且不可伸缩，因为每个查询都可以轻松读取您的表的大部分或全部，这消耗了太多的DynamoDB读取单元。一旦使用过多的读取单位，您将受到限制，并看到性能不佳。

专家意见：在2015年4月9日举行的AWS峰会上，AWS解决方案架构经理Brett Hollman在关于向您的前1000万用户扩展规模的演讲中，主张从SQL数据库开始，然后仅在有意义时使用NoSQL。因为迟早您可能需要在堆栈中的某个位置使用SQL Server。他的幻灯片在这里：http : //www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users 参见幻灯片28。

我们选择了Mongo / Dynamo的组合作为保健产品。基本上mongo可以更好地进行搜索，但是托管的Dynamo很棒，因为它符合HIPAA，无需任何额外的工作。因此，我们在标准设置中托管没有个人数据的mongo部分，并允许Amazon在基础架构方面处理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。