按照官方的说法，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等知名互联网公司和应用，当然，也包括淘宝网。
[65] 