声明：该文章主要来自《MongoDB实战》1书内容,主要想通过该书学习MongoDB的相应知识，加深理解，故写在自己的博文当中，作为记录在最后的章节中，会有1个自己集合MongoDB数据库利用的JavaEE的web利用。
第1章 走进MongoDB
MongoDB是1个高性能、开源、无模式的文档型数据库，是当前NoSQL数据库产品中最热门的1种，它在许多场景下可用于替换关系型数据库或键/值存储方式，MongoDB使用C++开发，MongoDB的官网是地址是:http://www.mongodb.org/，可以在此取得更多的详细信息。
1.1、为何要用NoSQL
1.1.1、NoSQL简介
NoSQL，全程Not Only SQL，指的是非关系型的数据库，这类数据库主要有这些特点：非关系型的、散布式的、开源的、水平可扩大的，原始的目的是为了大范围web利用，这场全新的数据库革命运动初期就有人提出，发展至2009年趋势越发高涨，NoSQL的拥戴者们提倡应用非关系型的数据存储，通常的利用如：模式自由、支持建议复制、简单的API、终究的1致性(非ACID)、大容量数据等，NoSQL被我们用得最多得当数key-value存储，固然还有其他的文档、列存储、图型数据库、xml数据库等，相对目前遮天蔽日的关系型数据库应用，这1概念无疑是1种全新思惟的注入。
1.1.2、发展现状
当今的计算机体系结构在数据存储方法要求利用架构具有庞大的水平扩大性，而NoSQL正在致力于改变这1现状，目前新浪微博的Redis和Google的Bitable和Amazon的SimpleDB使用的就是NoSQL型的数据库，NoSQL项目的名字上看不出甚么相同的地方，但是它们通常在某些方面相同：它们可以处理超大量的数据。
这场革命目前仍需等待，NoSQL对大型企业来讲还不是主流，但是1两年以后就会变个模样，在NoSQL运动的最新1次集会中，来自世界各地的150人，挤满了CBS Interactive的1间会议室，分享他们如何颠覆缓慢昂贵的关系数据库的暴政，怎样使用有效和更便宜的方法来管理数据。
关系型数据库给你强加了太多的东西，它们要你强行修改对象数据，以满足数据库新系统的需要，在NoSQL拥戴者们来看，基于NoSQL的数据库替换方案，只是给你所需要的。
1.1.3、为何是NoSQL
随着互联网web2.0网站的兴起，非关系型数据库现在成了1个及其热门的新领域，非关系型数据库产品的发展非常迅速，而传统的关系型数据库在应付web2.0网站，特别是超大范围和高并发的SNS类型的web2.0纯动态网站已显得力不从心，暴露了难以克服的问题，比如：
1、High performance 对数据库高并发写的需求。
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上没法使用动态网页静态化技术，因此数据库并发负载非常高，常常要到达每秒上万次读写要求，关系型数据库应付上万次的SQL查询还委曲顶得住，但是应付上万次的SQL写数据要求，硬盘IO就已没法承受了，其实对普通的BBS网站，常常也存在对高并发写要求的需求。
2、Huge Storage 对海量数据的高效存储和访问的需求。
对大型的SNS网站，每天用户产生海量的用户动态信息，以国外的Friend feed为例子，1个月就到达了2.5亿条用户动态，对关系型数据库来讲，在1张2.5亿条记录的表里进行SQL查询，效力是极为低下乃至不可忍耐的，再如大型web网站用户登录系统，比如腾讯、盛大、动辄数亿计的账号、关系数据库也很难以应付。
3、High Scalability && High Availability 对数据库的高扩大性和高可用性的需求。
在基于web的架构当中，数据库是最难进行横向扩大的，当1个利用系统的用户量和访问量与日俱增时，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩大性能和负载能力，对很多需要提供24小时不中断服务的网站来讲，对数据库系统进行升级和扩大是非常痛苦的事情，常常需要停机保护和数据迁移，可是停机保护随之带来的就是公司收入的减少。
在上面提高的3高需求眼前，关系数据库遇到难以克服的障碍，而对web2.0网站来讲，关系数据库的很多主要特性却常常无用武之地。比如：
1、数据库事务1致性需求
很多web实时系统其实不要求严格的数据库事务，对读1致性的要求很低，有些场合对写1致性要求也不高，因此数据库事务管理成了数据库高负载下1个沉重的负担。
2、数据库的写实时性和读实时性需求。
对关系数据库来讲，插入1条数据以后立刻查询，是肯定可以读出来这条数据的，但是对很多web利用来讲，其实不 高俅这么高的实时性。
3、对复杂的SQL查询，特别是夺标关联查询的需求。
任何大量数据的web系统，都非常忌讳多个大表的关联查询，和复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求和产品设计角度，就避免了这类情况的产生，常常更多的只是单表的主键查询，和单表条件分页查询，SQL功能的被极大的弱化了。
因此关系数据库在这些愈来愈多的利用场景下显得不那末适合了，为了解决这1问题的NoSQL数据库应运而生。
NoSQL是非关系型数据存储的广义定义，它打破了久长以来关系型数据库与ACID理论大1统的局面，NoSQL数据存储不需要固定的表结构，通常也不存在连接操作，在大数据存取上具有关系型数据库没法比拟的性能优势，该概念在2009年初得到广泛的认可。‘
现今的利用体系结构需要数据存储在横向伸缩性上能满足需求，而NoSQL存储就是为了实现这个需求。Google的BigTable与Amazon的Dynamo是非常成功的商业NoSQL实现，1些开源的NoSQL体系，如Fackbook的Cassandra，Aapche的HBase，也得到广泛的认可，从这NoSQL项目的名字看不出甚么相同的地方：hadoop、Voldemort、Dynomite还有其他很多，但是它们有1个共同点：就是改变大家对数据库在传统意义上的理解。
1.1.4、NoSQL特点：
1、它可以处理超大量的数据。
2、它运行在便宜的PC服务器集群上。
PC集群扩充起来非常方便并且本钱很低，避免了传统商业数据库的sharding操作的复杂性和本钱。
3、它击碎了性能瓶颈。
NoSQL的支持者称，通过NoSQL架构可以省去将web或java利用和数据转成SQL格式时间，履行速度变的更快。
SQL并不是适用于所有的程序代码，对那些沉重的重复操作的数据，SQL值得花钱，但是当数据结构非常简单时，SQL可能没有太大的用途。
4、它没有过量的操作
虽然NoSQL的支持者也承认关系型数据库提供无可比拟的功能集合，而且在数据完全性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那末复杂。
5、它的支持者源于社区。
由于NoSQL项目都是开源的，因此它们缺少供应商提供的正式支持，这1点它们与大多数开源项目1样，不能不从社区中需求支持。
NoSQL发展至今，出现了好几种非关系型数据库，本书以NoSQL中目前表现最好的MongoDB来进行说明。
1.2、初始MongoDB
MongoDB是1个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系型数据库的，它支持的数据结构非常疏松，是类似于json的bjson格式，因此而已存储比较复杂的数据类型，MongoDB最大的特点是它支持查询语言非常强大，其语法有点类似于面向对象的查询语言，几近可以实现类似于关系数据库单表查询的绝大部份功能，而且还支持对数据建立索引，它是1个面向集合的、模式自由的文档性数据库。
1、面向集合(collection-Orented)
意思是数据被分组存储在数据集中，被称为1个集合(Collection)。每一个集合在数据库中都有1个唯1的标示名，并且可以包括无线数目的文档，集合的概念类似于关系型数据库里的表，不同的是它不需要定义任何模式(Schema)
2、模式自由(schema-free)
意味着对存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义，提额这么屡次无模式或模式自由，它们究竟是1个甚么概念呢？比如，下面两个记录可以存储到同1个集合里面：
{"welcome":"beijing"}
{"age":25}
3、文档型
意思是我们存储的数据是键值对的集合，键是字符串，值可以是数据类型集合里的任何类型，包括数组和文档、我们把这个数据格式称作BSON，即Binary Serialized Document Notation。
1.2.1、特点
面向集合存储，易于存储对象类型的数据
模式自由
支持动态查询
支持完全索引，包括内部对象
支持查询
支持复制和故障恢复
使用高效的2进制数据存储，包括大型对象(如视频等)
自动处理碎片，以支持云计算层次的扩大性。
支持Python、PHP、Ruby、Java、C、C#、javaScript、Perl和C++语言的驱动程序，社区中也提供了对Erlang和.net平台的驱动程序。
文件存储格式为BSON
可以通过网络访问。
1.2.2、功能
面向集合的存储：合适存储对象和JSON情势的数据。
动态查询：mongoDB支持丰富的查询表达式，查询指令使用JSON情势的标记，可轻易查询文档中内嵌的对象和数组。
完全的索引支持：包括文档内嵌对象和数据，MongoDB的查询优化器会分析查询表达式，并生成1个高效的查询计划。
查询监视：MongoDB包括1系列监视工具用于分析数据库操作的性能。
复制和自动故障转移：MongoDB数据库支持服务器之间的数据复制，支持主从模式及服务器之间的相互复制，复制的主要目标是提供冗余和自动故障转移。
高效的传统存储方式：支持2进制数据和大型对象(如照片或图片)
自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。
1.2.3、使用处合
网站数据：MongoDB非常合适实时的插入，更新与查询，并具有网站实时数据存储所需要的复制和高度伸缩性。
缓存：由于性能很高，MongoDB也合适作为信息基础实行的缓存层，在系统重启以后，由于MongoDB搭建的持久化缓存可以免下层的数据源过载。
大尺寸，低价值的数据：使用传统的关系型数据库存储1些数据时可能会比较昂贵在此之前，很多时候程序员常常会选择传统的文件进行存储。
高伸缩性的场景：MongoDB非常合适由数10或数百台服务器组成的数据库，MongoDB的线路图中已包括对MapReduce引擎的内置支持。
用于对象和JSON数据的存储：MongoDB的BSON数据格式非常合适文档化格式的存储和查询。