MongoDB 是面向集合存储的文档型数据库，其涉及到的基本概念与关系型数据库相比有所不同。举个例子，在关系型数据库中，我们记录一个订单的信息，通常是这样设计表结构的：
设计一个订单基本信息表和一个订单明细表，1个订单有N个订单明细，这些订单明细通过外键关联到订单主表，所以要存储一个订单的信息，需要“1+N”条记录。在MongoDB中将订单基本信息和该订单的所有订单明细信息通过嵌套的json格式组织起来，保存为1个文档。也就是说在关系型数据库中需要“1+N”条记录存储的数据，MongoDB保存为1个类似Json的文档。所以，关系型数据库中的一条记录(或1+N条记录)基本相当于MongoDB的一个文档。关系型数据库中一个表存储多条记录，MongoDB中用一个“文件夹”存放多个类似的文档，并将这样的“文件夹”叫做集合。下面是MongoDB和关系型数据库的概念比较：
| MongoDB | 关系型数据库 |
| Databse(数据库) | Databse(数据库) |
| Collection(集合) | Table(表) |
|
Document(文档) |
Record/Row(记录/行) |
|
field(字段) |
Column(列) |
|
Index(索引) |
Index(索引) |
|
embedded documents/reference （内嵌文档/引用） |
table joins(表连接) |
文档是MongoDB最核心的概念，本质上是一种类JSON的BSON格式的数据。BSON是一种类JSON的二进制格式数据，它可以理解为在JSON基础上添加了一些新的数据类型，包括日期、int32、int64等。BSON是由一组组键值对组成，它具有轻量性、可遍历性和高效性三个特征。可遍历性是MongoDB将BSON作为数据存储的主要原因。
使用MongoDB文档时需要注意以下问题：
1.MongoDB中写操作的原子性限制在文档级别，对文档的保存、修改、删除等都是原子操作；
由于MongoDB是弱事务性的，所以当需要保证数据完整性存储时，可以利用文档的原子性来保障。还是以上面订单的例子来说，为防止MongoDB在保存主订单信息和订单明细时发生部分数据未保存成功，可以将订单主信息和订单明细保存为一个文档，这样，要么整体保存成功，要么整体失败，就相当于实现了事务的效果。
2.单个文档占用的存储空间不能超过16MB；
3.MongoDB会尽量保持文档被插入时键值对的顺序，但是不严格保证。
文档键(field)的命名需要注意以下几点：
1._id是系统保留的关键字，它是默认的主键，该值在集合中必须唯一，且不可更改
2.键不能包含\0或空字符，这个字符用于表示键的结尾
3.不能以$开头
4.不能包含.(点号)
5.键是区分大小写的且不能重复 例如：{foo:1,Foo:1}
集合的命名需要注意以下几点：
1.集合名不能是空字符串（""）
2.集合名不能含有\0字符（空字符），该字符表示集合名的结尾
3.集合名不能以"system."开头，此前缀是系统本身保留的
4.集合名中不能包含$字符（注：可包含.）
用命名空间组织集合：
类似于A文件夹下面存放某文档(或A文件夹下面存放B文件夹，然后B文件夹下面存放某文档)，那么获得该文档的路径为：A/文档（或A/B/文档），将“／”替换为“.”，变为“A.B.文档”，那么“A.B.”就是该文档的命名空间。
1.把数据库名添加到集合名字前面，中间用点号连接，得到集合的完全限定名，就是命名空间，例如：命名空间 neighbor.blog。
2. 需要说明的是，点号还可以出现在集合名字中，例如：neighbor.blog.reviews ，可以将reviews集合看作是blog集合的子集合。
3.使用子集合可以使我们更好的组织数据，使数据的结构更加清晰明了。