知道mongoDB好几年了，但是真的一直没有好好的研究过，知道是nosql（not only sql），BSON的文档数据结构等等，但一直都是单机使用。现在进入新的项目组，使用MongoDB进行商品数据的存储，不知道为什么会选择MongoDB为数据库。后面知道一点点是因为MongoDB的集合的动态模式（dynamic schema）特性，可以适应商品的不断变化的需求。于是想好好的对MongoDB进行研究一番。。。
MomgoDB是一个基于分布式文件系统的nosql数据库（使用C++编写），mongo的各种特性就是为了为应该提供可扩展（应对现 在互联网系统，不断变化的需求和数据结构）高性能（互联网系统数据量的高速增长趋势）数据存储解决方案。开始mongo之前需要对其设计特性和解决的问题进行了解，start：
一、Nosql数据库
MongoDB是比较熟知的Nosql（not only sql）数据库，所以需要对nosql数据库的概念进行了解（包括产生的背景）。如果是做互联网行业的话，应该理解很深刻的就是上面所说的可扩展和高性能，mongo就是为了解决问题而产生的。
1、背景
1、不断变化的需求和数据结构： 需求的变更速度和方向难以想象，而RDBMS很难针对这样的变化进行维护（比如我现在的电商项目的商品，就是使用的mongo），比如当需要增加一个字段的时候，需要在上千万的数据表中增加一个字段、赋值一个默认值（还很有可能需要增加索引）等。
2、数据量的急剧上升：在网上找的一张图片，说明了互联网项目数据的增加速度，使用RDBMS真的很难去应对。
2、CAP理论和Base理论
大名鼎鼎的CAP和Base理论，也是现在很多系统设计的基础理论。网上到处都是其解释，现在只是简单的说一下概念。
1、CAP（Consistency、Availabitily、Partition Tolerance）：一个分布式系统不能同时满足三者，只能满足其中的两种，即CA、CP或AP。
2、BASE（Basically Availible、Soft-state、Eventual Consistency）：基于CAP理论，而在实际项目中一般会使用的BASE理论，项目基本可用、软状态（即柔性事务，针对ACID而言）、最终一致（在一定时间后，或者使用补偿机制，实现ACID的最终一致）。
最主要是在网上找的一张图，觉得解释的很好，但是说实话自己还是没怎么想太明白，但是需要阐述的是Mongo与cap的关系：
二、与关系型数据库比较
1、概念比较
一般学习MongoDB的人都是从关系型数据库转过来的，所以需要知道几个概念，或者可以类比进行学习。
| 关系型数据库术语或概念 | MongoDB术语或概念 |
说明 |
| DataBase | DataBase | 数据库 |
| Table | Collection | 数据库表、集合 |
| Row | Document | 数据记录行、文档 |
| Column | Field | 数据列、字段 |
| Index | Index | 索引 |
| Table Jions | MongoDB不支持联合（join）查询 | |
| Primary Key | Object ID | 主键、MongoDB会自动将_id设置为主键（默认是MongoDB的Object ID类型） |
2、特点
1)、MongoDB不支持join查询
自己认为这点对于应用查询设计来说还是很重要的，至少在数据格式的存储上面显得比较重要。是冗余的存储在原表的一个字段中，还是使用循环后再来另一张表中查询。若冗余在join的主表中，那么当被join的表中该字段修改的时候则需要进行同步（或异步）修改。这一点即后面会专门讲解的范式化和反范式化中展开，最主要的因素还是取决于应用查询的特性，读多还是写多，等。
2)、Collection的动态模式
MongoDB中的集合是动态模式（Dynamic schema）的，不像RDBMS中需要预先定义好字段名称、类型等。
3)、MongoDB的Shell
MongoDB自带了一个简单但是功能强大的JavaScript shell，用于对mongo实例和数据操作，这点还是非常方便的，至少学习成本比较低。
三、MongoDB使用场景和不适用场景
针对应用字体的特性，对数据库和架构的选型非常的重要，那么在开始mongo的一大堆特性学习之前，MongoDB的使用场景和不适合的场景高于一切。
1、适用场景
1)、网站实时数据
MongoDB非常适合实时的插入、更新和查询；并具备网站实时数据存储所需要的复制和高伸缩性。
2)、数据缓存
由于性能很高，MongoDB也适合作为信息基础设施的缓冲层。在重启系统之后，MongoDB搭建持久化缓存层可以避免下层数据源的过载。但是个人觉得，那既然是缓存层，那还不如直接使用redis。
3)、大尺寸、低价值数据的存储
使用传统的关系型数据库存储一些不是那些重要的庞大的数据的时候，代价是比较高的（比如日志等）。
4)、高伸缩性场景
MongoDB非常适合有数十台到数百台服务器组成的数据库（支持副本集和分片的集群），并且支持MapReduce引擎，对大数据量、实时性要求不高的数据提供查询能力。
5)、对象或Json数据的存储
MongoDB的BSON数据格式非常适合文档化数据的存储和查询。
2、不适用场景
1)、高度事务性系统
比如银行等系统，对于数据的一致性要求比较高的系统，那么支持ACID的关系型数据库更适合。
2)、传统的商业智能应用
针对特定问题的BI数据库会对查询高度的优化，则数据仓库更适合。这点感觉不是很理解。
3)、需要复杂的SQL查询