MongoDB 与传统关系型数据库mysql比较

①弱一致性（最终一致），更能保证用户的访问速度：
举例来讲，在传统的关系型数据库中，一个COUNT类型的操做会锁定数据集，这样能够保证获得“当前”状况下的精确值。这在某些状况下，例 如经过ATM查看帐户信息的时候很重要，但对于Wordnik来讲，数据是不断更新和增加的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延 迟。他们须要的是一个“大约”的数字以及更快的处理速度。

但某些状况下MongoDB会锁住数据库。若是此时正有数百个请求，则它们会堆积起来，形成许多问题。咱们使用了下面的优化方式来避免锁定：
每次更新前，咱们会先查询记录。查询操做会将对象放入内存，因而更新则会尽量的迅速。在主/从部署方案中，从节点可使用“-pretouch”参数运行，这也能够获得相同的效果。 
使用多个mongod进程。咱们根据访问模式将数据库拆分红多个进程。 
②文档结构的存储方式，可以更便捷的获取数据。
对于一个层级式的数据结构来讲，若是要将这样的数据使用扁平式的，表状的结构来保存数据，这不管是在查询仍是获取数据时都十分困难。
举例1：
就拿一个“字典项”来讲，虽然并不十分复杂，但仍是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库 中的主键和外键表现出来，但把它看做一个“文档”而不是“一系列有关系的表”岂不更好？使用 “dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂（每每代价也很高）的链接查询方便 且快速。

举例2：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客， 评论与投票做为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操做。

CODE↓

> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},
  comments : [{ by: "Abe", text: "First" },
              { by : "Ada", text : "Good post" }]
})

> db.blogposts.find( { "author.name" : "Jane" } )

> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",
  comments : [{ by: "Abe", text: "First" },
              { by : "Ada", text : "Good post" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )

> db.blogposts.ensureIndex( { "comments.by" : 1 } );

 

举例③：
MongoDB是一个面向文档的数据库，目前由10gen开发并维护，它的功能丰富，齐全，彻底能够替代MySQL。在使用MongoDB作产品原型的过程当中，咱们总结了MonogDB的一些亮点：
使用JSON风格语法，易于掌握和理解：MongoDB使用JSON的变种BSON做为内部存储的格式和语法。针对MongoDB的操做都使用JSON风格语法，客户端提交或接收的数据都使用JSON形式来展示。相对于SQL来讲，更加直观，容易理解和掌握。
Schema-less，支持嵌入子文档：MongoDB是一个Schema-free的文档数据库。一个数据库能够有多个Collection，每 个Collection是Documents的集合。Collection和Document和传统数据库的Table和Row并不对等。无需事先定义 Collection，随时能够建立。
Collection中能够包含具备不一样schema的文档记录。 这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档能够有10个属 性，属性的类型既能够是基本的数据类型（如数字、字符串、日期等），也能够是数组或者散列，甚至还能够是一个子文档（embed document）。这 样，能够实现逆规范化（denormalizing）的数据模型，提升查询的速度。

 

③内置GridFS，支持大容量的存储。
  GridFS是一个出色的分布式文件系统，能够支持海量的数据存储。
  内置了GridFS了MongoDB，可以知足对大数据集的快速范围查询。
④内置Sharding。
提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分红若干个段，切分到不一样的Shard上。
Shards能够和复制结合，配合Replica sets可以实现Sharding+fail-over，不一样的Shard之间能够负载均衡。查询是对 客户端是透明的。客户端执行查询，统计，MapReduce等操做，这些会被MongoDB自动路由到后端的数据节点。这让咱们关注于本身的业务，适当的 时候能够无痛的升级。MongoDB的Sharding设计能力最大可支持约20 petabytes，足以支撑通常应用。
这能够保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来很是方便而且成本很低，避免了“sharding”操做的复杂性和成本。

⑤第三方支持丰富。(这是与其余的NoSQL相比，MongoDB也具备的优点)
如今网络上的不少NoSQL开源数据库彻底属于社区型的，没有官方支持，给使用者带来了很大的风险。
而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。
并且MongoDB社区很是活跃，不少开发框架都迅速提供了对MongDB的支持。很多知名大公司和网站也在生产环境中使用MongoDB，愈来愈多的创新型企业转而使用MongoDB做为和Django，RoR来搭配的技术方案。
⑥性能优越：
在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际没法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能一样很使人满意，一样写入百万级别的数 据，mongodb比我之前试用过的couchdb要快得多，基本10分钟如下能够解决。补上一句，观察过程当中mongodb都远算不上是CPU杀手。

与关系型数据库相比，MongoDB的缺点：
①mongodb不支持事务操做。
  因此事务要求严格的系统（若是银行系统）确定不能用它。(这点和优势①是对应的)
②mongodb占用空间过大。
  关于其缘由，在官方的FAQ中，提到有以下几个方面：
一、空间的预分配：为避免造成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，并且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的最大致积。随着数据量的增长，你能够在其数据目录里看到这些整块生成容量不断递增的文件。

二、字段名所占用的空间：为了保持每一个记录内的结构信息用于查询，mongodb须要把每一个字段的key-value都以BSON的形式存储，若是 value域相对于key域并不大，好比存放数值型的数据，则数据的overhead是最大的。一种减小空间占用的方法是把字段名尽可能取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上做为权衡了。我曾建议做者把字段名做个index，每一个字段名用一个字节表示，这样就不用担忧字段名取多长 了。但做者的担心也不无道理，这种索引方式须要每次查询获得结果后把索引值跟原值做一个替换，再发送到客户端，这个替换也是挺耗费时间的。如今的实现算是 拿空间来换取时间吧。

三、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”便可，之后还能够重复利用。

四、能够按期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢

③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。