共计 2429 个字符，预计需要花费 7 分钟才能阅读完成。
前言: MongoDB 最流行的现代数据库, 内存级的读写.MongoDB 这个来源英文单词“humongous”，homongous 这个单词的意思是“巨大的”、“奇大无比的”，从 MongoDB 单词本身可以看出它的目标是提供海量数据的存储以及管理能力。
什么是 MongoDB
MongoDB 是由 MongoDB，Inc。开发的非关系数据库.MongoDB 将数据作为文档存储在名为 BSON（二进制 JSON）的二进制表示中。相关信息存储在一起，以便通过 MongoDB 查询语言进行快速查询访问。字段因文档而异; 没有必要向系统声明文档结构 – 文档是自我描述的。如果需要将新字段添加到文档中，则可以在不影响集合中的所有其他文档的情况下创建该字段，而无需更新中央系统目录，也不会使系统脱机。（可选）模式验证可用于对每个集合强制执行数据治理控制。
MongoDB 的文档数据模型自然地映射到应用程序代码中的对象，使开发人员可以轻松学习和使用。文档使您能够轻松地表示层次关系以存储数组和其他更复杂的结构。
我们为什么要使用 mongoDB
因为它使他们能够更快地构建应用程序，处理高度多样化的数据类型，并大规模地管理应用程序。
由于 MongoDB 文档自然地映射到现代的面向对象编程语言，因此简化了开发。使用 MongoDB 删除了复杂的对象关系映射（ORM）层，该层将代码中的对象转换为关系表。MongoDB 灵活的数据模型还意味着数据库模型可以随业务需求而发展。
MongoDB 还可以在多个分布式数据中心内和跨多个分布式数据中心进行扩展，从而提供以前无法通过 MySQL 等关系数据库实现的新级别的可用性和可伸缩性。随着您的部署在数据量和吞吐量方面的增长，MongoDB 可以轻松扩展，无需停机，也无需更改应用程序。相比之下，使用 MySQL 实现扩展通常需要大量的定制工程工作。
1. 存储方式
MongoDB 它在数据存储的形态上和 MySQL 之类关系数据库有本质区别,MongoDB 存储的基本对象是 Document, 所以我们把它称为一种文档数据库. 而文档的集合是 Collection. 与 SQL 的概念类比,Collection 对应于 Table 而 Document 对应于 Row.Document 使用一种 BSON(Binary JSON) 结构来表达, 类似 JSON 的结构.
Document 在内部是如何存储的？每个 Document 被保存在一个 Record 中。Record 相当于 MongoDB 内部分配的一块空间，除了保存 Document 的内容可能还会预留一些填充的额外空间。对于写入后的 Document 如果还会更新，可能导致 Document 长度增加，就可以利用上额外的填充空间来。若业务对于写入后的 Document 不会再更新或删除（像监控日志、流水记录等），可以指定无填充的 Record 分配策略，更节省空间。
2. 效率
Mongo 的存储方式为虚拟内存 + 持久化存储，Mongo 将数据写入内存中，再由虚拟内存管理器将其持久化到硬盘中，因此写操作会比关系型数据库快很多. 而且 MongoDB 允许在服务端执行脚本，可以用 Javascript 编写某个函数，直接在服务端执行，也可以把函数的定义存储在服务端，下次直接调用即可。
3. 高扩展
mongoDB 存储的数据不需要具体的格式, 它非常容易扩展, 在使用 Mysql 开发时, 最初设计 table 是让人头疼的, 为了考虑到以后的扩展, 不得不在 table 的后面预留一些 Row, 让人恶心是吧. 但是 mongoDB 文档数据库的特点就是想存什么存什么, 后期想添加数据也就是一行代码的事, 给了我们极大的自由, 当然自由肯定也是有后果的, 后面会说.
4. 内置 Sharding
分片 (Sharding) 帮助扩展, 加速查询响应的时间, 减少宕机的影响
缺点
1. 占空间
MongoDB 有一个最大的缺点，就是它占用的空间很大，因为它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，在 MongoDB 中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果，一个是索引会出现性能问题。
2. MongoDB 对数据间的事务关系支持比较弱
mongoDB 在 4.0 版本之后也支持 ACID,MongoDB 将在 4.2 里推出分片集群的多文档事务支持。随着事务支持的增加，MongoDB 功能上更接近于关系型数据库，但是和关系型还是有本质上的区别：关系数据库是基于关系模型的，其固定化的数据模型严格死板，对新一代应用迭代式开发支持不好，对各种数据多变的场景如物联网或社交化都无法支持的很好。MongoDB 的 JSON 模型则具有动态灵活，数据库无须下线就可以进行模式变迁升级，特别适用于敏捷式的开发环境。
MongoDB 的应用场景
数据不是特别重要（例如通知，推送这些），数据表结构变化较为频繁，数据量特别大，数据的并发性特别高，数据结构比较特别（例如地图的位置坐标），这些情况下用 MongoDB，其他情况就还是用 MySQL，这样组合使用就可以达到最大的效率。
从目前阿里云 MongoDB 云数据库上的用户看，MongoDB 的应用已经渗透到各个领域，比如游戏、物流、电商、内容管理、社交、物联网、视频直播等，以下是几个实际的应用案例。
- 游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新
- 物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
- 社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能
- 物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析
- 视频直播，使用 MongoDB 存储用户信息、礼物信息等
……
