MongoDB的优缺点



  • 前言
    MongoDB作为Nosql主流数据库,它的优缺点肯定也跟Nosql的特性有关。其实一个数据库的好坏还是要根据具体业务需求来分析。本文与其说mongodb的优缺点,还不如说是mongodb的特性,但文中会作一些比较,所以还是叫mongodb的优缺点合适。

    MongoDB 优点

    • 无模式
      它可以减少表的空余字段,减少拆表的必要,例如用户集合可以一条记录带有 admin: true 属性,其他不带有这个属性,而在关系数据库中这类带来大量空余字段的属性最好拆表。如果觉得 admin: true 的例子太简单,可以考虑下怎么储存 gemspec 的内容并让它可索引。
      无模式另一个好处是让代码逻辑管理起来更清晰,可以把属性定义和模型逻辑放在一起:

       class Artist
              include Mongoid::Document
              field :name, type: String
       end
      

      类似 DataMapper 的库虽然也能实现这样的语法,但始终需要维护一个迁移脚本,需要重复自己。用 Mongoid 的时候我一直觉得打开 Model 文件先看到属性定义很舒服。

    • 数据类型
      MongoDB 支持的数据类型多于 MySQL,其中最主要是 Array,Hash 类型。而PostgreSQL 原生或通过扩展可以支持 Array 和 Hash,但是配套的操作不如 MongoDB 的简便。
      例如 MongoDB 对 Array 有一个 $addToSet 方法,只有数组不存在某元素时进行插入:

       update( $addToSet: { upvotes_ids: 1 } )
      

      而 PostgreSQL 要进行同样操作需要组合一些语句:

      SET upvotes_ids = array_append(upvotes_ids ,1) WHERE NOT (upvotes_ids @>array[1])
      所以MongoDB 的语句更简洁。

    MongoDB 缺点

    • 无模式缺点
      最大坏处就是无法真正掌握数据库中有什么内容,实际上并不是经常需要储存无模式数据,多数是模式化数据。所以即使不需要管理模式迁移,还是要管理数据迁移,每次更改属性相关逻辑时要写数据迁移脚本。这里无模式是好是坏取决于应用场景。

    • 不支持事务
      也许需不需要数据库事务成了是否选择 MongoDB 的决定性因素,MongoDB 不支持数据库事务。
      有很多应用对数据一致性其实要求不高,例如很多社交应用,大多数应用逻辑只是简单存取(发一段文字,上传一张照片),极少的不一致是不影响应用的。 而一些严肃应用,例如交易系统,就很需要数据库事务的支持了,否则就需要在应用层自己实现一个粗糙的、充满 Bug 的事务支持。如果有兴趣自己实现事务操作,可以看 MongoDB 的文章 Perform Two Phase Commits。
      如果有跨系统的事务操作,就不能完全依赖数据库事务,还要有应用层的重试或回滚操作(例如远程调用支付接口)。数据库层面支持事务的话,起码让维护系统内部数据一致性更轻松。

    • 查询语法
      MongoDB 的原生查询语法是 JavaScript,JavaScript 程序员可能对此欣喜若狂。我最初感觉也是很新鲜,但久了就觉得很烦躁。JavaScript 太多的括号和花括号,在组合多个查询条件的时候作括号匹配很费神。SQL 是一个查询 DSL,虽然看起来有点古老,但是在查询这个特定领域上做得很好。
      如果应用使用 ORM,可能很多时候不需要写原生查询语句。除了 PHP 社区外,其他社区也不推荐写原生查询。不过少数情况下,复杂查询还是原生语句更高效,而且数据库终端也是调试查询错误的最终手段,所以查询语法至少不能让人难受。

    结语
    从关系数据库到MongoDB,其实应用哪个数据都应该根据具体业务来决定,而不是个人喜好,数据库切换更是如此 。但有一个是可以确定的:如果当前数据库用得很好,就没必要更换。


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待