标签：
MongoDB是几大NoSQL数据库类型中的文档型数据库。所以我们这里还是要对如今很流行的NoSQL进行介绍。
NotOnly Sql，泛指非关系型数据库。NoSQL的拥护者们提倡运用非关系型的数据存储，通常的应用如：模式自由、支持简易复制、简单的API、最终的一致性（非ACID）、大容量数据等。NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新思维的注入。
随着互联网Web2.0网站的兴起，传统的关系型数据库在应付超大规模和高并发的SNS类型的纯动态网站时显得力不从心，暴露出了很多难以克服的问题：
1、High performance——对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系型数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘lO就已经无法承受了，其实对于普通的BBs网站，往往也存在对高并发写请求的需求。
2、Huge Storage——对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态信息，以国外的Friend feed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability&&High Availability——对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问最与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，可是停机维护随之带来的就是公司收入的减少。
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：数据库事务一致性，数据库的写实时性和读实时性，多表关联查询等等，这些关系型数据库的传统优势往往会成为Web2.0网站对高并发、大数据要求的负担。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题，NoSQL数据库应运而生：NoSQL是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作：在大数据存取上具备关系型数据库无法比拟的性能优势。
现今的计算机体系结构在数据存储方面要求应用架构具备庞大的水平扩展性，而NoSQL正在致力于改变这一现状：目前新浪微博的Redis和Google的Bigtable以及Amazon的SimPleDB使用的就是NoSQL型数据库。
所有的NoSQL项目往往都有一个共同点：可以处理超大量的数据。NoSQL的倡导者一直致力于如何使用更有效更便宜的方法来管理数据。它们认为关系型数据库给你强加了太多你不需要的东西，它们要你强行修改对象数据，以满足数据库系统的需要。当面临Web2.0超大量数据的攻击下，相比NoSQL，关系型数据库就显得十分昂贵而缓慢，而基于NoSQL的数据库替代方案“只是给你所需要的”。
它可以处理超大量的数据
它运行在便宜的PC服务器集群上
它击碎了性能瓶颈
它没有过多的操作
源于社区（开源）
此外，NoSQL的支持者承认关系型数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，它们也同时表示，企业的具体需求可能没那么复杂，对于那些繁重的重复操作的数据，SQL值得花钱，但当数据结构非常简单时，SQL可能没有太大用处。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的：他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。
MongDB最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它是一个面向集合的，模式自由的文档型数据库。
1、面向集合（ColIenction——Orented)
意思是数据被分组存储在数据集中，被称为一个集合（Collenction）。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库(RDBMS）里的表（table)，不同的是它不需要定义任何模式（schema)。
2、模式自由（schema一free)
意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。提了这么多次“无模式”或，“模式自由”，它到是个什么概念呢？例如，下面两个记录可以存在于同一个集合里面：{ “welcome”：”beijing”}、{ “age”：“26”}。
3、文档型
意思是我们存储的数据是键一值对的集合，键是字符串，值可以是数据类型集合里的任意类型，包括数组和文档．我们把这个数据格式称作“BSON”即“Binary SerializedDocument Notation."
下图是MongoDB与关系型数据库的代表MySQL中一些概念的对比：
＆ 面向集合存储，易于存储对象类型的数据。
＆ 模式自由
＆ 支持查询、动态查询
＆ 支持完全索引，包含内部对象
＆ 支持复制（主从复制、副本集）和故障恢复
＆ 使用高效的二进制数（BSON/GridFS）据存储，包括大型对象（如：视频等）
＆ 自动处理碎片，以支持云计算层次的扩展性
＆ 支持Python、PHP、Ruby、Java、C、C++、C#、JS、Perl等语言的驱动程序
网站数据：MongoDB非常适合实时的插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性
缓存：由于性能很高，MongDB也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。
大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储
高伸缩性的场景：MongDB非常适合由数十或数百台服务器组成的数据库。MongoDB的路线图中已经包含对MaPReduce引擎的内置支持。
用于对象及Json数据的存储：MongoDB的BS0N数据格式非常适合文档化格式的存储及查询
很简单，这里以Windows平台下的安装配置为例：
步骤一：下载（选Windows下的）MongoDB https://www.mongodb.org/downloads ，并设置程序存放路径，如下图：
步骤二： 将此目录添加到Path环境变量中，以便以后用命令行来操作
步骤三：建一个目录来存放Mongo的数据文件，例如我的设置在F:\MongoDBData：
步骤四：启动Mongo的服务端：
步骤五：启动Mongo的客户端
这时，在看Mongo的服务端会显示“1 connectionnow open”：
OK，到此Mongo的安装配置已经介绍完了，跟我们前面讲的Redis毫无差别，当然为了以后我们启动Mongo方便，我们可以将启动服务端和启动客户端的上述两个命令分别写到两个bat文件中，到时候直接运行这两个文件即可，如下图：
下面是我的两个文件：
上面讲的是默认的启动配置，例如默认端口是27017，这些配置我们启动的时候都可以自己制定，很简单，不再多说，如下图：
版权声明：本文为博主原创文章，未经博主允许不得转载。
标签：
原文地址：http://blog.csdn.net/wang379275614/article/details/47261959
