初识MongoDB（一）

 

    按照官方的说法，MongoDB是一种可扩展的高性能的开源的面向文档（document-oriented ）的数据库，采用C++开发。

 

    面向文档，那么什么是文档呢？很明显这不是我们常见的word文档。这里说的文档，是一种可以嵌套的数据集合。从关系数据库的范式的概念来说，嵌套是明显的反范式设计。范式设计的好处是消除了依赖，但是增加了关联，查询需要通过关联两张或者多张表来获得所需要的全部数据，但是更改操作是原子的，只需要修改一个地方即可。反范式则是增加了数据冗余来提升查询性能，但更新操作可能需要更新冗余的多处数据，需要注意一致性的问题。

 

    一个典型的例子，如blog，关系数据库中一般可以把文章设计为一张表，评论设计为一张表，那么在页面需要展示一篇文章和其对应的评论的时候，就需要关联查询文章表和评论表。但是面向文档的设计，可以将评论作为文章的一个嵌套文档存放在一起，这不但省去了关联查询，由于存储在一起，查询的性能也可以做到更好。

 

    MongoDB的面向文档采用的是BSON，一种类似JSON的格式，但是是二进制序列化的。如上面提到的blog的文章和评论，可以做如下设计：

 

{ 'id':1, 'author':'NinGoo', 'title':'白话MongoDB（一）', 'content':'按照官方的说法，此处省略一万字',
    comment:[ { 'comment-author':'宋兵甲', 'comment-content':'有木有' } ,
              { 'comment-author':'尼玛','comment-content':'伤不起啊' }
            ]
}

    1. 相关数据存放在一起，针对性的查询可以消除join，性能比分散存储要高且方便。

    2. 整个结构清晰自解析。所有字段名和值都存储，所以不需要提前设计结构，key的名字和数目可以任意指定，也就是所谓的schema-free。

    3. 由于字段名在每一行每一列都需要重复存在，会带来一些额外的存储消耗，这在海量数据及字段较多的时候也需要考虑。

    4. 一个document的长度有限，1.7.2之前是4MB，目前是8MB，以后可能增长到32MB。如果有更大的数据，可以使用MongoDB底层的GridFS直接作为文件存储。

    5. 如果需要查找某个评论者的所有评论，则相对困难。当然，MongoDB支持任意key的索引，这也不是什么大问题。

 

    像上面的一个结构，为一个文档（document），相当于关系数据库中的一行记录，多个文档组成一个集合（collection），相当于关系数据库的表。多个集合（collection），逻辑上组织在一起，就是数据库（database），一个MongoDB实例支持多个数据库（database）。

 

 

 

参考资料：

http://nosql-database.org/ 收集了基本上目前所有的NoSQL系统

http://www.mongodb.org/      面向文档的nosql数据库

http://cassandra.apache.org/ apache的开源项目

 

 

转载自：http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_1.html