前端之家收集整理的这篇文章主要介绍了
NoSQL数据库学习笔记之 初识MongoDB，
前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。
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)慢，而对非索引字段的查询则胜于关系型数据库。
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.
原文链接：https://www.f2er.com/nosql/204323.html
