首页 文章

DynamoDB与MongoDB NoSQL [关闭]

提问于
浏览
150

我正在试图找出我可以用于未来项目的东西,我们计划在第一年每月存储大约50万条记录,而在接下来的几年中可能更多,这是一个垂直应用程序,所以不需要使用这个数据库,这就是我决定选择noSQL数据存储的原因 .

我想到的第一个选择是mongo db,因为它是一个非常成熟的产品,得到了社区的大量支持,但另一方面我们得到了一个全新的产品,提供最佳性能的托管服务,我将开发这个应用程序,但没有维护计划(至少现在),所以我认为这将是一个巨大的优势,因为亚马逊提供了一种弹性的扩展方式 .

我主要担心的是查询结构,我还没有看过dynamoDB查询功能,但由于是k / v数据存储,我觉得这可能比mongo db更受限制 .

如果有人有将项目从mongoDB迁移到DynamoDB的经验,那么任何建议都将完全受到赞赏 .

8 回答

  • 13

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

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

  • 155

    请记住,我只尝试过使用MongoDB ...

    从我所读到的,DynamoDB在功能方面已经走了很长的路 . 它曾经是一个超级基本的键值存储,具有极其有限的存储和查询功能 . 它已经成长,现在支持bigger document sizes + JSON supportglobal secondary indices . DynamoDB和MongoDB在功能方面提供的差距随着每个月变小 . DynamoDB的新功能在here上进行了扩展 .

    由于最近添加了DynamoDB功能,MongoDB与DynamoDB比较的大部分都已过时 . 但是,this post提供了一些其他令人信服的选择DynamoDB,即它简单,低维护,而且成本通常很低 . Another discussion here数据库选择很有意思,虽然略显陈旧 .

    我的看法:如果您正在进行严格的数据库查询或使用DynamoDB不支持的语言,请使用MongoDB . 否则,坚持使用DynamoDB .

  • 55

    我既努力又兼顾两者的粉丝 .

    但是你需要了解何时使用什么以及用于什么目的 .

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

    我会选择混合类型的数据库,其中有广泛的可查询数据应该是MongoDB,具有它的所有功能,你永远不会觉得有限提供增强或修改 .

    DynamoDB非常快(比MongoDB更快),因此DynamoDB通常用作可扩展应用程序中会话的替代方案 . DynamoDB最佳实践还表明,如果有大量数据使用较少,请将其移至其他表 .

    所以假设你有文章或提要 . 人们更有可能寻找上周的东西或本月的东西 . 人们很少有机会访问两年前的数据 . 出于这些目的,DynamoDB更喜欢将数据按月或按年存储在不同的表中 .

    DynamoDB具有无缝可扩展性,您必须在MongoDB中手动完成 . 但是,如果您不了解吞吐量分区以及如何在场景后进行缩放,那么您将失去DynamoDB的性能 .

    应该在速度至关重要的地方使用DynamoDB,另一方面,MongoDB拥有太多的手和功能,这是DynamoDB所缺乏的 .

    例如,您可以拥有MongoDB的副本集,其中一个副本保存8小时(或其他)小时的数据实例 . 非常有用,如果你在数据库中弄乱了很多时间,并希望获得之前的数据 .

    这是我的看法 .

  • 49

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

  • 16

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

    我们选择使用mongo而不是在发电机上托管整个应用程序的主要原因有两个原因 . 首先,我们需要预先形成基于位置的搜索,其中mongo非常棒,当时,Dynamo不是,但他们现在确实有一个选项 .

    其次是一些文档是非结构化的,我们提前不知道数据是什么,所以例如让用户在“表单”集合中输入一个文档,如下所示:{“username”:“user1”,“电子邮件“:”me@me.com“} . 另一个用户将其放在同一个集合{“phone”:“813-555-3333”,“location”:[28.1234,-83.2342]} . 使用mongo,我们可以随时搜索任何这些动态和未知字段,使用Dynamo,您可以执行此操作,但每次添加您想要搜索的新字段时都必须创建索引 . 因此,如果您之前从未在Dynamo文档中有过电话字段,那么突然间,有人会添加它,它完全无法搜索 .

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

  • 7

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

  • 21

    我最近将我的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

  • 8

    简短回答:从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 .

相关问题