赞成和反对从SQL服务器迁移到MongoDB的原因

我知道这是一个很大的问题,它不是一个肯定或没有答案,但我们开发Web应用程序,并正在考虑使用MongoDB作为我们的持久性解决方案.将MongoDB与NoRM组合用于对象存储.

我想问的是你从SQL切换到mongo时遇到了什么陷阱？什么时候mongo根本不是正确的解决方案,并且mongodb的优势足以从SQL迁移开发？

1> Knut Haugen..：

---

在我看来,在选择存储后端时,数据格式应该是首要考虑因素.您是否拥有关系性质的数据？如果是这样,是否可以在文档中建模数据？数据建模在文档数据库中与在关系数据库中一样重要,它只是以不同方式完成.你有多少种类的物品以及它们有什么关系？Mongodb中的DBrefs可以做到这一点,还是你会错过外键,这会很痛苦吗？您对数据的访问模式有哪些？您只是获取由字段值过滤的一种类型的数据,还是您有复杂的提取模式？

您需要ACID交易完整性吗？域是否对数据施加了很多约束？您是否需要文档数据库的可伸缩性因素,或者只是一个"酷"的东西？

您的一致性和数据完整性要求是什么？一些NoSQL解决方案和特别是MongoDB在写入一致性方面非常松散,以获得性能.NoSQL没有统一的格局和其他产品,例如CouchDB在这个部门有其他特征.有些也是可调的.

这些都是应该选择存储的问题.

一些经验

使用MongoDB或任何文档数据库时,对存储的数据进行广泛的报告可能会更困难,并且一些用例已经将RDBMS和document-db组合在一起用于此目的.

(非常)不同的查询模型.MongoDB也与其他文档-dbs不同.

可灵活地在开发期间更改数据格式/架构

未知领土

在驱动程序和框架中不同程度的成熟度

快速

更简单(在许多方面)产品和管理工具(与许多RDBMS产品相比)

不再有阻抗不匹配.存储适合数据,而不是相反.

减少摩擦并更直接地访问数据.

域名更多依赖于持久性(取决于NoRM的ORM"级别",它取决于后端的抽象程度.我没有使用NoRM,所以我无法回答这个问题.)

2> TTT..：

---

缺点

(缺乏/不同的愿景)耐久性(阅读 http://www.mikealrogers.com/2010/07/mongodb-performance-durability)

没有交易

没有限制

使用MapReduce进行聚合很慢,您需要编写类似分组的代码

报告更难,开发人员定义关系,但业务分析师无法构建自己的查询,他们不能做例如'减'('除了'在sql server术语中)

利弊

你可以轻松添加新的'列'和'表'

速度

分片(仍为测试版)

文档与对象的匹配程度比一组关系表更紧密,因此映射变得更容易

它拓宽了思想

3> Sjuul Jansse..：

---

几天后我一直在探索它.这就是我可以说的:

对于:

没有更多的SQL语句

您的数据库类似于您的类,而不是相反

您的"架构"更灵活

很好地扩展

很容易上手

<意见>很酷

反对:

我目前正在尝试为我的mongo应用程序实现自定义成员资格提供程序和角色提供程序,但当我尝试从mongo中检索它时,我的MemberShip用户类以某种方式具有NULL字段.

在某个地方,我已经读过C#驱动程序,它相对年轻但稳定,所以期待一些变化.(虽然这不会让我退缩)

我注意到教程中缺少的一件事:在对象中初始化列表,否则在尝试.save(yourobj)时会抛出错误.最安全的做法是在类中编写一个构造函数,确保对象中没有任何NULL对象.这样,如果忘记了什么,就不会出错.

---

我为MongoDB编写了一堆ASP.NET提供程序,您可以使用它们:https://github.com/freshlogic/MongoDB.Web

4> GroovyCakes..：

---

你的里程可能会有所不同,但这是一个快速图表,我把它放在一起来比较更新多个"表行"(MongoDB中的非分层平面文档)的速度,有没有索引,让我们知道它如何缩放我们的申请.