特点:
高性能、易部署、易使用，存储数据非常方便。主要功能特性有： 面向集合存储，易存储对象类型的数据。 模式自由。 支持动态查询。 支持完全索引，包含内部对象。 支持查询。 支持复制和故障恢复。 使用高效的二进制数据存储，包括大型对象(如视频等)。 自动处理碎片，以支持云计算层次的扩展性 支持Python，PHP，Ruby，Java，C，C#，Javascript，Perl及C 语言的驱动程序，社区中也提供了对Erlang及.NET等平台的驱动程序。 文件存储格式为BSON(一种JSON的扩展)。 可通过网络访问。 功能:
面向集合的存储：适合存储对象及JSON形式的数据。 动态查询：Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。 完整的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。 查询监视：Mongo包含一个监视工具用于分析数据库操作的性能。 复制及自动故障转移：Mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。 高效的传统存储方式：支持二进制数据及大型对象(如照片或图片) 自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。 适用场合:
网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。 缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源 过载。 大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。 高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。 用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。
知乎上有篇文章：[什么场景应该用 MongoDB ？ 很多人比较关心 MongoDB 的适用场景，也有用户在话题里分享了自己的业务场景，比如 案例1:： 用在应用服务器的日志记录，查找起来比文本灵活，导出也很方便。也是给应用练手，从外围系统开始使用MongoDB。 用在一些第三方信息的获取或者抓取，因为MongoDB的schema-less，所有格式灵活，不用为了各种格式不一样的信息专门设计统一的格式，极大的减少开发的工作。
案例2： mongodb之前有用过，主要用来存储一些监控数据，No schema 对开发人员来说，真的很方便，增加字段不用改表结构，而且学习成本极低。 案例3： 使用MongoDB做了O2O快递应用，·将送快递骑手、快递商家的信息(包含位置信息)存储在 MongoDB，然后通过 MongoDB 的地理位置查询，这样很方便的实现了查找附近的商家、骑手等功能，使得快递骑手能就近接单，目前在使用MongoDB 上没遇到啥大的问题，官网的文档比较详细，很给力。
经常跟一些同学讨论 MongoDB 业务场景时，会听到类似『你这个场景 mysql 也能解决，没必要一定用 MongoDB』的声音，的确，并没有某个业务场景必须要使用 MongoDB才能解决，但使用 MongoDB 通常能让你以更低的成本解决问题(包括学习、开发、运维等成本)，下面是 MongoDB 的主要特性，大家可以对照自己的业务需求看看，匹配的越多，用 MongoDB 就越合适。
MongoDB 特性优势 事务支持MongoDB 目前只支持单文档事务，需要复杂事务支持的场景暂时不适合灵活的文档模型JSON 格式存储最接近真实对象模型，对开发者友好，方便快速开发迭代高可用复制集满足数据高可靠、服务高可用的需求，运维简单，故障自动切换可扩展分片集群海量数据存储，服务能力水平扩展高性能mmapv1、wiredtiger、mongorocks(rocksdb)、in-memory 等多引擎支持满足各种场景需求强大的索引支持地理位置索引可用于构建 各种 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过期的需求Gridfs解决文件存储的需求aggregation & mapreduce解决数据分析场景需求，用户可以自己写查询语句或脚本，将请求都分发到 MongoDB 上完成。
从目前阿里MongoDB 云数据库上的用户看，MongoDB 的应用已经渗透到各个领域，比如游戏、物流、电商、内容管理、社交、物联网、视频直播等，以下是几个实际的应用案例。
- 游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新
- 物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
- 社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能
- 物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析
- 视频直播，使用 MongoDB 存储用户信息、礼物信息等
- ......
如果你还在为是否应该使用 MongoDB，不如来做几个选择题来辅助决策(注：以下内容改编自 MongoDB 公司 TJ 同学的某次公开技术分享)。
应用特征Yes / No应用不需要事务及复杂 join 支持必须 Yes新应用，需求会变，数据模型无法确定，想快速迭代开发？应用需要2000-3000以上的读写QPS(更高也可以)？应用需要TB甚至 PB 级别数据存储?应用发展迅速，需要能快速水平扩展?应用要求存储的数据不丢失?应用需要99.999%高可用?应用需要大量的地理位置查询、文本查询？
如果上述有1个 Yes，可以考虑 MongoDB，2个及以上的 Yes，选择MongoDB绝不会后悔。
