前言
工欲善其事必先利其器。在学习MongoDB之前，需要对MongoDB的一些基本概念有系统的了解。
所以，本篇文章主要介绍MongoDB的一些基本概念，这些概念的定义均来自《MongoDB权威指南》，关于此书想要了解更多，请点击此处。
我尽量使用最简洁的语言来尽可能完整地描述这些基本概念，如有遗漏或不妥之处欢迎指正。
文档
文档是MongoDB的核心概念之一。多个键值对有序地放在一起便是文档。例如：
{"name":"Jerry","score":80}
这个文档有2个键值对，一个是name，其对应的值为"Jerry"，另一个是score，其对应的值为“80”。
文档中的键值对是有序的，上面的文档和下面的文档是完全不同的：
{"score":80,"name":"Jerry"}
文档中的值不仅可以是双引号中的字符串，也可以是数值，比如上面文档中的score，还可以是其他几种数据类型，甚至可以是整个嵌入的文档(会在后续文章中介绍)。
MongoDB不单区分类型，也区分大小写，下面2个文档是不同的：
{"score":80}
{"score":"80"}
下面2个文档也是不同的：
{"score":80}
{"Score":80}
另一个需要注意的地方是，文档中的键不能重复，例如下面的文档是不符合规定的：
{"name":"Jerry","score":80,"score":90}
集合
集合也是MongoDB的核心概念之一。集合就是一组文档。如果说文档类似于关系型数据库的记录的话，那集合就类似于关系型数据库的表。
集合中的文档可以是多式多样的，例如下面的2个文档可以同属于一个集合：
{"name":"长安乱","press":"春风文艺出版社","date":"2004-08-01"}
{"author":"韩寒"}
根据文档的概念，我们知道文档中的键是不能重复的，那集合中的文档是否可以重复？
答案是肯定的，集合中可以放置任意的文档，例如下面的集合是完全符合规定的：
{"name":"长安乱","press":"春风文艺出版社","date":"2004-08-01"}
{"name":"长安乱","press":"春风文艺出版社","date":"2004-08-01"}
因为集合中可以放置任意的文档，那随之而来一个问题，还有必要使用多个集合吗？
答案也是肯定的，理由如下：
- 把各种各样的文档都混在一个集合里面，无论对于开发者还是管理员来说都是噩梦。开发者要么确保每次查
询只返回需要的文档类型，要么让执行查询的应用程序来从这些文档中筛选出所需要的类型。如果查询书的名字还要剔除那些含有作者数据的文档，就很令人恼火。
- 在一个集合里面查询特定类型的文档在速度上也很不划算，分开做多个集合要快得多。
从只含书籍信息的集合中查询出几本书，要比从含有书和作者信息的集合中查询消耗更少的磁盘寻道操作。 - 当创建索引的时候，文档会有附加的结构(尤其是有唯一索引的时候)。索引是按照集合来定义的，把同种类
型的文档放入同一个集合里面，可以使索引更加有效。
以上3点理由摘自《MongoDB权威指南》，并稍作了修改。
子集合
在集合的命名中引入"."来组织集合是一个惯例，例如blog.posts和blog.authors，posts和authors可以看作blog的子集合，这里blog本身可以是一个集合，也可以根本就不存在。
数据库
MongoDB中多个文档组成集合，同样多个集合可以组成数据库。一个MongoDB实例可以承载多个数据库，它们之间可视为完全独立的。
在对数据库命名的时候，应避免使用以下被保留的数据库名：
- admin
从权限的角度来看，这是一个“root"数据库。如果将一个用户添加到这个数据库，这个用户就自动继承所有数据库的权限。一些特定的服务器端命也只能从这个数据库运行，比如列出所有的数据库或关闭服务器。
- local
这个数据库永远不会被复制，可以用来存储限于本地单台服务器的任意集合。
- config
当Mongo用于分片设置时，config数据库在内部使用，用于保存分片的相关信息。
把数据库的名字放到集合名称之前，就得到集合的完全限定名，称为命名空间。例如cms数据库中的集合blog.posts的命名空间为cms.blog.posts。
MongooooooooooooooooooooDB入门二：基本概念介绍,布布扣,bubuko.com