从SQL服务器迁移到MongoDB的原因

我知道这是一个很大的问题,这不是一个答案,但我们开发Web应用程序,并正在研究使用MongoDB的持久性解决scheme。 将MongoDB与NoRM结合起来用于对象存储。

我想问的是你从SQL切换到mongo时遇到的问题? 什么时候mongo根本就不是正确的解决scheme,并且是mongodb的优势足以从SQL中移动开发?

非常感谢您提供的任何build议。

在我看来,你的数据格式应该是select存储后端的主要关注点。 你有关系性质的数据吗? 如果是这样,是否可以,并在文档中build模数据是一个好主意? 数据build模在文档数据库中与在关系数据库中一样重要,只是做了不同的处理。 你有多less种types的物体,它们是如何相关的? Mongodb中的DBrefs可以做的伎俩,或者你会错过外键这将是痛苦的? 你的数据访问模式是什么? 你只是提取一个字段值过滤的types的数据,或者你有错综复杂的提取模式?

你需要ACID交易完整性吗? 该域是否对数据执行了很多限制? 你需要文档数据库的可伸缩性因素还是只是一个“酷”的东西?

您的一致性和数据完整性要求是什么? 一些NoSQL解决scheme和MongoDB在写入一致性方面相当宽松,以获得性能。 NoSQL没有统一的格局和其他产品,例如CouchDB在这个部门有其他的特点。 有些也是可调的。

这些都是应该存储的select的问题。

一些经验

  • 在使用MongoDB或任何文档数据库时,对存储的数据进行广泛的报告可能会更困难,并且一些使用案例已经将RDBMS和document-db结合在一起。
  • (非常)不同的查询模型。 MongoDB也不同于其他文档。
  • 在开发过程中灵活地更改数据格式/模式
  • 未知的领土
  • 司机和框架的成熟程度不同
  • 快速
  • 更简单(在很多方面)产品和pipe理工具(与许多RDBMS产品相比)
  • 没有更多的阻抗不匹配。 存储符合数据,而不是相反。
  • 更less的摩擦和更直接的数据访问。
  • 域更多地依赖于持久性(取决于NoRM的ORM“级别”,取决于后端的抽象程度,我没有使用NoRM,所以我不能回答这个问题。)

缺点

  1. (缺乏/不同的视觉)耐久性(阅读http://www.mikealrogers.com/2010/07/mongodb-performance-durability
  2. 没有交易
  3. 没有限制
  4. 与MapReduce的聚合速度很慢,您需要编写类似group-by的代码
  5. 报告更难,开发者定义关系,但业务分析师不能build立自己的查询,他们不能做一个“减”(在SQL服务器术语“除外”),

利弊

  1. 你可以轻松添加新的“列”和“表”
  2. 速度
  3. 分片(还是testing版)
  4. 文档比一组关系表更接近对象,因此映射变得更容易
  5. 它拓宽了思想

这几天我一直在嘲笑它。 这就是我可以说的:

对于:

  • 没有更多的SQL语句
  • 你的数据库类似于你的类而不是其他的方式
  • 你的“架构”更加灵活
  • 好好衡量
  • 很容易上手
  • <意见>很酷</ opinion>

反对:

  • 我目前正在尝试为我的mongo应用程序实现一个自定义的成员资格提供程序和angular色提供程序,但不知何故,当我尝试从mongo中检索它时,我的MemberShip用户类有NULL字段。
  • 在某处我读到了关于C#驱动程序,它相对年轻,但稳定,所以期待一些变化。 (虽然这不会阻止我)

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

图表比较速度来更新记录

你的里程可能会有所不同,但这是一个快速的图表,我把它们放在一起来比较更新多个“表格行”(MongoDB中的非分层平面文档)有无索引的速度,以便让我们了解它将如何扩展我们的应用。

在NoSQL 入门中您可能会发现使用NoSQL数据库(包括MongoDB)的优点和缺点。 一个简短的总结将是:一个不同的数据模型(想象一下如果需要从对象模型到“这个新模型”的映射,它会工作得好),一个不同的查询模型(尽pipe与其他人相比,MongoDB查询是相当有用的) ,没有交易(尽pipe你有一些primefaces操作)。

无论如何,从我的angular度来看,最重要的变化是数据模型以及用这种新方法devise应用程序的方式。