DynamoDB VS MongoDB NoSQL

小开

有了50万的文档，就没有理由再扩展了。一台带有 SSD 和8GB 内存的典型笔记本电脑可以轻松地处理数以百万计的记录，所以如果你是因为可伸缩性而试图挑选记录，你的选择其实并不重要。我建议你选择你最喜欢的，也许在哪里你可以找到最多的在线支持。

小开

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

小开

我知道这很老了，但是当你搜索对比的时候还是会出现。我们使用的是 Mongo，现在几乎完全转移到 Dynamo，这是我们现在的首选。不是因为它有更多的功能，它没有。Mongo 有一个更好的查询语言，你可以在一个结构中建立索引，有很多小东西。Dynamo 的优势在于《观察家报告》在其评论中所说的: 这很容易。您不必照顾任何服务器。当您开始设置 Mongo 分片解决方案时，情况会变得复杂。你可以去其中一家托管公司，但那也不便宜。使用 Dynamo，如果需要更大的吞吐量，只需单击一个按钮。您可以编写自动伸缩的脚本。到了升级 Dynamo 的时候，你已经完成了。这是很多宝贵的压力和时间没有花费。如果你没有专门的行动人员，Dynamo 是很棒的。

所以我们现在默认使用 Dynamo。也许是 Mongo，如果数据结构足够复杂，那么我们可能会回到 SQL 数据库。Dynamo 很迟钝，你真的需要考虑如何构建它，而且很可能你会使用 Elasticcache 的 Redis 来为复杂的东西工作。不过不用照顾它也挺好的。你的代码。就是这样。

小开

记住，我只用 MongoDB 做过实验。

据我所知，DynamoDB 在特性方面已经取得了长足的进步。它曾经是一个超级基本的键值存储，其存储和查询能力非常有限。它已经成长，现在支持更大的文档大小 + JSON 支持和全球二级指数。DynamoDB 和 MongoDB 在特性方面的差距每个月都在缩小。DynamoDB 的新特性是在给你上扩展的。

由于最近添加了 DynamoDB 特性，很多 MongoDB 与 DynamoDB 的比较已经过时了。然而，这篇文章提供了一些其他令人信服的点来选择 DynamoDB，即它是简单的，低维护，而且往往低成本。数据库选项的这里有另一个讨论很有趣，尽管有点老。

我的要点是: 如果您正在进行严肃的数据库查询或使用 DynamoDB 不支持的语言，那么使用 MongoDB。否则，坚持使用 DynamoDB。

小开

简短的回答: 从 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 峰会上，解决方案架构经理 Brett Hollman 在他关于扩展到你的前1000万用户的演讲中提倡从 SQL 数据库开始，然后只在有意义的时候使用 NoSQL。因为您迟早可能需要在堆栈中的某个地方使用 SQL 服务器。他的幻灯片在这里: < a href = “ http://www.slideshare.net/AmazonWebServices/deep-dig-scale-up-to-your-first-10-million-users”> 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 而不是托管发电机上的整个应用程序的主要原因有两个。首先，我们需要预先形成基于位置的搜索，这在当时是很好的 mongo，Dynamo 不是，但他们现在有一个选项。

其次，一些文档是非结构化的，我们事先不知道数据是什么，所以例如，让我们假设用户输入一个“表单”集合中的文档，如下所示: {“ username”: “ user1”，“ email”: “ 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小时之前的数据实例。非常有用，如果你搞砸了数据库中的一些大时间，并希望得到的数据，因为它是以前。

这是我的看法。