我知道这是一个很大的问题,这不是一个肯定或没有答案,但我们开发网络应用程序,并正在考虑使用MongoDB作为我们的持久性解决方案。将MongoDB与NoRM结合用于对象存储。
我想问的是,从SQL切换到mongo时遇到了什么陷阱?什么时候mongo不是正确的解决方案,mongodb的优势是否足以从SQL迁移开发?
答案 0 :(得分:35)
在我看来,在选择存储后端时,数据格式应该是首要考虑因素。您是否拥有关系性质的数据?如果是这样,是否可以在文档中建模数据?数据建模在文档数据库中与在关系数据库中一样重要,它只是以不同方式完成。你有多少种类的物品以及它们有什么关系? Mongodb中的DBrefs可以做到这一点,还是你会错过外键,这会很痛苦吗?您对数据的访问模式有哪些?您只是获取由字段值过滤的一种类型的数据,还是您有复杂的提取模式?
您是否需要ACID交易完整性?域是否对数据施加了很多约束?您是否需要文档数据库的可伸缩性因素,或者只是一个“酷”的东西?
您的一致性和数据完整性要求是什么?一些NoSQL解决方案和特别是MongoDB在写入一致性方面非常松散,以获得性能。 NoSQL没有统一的格局和其他产品,例如CouchDB在该部门还有其他特点。有些也是可调的。
这些都是应该选择存储的问题。
一些经验
答案 1 :(得分:7)
缺点
专业人员
答案 2 :(得分:5)
我几天来一直在探索它。这就是我可以说的:
FOR:
反对:
我注意到教程中缺少的一件事: 初始化对象内的列表,否则在尝试.save(yourobj)时会抛出错误。最安全的做法是在类中编写一个构造函数,确保对象中没有任何NULL对象。这样,如果忘记了什么,就不会出错。
答案 3 :(得分:5)
你的里程可能会有所不同,但这是一个快速图表,我把它放在一起比较更新多个“表行”(MongoDB中的非分层平面文档)的速度,有没有索引,让我们知道它是如何的会缩放我们的应用程序。
答案 4 :(得分:2)
您可能会在此Getting started with NoSQL中找到使用NoSQL数据库(包括MongoDB)的一些优缺点。一个快速的总结将是:一个不同的数据模型(想想是否需要从对象模型到“这个新模型”的映射,它能否正常工作),一个不同的查询模型(MongoDB查询非常有能力,但与其他模型相比) ,没有交易(你有一些原子操作)。
无论如何,从我的角度来看,最重要的变化是数据模型以及使用这种新方法设计应用程序的方式。
答案 5 :(得分:0)
我一直在使用AWS的Atlas云上运行的MongoDB已有很多月了,这有两个主要好处: