源地址http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_1.html 作者:NinGoo
按照官方的说法,MongoDB是一种可扩展的高性能的开源的面向文档(document-oriented )的数据库,采用C++开发。注意mongo不是mango(芒果),这个词是从humongous中截取出来的,其野心不言而明,直指海量数据存储。和其他很多NoSQL不太一样,MongoDB背后有一个专门的商业公司在提供支持和推广,有点类似MySQL AB的模式。这一系列文章,是为入门者写的,已经对NoSQL和MongoDB有一定研究和经验的,可以略过,或者看看如有疏漏,请留言指出。
面向文档,那么什么是文档呢?很明显这不是我们常见的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)。
大部分的NoSQL产品,为追求性能,一致性等,一般只能支持简单的基于row-key的单条或者范围查询,但是MongoDB可以针对任意列的key创建索引,甚至是内嵌文档里的key,从支持的查询的灵活性上来看,更接近传统的关系数据库,同时还能在性能上向NoSQL看齐,加上支持复制,自动分片和Map/Reduce等功能,非常的吸引眼球,正在成为一款热门的海量存储产品。其背后的商业支持公司10gen,也正在不遗余力的推广,前不久还在北京专门组织了一场技术交流会。在其首页列举的典型客户里,包括foursquare,sourceforge,github等知名互联网公司和应用,当然,也包括淘宝网。