MongoDB是应用最为广泛的文档数据库，也是目前最热门的NoSQL数据库之一。 mongoDB由C++语言编写，旨在提供可扩展的高性能数据存储解决方案。MongoDB的定位是介于关系型数据库和key value数据库之间的数据库产品。也就是说，MongoDB的目标是既能够像关系型数据库那样提供较复杂的查询操作，又能够像key value数据库那样保持高性能和可扩展性的特点。
以BSON格式存储文档
MongoDB以BSON格式存储数据(文档)，BSON是Binary JSON的缩写，是一种类JSON的二进制存储格式。和JSON一样，BSON也支持内嵌文档对象和数组对象。MongoDB的操作都使用JSON风格语法，客户端提交和接收的数据都使用JSON形式来展现，较SQL更加直观，容易理解和掌握。
消除对象关系映射(ORM)
面向对象开发方式是当今企业级应用开发环境中的主流开发方法，开发者通常以对象的方式对业务实体进行建模，而关系型数据库中的数据以关系模型进行存储，所以开发者需要在对象——关系——对象之间来回变换。每个面向对象编程语言中都会有ORM工具，然而，即使使用工具，ORM仍然非常耗时。借助于BSON，MongoDB可以以面向对象的方式存储和管理数据，这使得应用代码层和数据库层在数据模型上保持一致，从而消除了复杂的
ORM(Object Relation Mapping)层。
Flexible Schema
作为一个文档数据库，MongDB的最小数据存储单位是文档，一个文档相当于关系型数据库中的一行记录。多个文档组成一个集合(Collection)，一个Collection相当于关系型数据库中的一张表。但是，Collection和表有很大的不同，MongoDB中的Collection没有固定的结构，也就是说，同一Collection的文档包含的字段个数、字段名、字段的数据类型都可以不同。而且，每个文档包含的字段可以动态地添加和删除，不会影响同一collection的其他文档。实际应用中，通常会把同类文档存放在一个Collection中，同一Collection中的文档一般具有类似的结构，但这不是必需的。Flexible Schema特性使得数据模式的改变和扩展变得非常容易，不需要像关系型数据库中那样用“alter table”语言改变整张表的结构。
最终一致性，提高访问性能
在传统关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的准确值。在某些应用场景，如ATM查账和火车票预订，这种“高精确性”是必须保证的。然而，在很多web应用中，比如我要查看对某件电子产品的评价，这种“高精确性”是没有意义的，反而会产生很大的延迟。相对于精确性，这些web应用更看重访问性能。MongoDB保证数据的最终一致性，数据最终一致，但无需时时一致，容许数据一定时间上的不一致，从而提高系统性能。
丰富、高效的查询功能
MongoDB是NoSQL数据库当做查询功能最丰富的， MongoDB不支持SQL，其自身的查询语言非常强大，语法有点类似面向对象的语言，几乎可以实现类似关系型数据库单表查询的绝大部分功能，并支持索引。对有索引的字段进行查询并不比关系型数据库(如mySQL)慢，而对非索引字段的查询则胜于关系型数据库。
不支持JOIN
MongoDB不支持JOIN操作，如果想在多个Collection中检索数据，那就必须做多次查询，然后在客户端完成连接。MongoDB支持复杂的数据结构(文档)，设计数据模型时可以轻易地对数据进行De-Normalize，这样可以避免对多个Collection的查询，同时让数据库中的数据模型和应用程序中的对象更加一致。当然，这必然会增加数据冗余，可以看做是数据冗余和开发简易性之间的tradeoff.
数据持久化
MongoDB的持久化是通过内存映射（
MMAP）方式实现的，MongoDB的所有数据文件都是通过内存映射方式进行操作的。其实，这里MongDB是偷懒了，它将缓存工作交给操作系统处理。所以，MongDB的持久化是通过对内存映射的数据文件执行fsync来保证的。fsync操作将内存中有变更的数据写到对应的磁盘文件上。MongDB可以指定某一时间间隔(默认60秒)调用fsync，也可以手动强制进行fsync操作。每次写操作可以单独设置数据持久化级别。
Jornaling日志功能
仅使用MMAP进行持久化存在一个问题：在两次fsync之间，如果系统停机，那么这段时间内的修改就丢失了。而且如果停机发生在fsync进行时，可能会出现一部分数据更新了，而另一部分没有更新的情况。为了解决这个问题，MongoDB从2.0版本开始提供Journaling日志功能(默认开启)。Jornaling通过预写式的Redo日志为MongoDB增加额外的可靠性。数据库的数据变更操作会首先写入Journaling日志，定期集中提交(目前是每100ms)。如果数据库意外停机，系统重启时会通过重演Journaling日志恢复MongoDB的一致状态。一次成功fsync之后，现有的journaling日志就没有用了，所以MongoDB每次正常停机都会清空Journaling日志，因为正常停机会进行一次完整的fsync操作，将数据文件同步到磁盘上。 Journaling增强了MongoDB的安全性，当然，它会轻微影响性能。
应用场景
适用：
1. 日志。企业环境下，每个应用程序都有不同的日志信息，MongoDB适合用于存储不同结构的日志信息。
2. 复杂分析。MongoDB的Flexible Schema特性使其可以存储实体的不同特征，且可以添加新的特征，而不需要修改模式。
不适用：
MongoDB不支持事务特性，所以对事务要求严格的系统都不适合适用MongoDB，如银行系统、购票系统等；
部署MongoDB的企业/产品有：淘宝、大众点评、盛大、SAP(ECM of PaaS)、Github、SourceForge.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
