我想弄清楚我可以在未来的项目中使用什么，我们计划在第一年每个月存储大约500k条记录，也许更多是为了今后几年，这是一个垂直应用程序所以不需要为此使用数据库，这就是我决定选择noSQL数据存储的原因。DynamoDB与MongoDB NoSQL
我想到的第一个选择是mongo db，因为它是一个非常成熟的产品，得到了社区的大力支持，但另一方面，我们获得了一款全新的产品，可以提供顶级性能的托管服务，将开发这个应用程序，但没有维护计划（至少现在），所以我认为这将是一个巨大的优势，因为亚马逊提供了一种有弹性的扩展方法。
我主要关心的是查询结构，我还没有看过dynamoDB查询功能，但由于是k/v数据存储，我觉得这可能比mongo db更有限。
如果有人有将项目从mongoDB移动到DynamoDB的经验，任何建议都将完全赞赏。
对于500k的文档，没有任何比例尺的理由。一台典型的带有SSD和8GB RAM的笔记本电脑可以轻松完成数以百万计的记录，所以如果您因为扩展选择而试图挑选并不重要。我建议你选择你最喜欢的，也许你可以在哪里找到最多的在线支持。
是的，我的市长担心的是扩大规模和维护时间，坦白地说，我认为mongoDB可以完成我正在考虑的中长期维护方面的工作 –
Derick是另一个主要的规模因素利用率，而不仅仅是文档数量或数据库大小。 @jack不会“感觉”，而是依赖于测试，包括最终部署的平台和硬件;一周花费数据和基准测试数据库变体应该导致知情的决定节省很多痛苦。 – zanlok
提供专业的产品/服务远远超出了“这可以做到”的简单解决方案。仅仅因为廉价机器可以运行Linux，MongoDB和几百万条几乎没有钱的记录并不等于现实世界中的卓越性能。500K记录（SIMPLE模式）可能是DynamoDB的一个很好的候选者，因为OP将没有维护成本（至少对于硬件），并且每月的费用可能远远低于服务器在整个过程中的成本一年或两年。 – cbmeeks
为了快速概览比较，我非常喜欢这个网站，它有许多比较页面，例如AWS DynamoDB vs MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB
感谢您的链接！我从来没有去过db-engines.com。伟大的网站！ –
我知道这是旧的，但它仍然出现时，你搜索的比较。我们使用的是Mongo，几乎完全转移到Dynamo，这是我们现在的首选。不是因为它有更多的功能，它不是。 Mongo有一个更好的查询语言，你可以在一个结构中索引，有很多小东西。迪纳摩的优势在于OP在他的评论中所说的：这很容易。您不必照顾任何服务器。当你开始设置Mongo分片解决方案时，它会变得复杂。您可以去其中一家托管公司，但这也不便宜。使用Dynamo，您需要更多的吞吐量，您只需点击一个按钮即可。您可以编写脚本来自动缩放。当需要升级Dynamo时，它已经为您完成了。这些都是宝贵的压力和时间。如果你没有专门的操作人员，Dynamo非常棒。
所以我们现在默认使用Dynamo。 Mongo也许，如果数据结构足够复杂以保证它，但那么我们可能会回到SQL数据库。 Dynamo很呆板，您真的需要考虑如何构建它，并且可能会在Elasticcache中使用Redis以使其适用于复杂的内容。但它确实很好，无需照顾它。你编码。而已。
如果必须将数据库与数据库进行比较，则必须仅比较数据库功能。托管的解决方案不是数据库功能。如果您正在寻找一个托管的MongoDB，那么去MongoHQ，他们会做所有您想要避免的烦琐工作，同时关注您的核心工作。 – Kabeer
确实如此，尽管我们所做的初始成本比较显示发电机是一笔相当不错的交易。另一个问题是，如果你必须升级/缩小发电机，这是一个按钮的点击。如果您必须添加磁盘或调整mongo服务器的大小，则无论是否需要执行此操作，或其他人都需要停机。 – CargoMeister
请记住，我只用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。
简短回答：从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峰会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而不是在发电机上托管整个应用程序的主要原因有两个原因。首先，我们需要对mongo擅长的基于位置的搜索进行预处理，当时Dynamo没有，但他们现在有选择。其次是一些文档是非结构化的，而且我们并不知道数据会是什么，所以举个例子，假设用户在“表单”集合中输入一个文档，如下所示：{“username”：“ user1“，”email“：”[email protected]“}。另一位用户将其放在同一个集合{“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小时（或其他）的数据实例。真的很有用，如果你在你的数据库中弄了一些大的时间，想要像以前那样获取数据。
这是我的看法。
Redis和MongoDB的组合？我觉得这很棒。 – Ismaestro
我想是的，我没有Redis的实际操作经验，但是由于它的性能，它肯定被广泛使用，在内存数据库中几乎总是比基于磁盘的数据库性能更好。所以我认为需要大量需求和高频率访问的数据应该发送给Redis。另一方面，应该使用MongoDB的大量昏睡数据。 –
如果您需要关于查询结构的建议，我会建议您提供一个模式示例以及访问数据的用例。如果没有这些，很难对适合度作出判断。 –
确实，如何查询数据可能会显着影响后端数据库选择。等级将如何成为我的第一个问题。 – zanlok
我很惊讶这个问题还没有通过排名SO人关闭。通常寻求建议的问题会因为他们没有向一个非常具体的问题寻求帮助而关闭。 –