DynamoDB 与 MongoDB NoSQL [关闭]答案

【问题标题】：DynamoDB vs MongoDB NoSQL [closed]DynamoDB 与 MongoDB NoSQL [关闭]
【发布时间】：2013-07-29 15:48:00
【问题描述】：

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

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

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

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

【问题讨论】：

如果您需要有关查询结构的建议，我建议您提供架构示例以及访问数据的用例。没有这些，很难判断是否合适。
确实，您查询数据的方式可能会极大地影响后端数据库的选择。我的 #1 问题会有多层次。
我很惊讶这个问题还没有被 SO 人的排名解决。通常，寻求建议的问题会被关闭，因为他们不是针对非常具体的问题寻求帮助。

标签： mongodb amazon-web-services nosql amazon-dynamodb

【解决方案1】：

对于 500k 个文档，没有理由进行任何扩展。具有 SSD 和 8GB 内存的典型笔记本电脑可以轻松完成数千万条记录，因此，如果您因为扩展而尝试选择，那么您的选择并不重要。我建议你选择你最喜欢的，也许你可以在哪里找到最多的在线支持。

【讨论】：

是的，我的市长关心的是扩大规模和长期维护，老实说，我个人觉得 mongoDB 可以完成我正在考虑的中长期维护工作跨度>
Derick，规模的另一个主要因素是利用率，而不仅仅是文档数或数据库大小。 @jack 不是“感觉”而是依赖于测试，包括最终部署的平台和硬件；花一周时间用数据和基准测试填充几个数据库变体应该会导致明智的决策节省很多痛苦。
提供专业的产品/服务远远超出了简单的“这可以做到”的解决方案。仅仅因为一台便宜的机器几乎不花钱就能运行 Linux、MongoDB 和数百万条记录，这并不等于在现实世界中的出色性能。 50 万条记录（使用简单模式）可能是 DynamoDB 的一个很好的候选者，因为 OP 没有维护成本（至少对于硬件而言），而且每月的费用可能远低于服务器在整个过程中的成本一两年。

【解决方案2】：

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

Migrate from MongoDB to AWS DynamoDB + SimpleDB

7 Reasons You Should Use MongoDB over DynamoDB

3 Reasons You Should Use DynamoDB over MongoDB

【讨论】：

感谢您在此处发布您的文章，这些文章帮助我有一个更清晰的愿景，并且在我做出决定时肯定会帮助我
阅读了应该使用 dynamo 而不是 mongo 的三个原因，有一家公司提供托管服务，与 dynamoDB 相比，它更昂贵，但如果你没有，可以考虑nosql维护负责人，公司名称是mongoLab
@Pedro 非常感谢您的提醒。也许我以一种低效的方式使用 MongoDB。我有 140 万条记录，占用 8G 磁盘，但转移到 DynamoDB 后，只占用 300M 存储。如果我将这些数据迁移到 MongoLab，我可能需要测试并查看存储空间：)
链接坏了吗？
@MasonZhang 如果您将这些数据迁移到 MongoLab，看看存储是什么会非常有趣。

【解决方案3】：

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

【讨论】：

感谢您的链接！我以前从未去过 db-engines.com。很棒的网站！

【解决方案4】：

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

所以我们现在默认使用 Dynamo。 Mongo 可能，如果数据结构足够复杂以保证它的存在，那么我们可能会回到 SQL 数据库。 Dynamo 是迟钝的，你真的需要考虑如何构建它，并且很可能你会在 Elasticcache 中使用 Redis 来使它适用于复杂的东西。但不必照顾它肯定很好。你编码。而已。

【讨论】：

如果必须将数据库与数据库进行比较，则必须仅比较数据库功能。托管解决方案不是数据库功能。如果您正在寻找托管的 MongoDB，请选择 MongoHQ，他们会完成您在专注于核心工作时可能希望避免的所有繁重工作。
确实如此，尽管我们所做的初始成本比较表明 dynamo 是一笔不错的交易。另一个问题是，如果您必须放大/缩小发电机，只需单击一个按钮。如果您必须添加磁盘或调整 mongo 服务器的大小，则涉及停机时间，无论您必须这样做还是其他人。
@Kabeer 从技术上讲，我 100% 同意您的观点，但在现实世界中，整个软件包对于做出商业决策很重要。归根结底，这是一个商业决策。

【解决方案5】：

请记住，我只用过 MongoDB...

据我所知，DynamoDB 在功能方面取得了长足的进步。它曾经是一个超级基础的键值存储，存储和查询能力极其有限。它已经发展壮大，现在支持bigger document sizes + JSON support 和global secondary indices。 DynamoDB 和 MongoDB 在功能方面的差距每个月都在缩小。 DynamoDB的新功能在here上扩展。

