MongoDB简介摘录

MongoDB 是一个文档数据库，旨在简化开发和扩展。

MongoDB 提供了 Community 和 Enterprise 版本的数据库：

MongoDB 社区是可免费使用版本。

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

非关系型数据库就是NoSQL数据库，全称是Not Only SQL。

常见的关系型数据库如mysql、oracle、SqlServer等，

常见的非关系型数据库如MongoDB、Redis、Cassandra(Facebook用的)、HBase(谷歌)、Neo4j、Oracle NoSQL、Amazon DynamoDB等。

非关系型数据库的优点：简单高速，对于一些简单的微服务分布式应用，MongoDB+Redis完全够用了，非常轻量级，没有关系型数据库那么多的条条框框。

非关系型数据库的缺点：非关系型当然就是最好表与表之间最好不要有太多关系，牺牲点冗余没关系，但当系统越来越复杂，表越来越多，表之间关联查询越来越多时可能处理起来就会变得麻烦，这时你就会怀念起关系型数据库的好处。所以可能对一些大型分布式应用来说，可能就是mysql+MongoDB+Redis结合一起来使用。

为什么叫Not Only SQL：

无它，因为关系型数据库（以 SQL 为符号象征）一统天下势力强大，在这种形式下怎样推广新的数据库技术呢？

如果Redis 叫自己数据结构数据库，MongoDB 叫自己基于文档的数据库，Cassendra 叫自己基于列的数据库。这样谁也记不住它们。

所以为了反sql，所以统一叫NoSQL，水滴石穿，团结力量大。

非关系型数据库以MongoDB为例子说明下其优缺点：

1.不使用SQL作为查询语言，查询语句有自己的语法规则，支持丰富的查询表达式，虽然是非关系型数据库，但也支持关联其他表联合查询。那能不能像plsql那样写脚本文件去执行，比如查询数据循环修改之类的？当然可以，MongoDB是支持js语句的，所以js那些语法、内置函数等都可以使用。

2.不用写建表语句。保存数据时直接保存就好，如果发现表(其实就是文档)不存在MongoDB会自动创建。

3.字段也不用建，有多少字段就会自动保存多少字段，而且可以每行保存不同的字段，说到底就是可以恣意妄为想怎么保存就怎么保存，于是有人会问，字段越来越多会不会造成造成空间占用越来越大？完全不会，因为每行都是独立保存的，没有的字段不会存储，而不像关系型数据库每行存储的字段都一样有时候为了方便扩展还建了一堆备用字段造成字段冗余。所以MongoDB特别适合表结构变化较为频繁，数据量特别大，数据的并发性特别高，数据结构比较特别(例如地图的位置坐标)的情况。

4.自带了一个名叫 GirdFS 的分布式文件系统，这就为 MongoDB 的部署提供了很大便利。而像 MySQL 这种比较早的数据库，虽然市面上有很多不同的分表部署的方案，但这种终究不如 MongoDB 直接官方支持来得便捷实在。

1. MongoDB 在启动后会将数据库中的数据以文件映射的方式加载到内存中。mongo为了优化他的读写效率，将内存当做缓存，如果内存资源相当丰富的话，这将极大地提高数据库的查询速度，毕竟内存的 I/O 效率比磁盘高多了。

所以它性能优越:快速！在适量级的内存的 MongoDB 的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。

6.弱一致性(最终一致)，更能保证用户的访问速度。

了解下它的持久化方式就理解了：

MongoDB 的所有数据实际上是存放在硬盘的，所有要操作的数据通过 mmap 的方式映射到内存某个区域内。

然后，MongoDB 就在这块区域里面进行数据修改，避免了零碎的硬盘操作。

至于 mmap上的内容flush到硬盘就是操作系统的事情了，所以，如果，MongoDB 在内存中修改了数据后，mmap 数据flush到硬盘之前，系统宕机了，数据就会丢失。

7.MongoDB 允许在服务端创建函数。就像oracle可以创建存储过程、函数那样，MongoDB支持用 Javascript 编写某个函数，直接在服务端执行，也可以把函数的定义存储在服务端，下次直接调用即可。MongoDB说：对吧，我功能并不比oracle差。

8.MongoDB 以 BSON 结构(二进制)进行存储，对海量数据存储有着很明显的优势。还有JSON 格式存储最接近真实对象模型，对开发者友好，方便快速开发迭代。

9.强大的索引支持: 地理位置索引可用于构建 各种 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过期的需求

10.架构特点：可以通过副本集，以及分片来实现高可用，运维简单，故障自动切换。

11.千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数 据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。

12.不存在sql注入，4.2版本后关闭了执行js的方法后再也没办法搞了。

缺点：

1.MongoDB 目前只支持单文档事务，需要复杂事务支持的场景暂时不适合。

2.其他一些缺点感觉就是挠痒痒比如单机可靠性比较差、大数据量持续插入入性能有较大波动、磁盘空间占用比较大。

适合场景：事件的记录，内容管理或者博客平台等等。作为最为接近关系型数据库，比较完善的 DB 之一，适用人群不断在增长。

从目前阿里云 MongoDB 云数据库上的用户看，MongoDB 的应用已经渗透到各个领域，比如游戏、物流、电商、内容管理、社交、物联网、视频直播等，以下是几个实际的应用案例。

游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新。

物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。

社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能。

物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析

视频直播，使用 MongoDB 存储用户信息、礼物信息等

……

如果你还在为是否应该使用 MongoDB，不如来做几个选择题来辅助决策（注：以下内容改编自 MongoDB 公司 TJ 同学的某次公开技术分享）。

·应用不需要事务及复杂 join 支持

·新应用，需求会变，数据模型无法确定，想快速迭代开发

·应用需要2000-3000以上的读写QPS（更高也可以）

·应用需要TB甚至 PB 级别数据存储

·应用发展迅速，需要能快速水平扩展

·应用要求存储的数据不丢失

·应用需要99.999%高可用

·应用需要大量的地理位置查询、文本查询

如果上述有1个符合，可以考虑 MongoDB，2个及以上的符合，选择 MogoDB 绝不会后悔。

总体上讲：

由于MongoDB独特的数据处理方式，可以将热点数据加载到内存，故而对查询来讲，会非常快（当然也会非常消耗内存）；同时由于采用了BSON的方式存储数据，故而对JSON格式数据具有非常好的支持性以及友好的表结构修改性，文档式的存储方式，数据友好可见；数据库的分片集群负载具有非常好的扩展性以及非常不错的自动故障转移（大赞）。

不足：数据库的查询采用了特有的查询方式，有一定的学习成本（不高）；锁只能提供到collection级别，还做不到行级锁；没有事务机制（不能回滚啊）；学习资料肯定没有MySQL的多。