关闭

白话MongoDB(一)

标签: mongodb
11102人阅读 评论(0) 收藏 举报

 按照官方的说法,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等知名互联网公司和应用,当然,也包括淘宝网。
  原文链接http://kb.cnblogs.com/page/95936/

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:447418次
    • 积分:3722
    • 等级:
    • 排名:第8619名
    • 原创:29篇
    • 转载:19篇
    • 译文:0篇
    • 评论:4条
    文章分类
    文章存档
    最新评论