由于最近添加了 DynamoDB 功能，MongoDB 与 DynamoDB 的大部分比较已经过时。但是，this post 提供了一些其他令人信服的理由来选择 DynamoDB，即它简单、维护成本低且通常成本低。 Another discussion here 的数据库选择读起来很有趣，虽然有点旧。

我的收获：如果您正在执行严肃的数据库查询或使用 DynamoDB 不支持的语言工作，请使用 MongoDB。否则，请坚持使用 DynamoDB。

【讨论】：

【解决方案6】：

简答：从 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。

【讨论】：

您应该真正了解将 cloudsearch 与 dynamodb 流和 lambda 集成以实现全文或基于位置的查询是多么容易。
根据您的需要选择您的数据库。这不是 SQL 和 noSQL 之间的选择，而是面向文档的 DB、面向图的 DB、键值 DB、RDMBS 之间的选择。没有黄金选择，SQL 肯定不是。

【解决方案7】：

我们为医疗保健产品选择了 Mongo/Dynamo 的组合。基本上 mongo 允许更好的搜索，但托管的 Dynamo 非常棒，因为它符合 HIPAA 标准，无需任何额外工作。因此，我们在标准设置上托管没有个人数据的 mongo 部分，并允许亚马逊在基础设施方面处理 HIPAA 部分。我们可以从 mongo 中查询某些项目，这些项目会显示带有相关 Dynamo 文档的指针（ID）的文档。

我们选择使用 mongo 而不是在 dynamo 上托管整个应用程序的主要原因有两个。首先，我们需要执行基于位置的搜索，这是 mongo 擅长的，当时 Dynamo 不擅长，但他们现在有一个选择。

其次是一些文档是非结构化的，我们事先不知道数据是什么，因此假设用户 a 在“form”集合中输入一个文档，如下所示：{“username”：“user1 ", "电子邮件": "me@me.com"}。另一个用户把它放在同一个集合中 {"phone": "813-555-3333", "location": [28.1234,-83.2342]}。使用 mongo，我们可以随时搜索这些动态和未知字段中的任何一个，使用 Dynamo，您可以这样做，但每次添加您希望可搜索的新字段时都必须创建索引。因此，如果您之前在 Dynamo 文档中从未有过电话字段，然后突然之间，有人添加了它，它完全无法搜索。

现在这又引出了你提到的另一点。有时为工作选择正确的解决方案并不总是意味着为工作选择最好的产品。例如，您可能有一个客户需要并将使用您创建的系统 10 年以上。使用足以完成工作的 SaaS/IaaS 解决方案可能是更好的选择，因为您可以依靠亚马逊来长期维护和维护他们的系统。

【讨论】：

【解决方案8】：

我都曾在这两个方面工作过，并且是两者的粉丝。

但您需要了解何时使用什么以及用于什么目的。

我不认为将所有数据库移动到 DynamoDB 是一个好主意，原因是除了主键和辅助键之外查询很困难，索引有限并且在 DynamoDB 中扫描很痛苦。

我会选择一种混合类型的数据库，其中应该有大量可查询的数据，而 MongoDB 拥有它的所有功能，您永远不会感到受限于提供增强或修改。

DynamoDB 速度快如闪电（比 MongoDB 快），因此 DynamoDB 通常用作可扩展应用程序中会话的替代方案。 DynamoDB 最佳实践还建议，如果有大量使用较少的数据，请将其移至其他表。

假设您有一篇文章或提要。人们更有可能寻找上周的东西或本月的东西。人们访问两年前的数据的机会确实很少。出于这些目的，DynamoDB 倾向于将数据按月或按年存储在不同的表中。

DynamoDB 具有完美的可扩展性，您必须在 MongoDB 中手动执行此操作。但是，如果您不了解吞吐量分区以及扩展如何在幕后工作，您将失去 DynamoDB 的性能。

DynamoDB 应该用于速度至关重要的地方，而 MongoDB 有太多的手和功能，而 DynamoDB 缺乏这些。

例如，您可以拥有一个 MongoDB 副本集，其中一个副本保存 8（或其他）小时的数据实例。真的很有用，如果您在数据库中搞砸了一些重要的事情并希望获得以前的数据。

这是我的看法。

【讨论】：

Redis 和 MongoDB 的组合？太棒了，我想。
我想是的，我没有使用 Redis 的实际经验，但可以肯定的是，由于它的性能，它被广泛使用，在内存数据库中几乎总是比基于磁盘的数据库性能更好。所以我认为需要大需求和高频率访问的数据应该去Redis。另一方面，对于大量昏昏欲睡的数据，应该使用 MongoDB。