汇总：
1. [MongoDB]安装MongoDB2. [MongoDB]Mongo基本使用：3. [MongoDB]MongoDB的优缺点及与关系型数据库的比较4. [MongoDB]MongoDB与JAVA结合使用CRUD
参考：http://www.cnblogs.com/hoojo/archive/2011/06/01/2066119.html
介绍：MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
特点：高性能、易部署、易使用，存储数据非常方便。
主要功能特性有：
Ø 面向集合存储，易存储对象类型的数据
Ø 模式*
Ø 支持动态查询
Ø 支持完全索引，包含内部对象
Ø 支持查询
Ø 支持复制和故障恢复
Ø 使用高效的二进制数据存储，包括大型对象（如视频等）
Ø 自动处理碎片，以支持云计算层次的扩展性
Ø 支持RUBY，PYTHON，JAVA，C++，PHP等多种语言
Ø 文件存储格式为BSON（一种JSON的扩展）
Ø 可通过网络访问
使用原理
所谓"面向集合"（Collenction-Oriented），意思是数据被分组存储在数据集中，被称为一个集合（Collenction)。每个集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。
模式*（schema-free)，意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。
存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各种复杂的文件类型。我们称这种存储形式为BSON（Binary JSON）。
参考：
http://blog.sina.com.cn/s/blog_966e430001019s8v.html
与关系型数据库相比，MongoDB的优点：
①弱一致性（最终一致），更能保证用户的访问速度：
举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到"当前"情况下的精确值。这在某些情况下，例如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种"精确"的保证几乎没有任何意义，反而会产生很大的延迟。他们需要的是一个"大约"的数字以及更快的处理速度。
：
就拿一个"字典项"来说，虽然并不十分复杂，但还是会关系到"定义"、"词性"、"发音"或是"引用"等内容。大部分工程师会将这种模型使用关系型数据库中的主键和外键表现出来，但把它看作一个"文档"而不是"一系列有关系的表"岂不更好？使用 "dictionary.definition.partOfSpeech='noun'"来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便且快速。
：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客，评论与投票作为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的"JOIN"操作。
CODE↓
> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" }]
})
> db.blogposts.find( { "author.name" : "Jane" } )
> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )
个属性，而下一条记录的文档可以有10个属性，属性的类型既可以是基本的数据类型（如数字、字符串、日期等），也可以是数组或者散列，甚至还可以是一个子文档（embed document）。这样，可以实现逆规范化（denormalizing）的数据模型，提高查询的速度。
③内置GridFS，支持大容量的存储。
GridFS是一个出色的分布式文件系统，可以支持海量的数据存储。
内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。
④内置Sharding。
提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。
Shards可以和复制结合，配合Replica sets能够实现Sharding+fail-over，不同的Shard之间可以负载均衡。查询是对客户端是透明的。客户端执行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务，适当的时候可以无痛的升级。MongoDB的Sharding设计能力最大可支持约20 petabytes，足以支撑一般应用。
这可以保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了"sharding"操作的复杂性和成本。
分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。
与关系型数据库相比，MongoDB的缺点：
①mongodb不支持事务操作。
所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)
②mongodb占用空间过大。
关于其原因，在官方的FAQ中，提到有如下几个方面：
1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。
、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记"已删除"即可，以后还可以重复利用。
、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢
③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方