MongoDB是一个基于分布式文件存储的数据库。由C 语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
- 功能特性：
· 面向集合存储，易存储对象类型的数据。
· 模式自由。
· 支持动态查询。
· 支持完全索引，包含内部对象。
· 支持查询。
· 支持复制和故障恢复。
· 使用高效的二进制数据存储，包括大型对象（如视频等）。
· 自动处理碎片，以支持云计算层次的扩展性
· 支持RUBY，PYTHON，JAVA，C ，PHP等多种语言。
· 文件存储格式为BSON（一种JSON的扩展）
· 可通过网络访问
- 使用原理：
所谓“面向集合”（Collection-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collection)。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。Nytro MegaRAID技术中的闪存高速缓存算法，能够快速识别数据库内大数据集中的热数据，提供一致的性能改进。
模式自由（schema-free)，意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。
存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各种复杂的文件类型。我们称这种存储形式为BSON（Binary Serialized Document Format）。
MongoDB已经在多个站点部署，其主要场景如下：
1）网站实时数据处理。它非常适合实时的插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
2）缓存。由于性能很高，它适合作为信息基础设施的缓存层。在系统重启之后，由它搭建的持久化缓存层可以避免下层的数据源过载。
3）高伸缩性的场景。非常适合由数十或数百台服务器组成的数据库，它的路线图中已经包含对MapReduce引擎的内置支持。
不适用的场景如下：
1）要求高度事务性的系统。
2）传统的商业智能应用
3）复杂的跨文档（表）级联查询
- 应用环境：
MongoDB服务端可运行在Linux、Windows或mac os x平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。
- 设计特征：
MongoDB 的设计目标是高性能、可扩展、易部署、易使用，存储数据非常方便。
（1）面向集合存储，容易存储对象类型的数据。在MongoDB 中数据被分组存储在集合中，集合类似RDBMS 中的表，一个集合中可以存储无限多的文档
（2）模式自由，采用无模式结构存储。在MongoDB 中集合中存储的数据是无模式的文档，采用无模式存储数据是集合区别于RDBMS 中的表的一个重要特征
（3）支持完全索引，可以在任意属性上建立索引，包含内部对象。MongoDB的索引和RDBMS 的索引基本一样，可以在指定属性、内部对象上创建索引以提高查询的速度。除此之外，MongoDB 还提供创建基于地理空间的索引的能力
（4）支持查询。MongoDB 支持丰富的查询操作，MongoDB 几乎支持SQL中的大部分查询
（5）强大的聚合工具。MongoDB 除了提供丰富的查询功能外，还提供强大的聚合工具，如count、group 等，支持使用MapReduce 完成复杂的聚合任务
（6）支持复制和数据恢复。MongoDB 支持主从复制机制，可以实现数据备份、故障恢复、读扩展等功能。而基于副本集的复制机制提供了自动故障恢复的功能，确保了集群数据不会丢失
（7）使用高效的二进制数据存储，包括大型对象（如视频）。使用二进制格式存储，可以保存任何类型的数据对象
（8）自动处理分片，以支持云计算层次的扩展。MongoDB 支持集群自动切分数据，对数据进行分片可以使集群存储更多的数据，实现更大的负载，也能保证存储的负载均衡
（9）支持Perl、PHP、Java、C#、JavaScript、Ruby、C 和C 语言的驱动程序，MongoDB 提供了当前所有主流开发语言的数据库驱动包，开发人员使用任何一种主流开发语言都可以轻松编程，实现访问MongoDB 数据库
（10）文件存储格式为BSON（JSON 的一种扩展）。BSON 是对二进制格式的JSON 的简称，BSON 支持文档和数组的嵌套
（11）可以通过网络访问。可以通过网络远程访问MongoDB 数据库
- 基本概念：
（1）文档
文档是 MongoDB 中数据的基本单位，类似于关系数据库中的行（但是比行复杂）。多个键及其关联的值有序地放在一起就构成了文档。不同的编程语言对文档的表示方法不同，在JavaScript 中文档表示为：
{“greeting”:“hello,world”}
这个文档只有一个键“greeting”，对应的值为“hello,world”。多数情况下，文档比这个更复杂，它包含多个键/值对。例如：
{“greeting”:“hello,world”,“foo”: 3}
文档中的键/值对是有序的，下面的文档与上面的文档是完全不同的两个文档。
{“foo”: 3 ,“greeting”:“hello,world”}
文档中的值不仅可以是双引号中的字符串，也可以是其他的数据类型，例如，整型、布尔型等，也可以是另外一个文档，即文档可以嵌套。文档中的键类型只能是字符串。
（2）集合
集合就是一组文档，类似于关系数据库中的表。集合是无模式的，集合中的文档可以是各式各样的。例如，{“hello,word”:“Mike”}和{“foo”: 3}，它们的键不同，值的类型也不同，但是它们可以存放在同一个集合中，也就是不同模式的文档都可以放在同一个集合中。既然集合中可以存放任何类型的文档，那么为什么还需要使用多个集合？这是因为所有文档都放在同一个集合中，无论对于开发者还是管理员，都很难对集合进行管理，而且这种情形下，对集合的查询等操作效率都不高。所以在实际使用中，往往将文档分类存放在不同的集合中，例如，对于网站的日志记录，可以根据日志的级别进行存储，Info级别日志存放在Info 集合中，Debug 级别日志存放在Debug 集合中，这样既方便了管理，也提供了查询性能。但是需要注意的是，这种对文档进行划分来分别存储并不是MongoDB 的强制要求，用户可以灵活选择。
可以使用“.”按照命名空间将集合划分为子集合。例如，对于一个博客系统，可能包括blog.user 和blog.article 两个子集合，这样划分只是让组织结构更好一些，blog 集合和blog.user、blog.article 没有任何关系。虽然子集合没有任何特殊的地方，但是使用子集合组织数据结构清晰，这也是MongoDB 推荐的方法。
（3）数据库
MongoDB 中多个文档组成集合，多个集合组成数据库。一个MongoDB 实例可以承载多个数据库。它们之间可以看作相互独立，每个数据库都有独立的权限控制。在磁盘上，不同的数据库存放在不同的文件中。MongoDB 中存在以下系统数据库。
- Admin 数据库：一个权限数据库，如果创建用户的时候将该用户添加到admin 数据库中，那么该用户就自动继承了所有数据库的权限
- Local 数据库：这个数据库永远不会被负责，可以用来存储本地单台服务器的任意集合
- Config 数据库：当MongoDB 使用分片模式时，config 数据库在内部使用，用于保存分片的信息
- 数据模型：
一个MongoDB 实例可以包含一组数据库，一个DataBase 可以包含一组Collection（集合），一个集合可以包含一组Document（文档）。一个Document包含一组field（字段），每一个字段都是一个key/value pair。
key: 必须为字符串类型
value：可以包含如下类型
- 基本类型，例如，string，int，float，timestamp，binary 等类型
- 一个document
- 数组类型
- 应用场景：
MongoDB 的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）和传统的RDBMS 系统（具有丰富的功能）之间架起一座桥梁，它集两者的优势于一身。根据官方网站的描述，Mongo 适用于以下场景
- 网站数据：Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性
- 缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo 搭建的持久化缓存层可以避免下层的数据源过载
- 大尺寸、低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储
- 高伸缩性的场景：Mongo 非常适合由数十或数百台服务器组成的数据库，Mongo 的路线图中已经包含对MapReduce 引擎的内置支持
- 用于对象及JSON 数据的存储：Mongo 的BSON 数据格式非常适合文档化格式的存储及查询
MongoDB 的使用也会有一些限制，例如，它不适合于以下几个地方：
- 高度事务性的系统：例如，银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序
- 传统的商业智能应用：针对特定问题的BI 数据库会产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择
- 需要SQL 的问题
