与关系型数据库相比，MongoDB的优点：
①弱一致性（最终一致），更能保证用户的访问速度：
②文档结构的存储方式，能够更便捷的获取数据。
③内置GridFS，支持大容量的存储。
④内置Sharding。
⑤第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)
⑥性能优越
与关系型数据库相比，MongoDB的缺点：
①mongodb不支持事务操作。
②mongodb占用空间过大。
③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。
---------------------------------------
适用场合
网站数据：MongoDB非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性
缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层
大尺寸、低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，可以考虑MongoDB
高伸缩性的场景：MongoDB非常适合由数十或数百台服务器组成的数据库
用于对象及JSON数据的存储：MongoDB的BSON数据格式非常适合文档个数的存储及查询
-------------------------------------------
体系结构
从图中可以看出，MongoDB sharding 主要分为 3 大部分。shard 节点、config 节点和 config 节点。
对客户端来说，直接访问的是 图中绿色的 mongos 节点。背后的 config 节点和 shard 节点是客户端不能直接访问的。mongos 的主要作用是数据路由。从元数据中定位数据位置，合并查询结果。另外，mongos 节点还负责数据迁移和数据自动平衡，并作为 sharding 集群的管理节点。它对外的接口就和普通的 mongod 一样。因此，可以使用标准 mongodb 客户端和驱动进行访问。mongos 节点是无状态的，本身不保存任何数据和元数据，因此可以任意水平扩展，这样任意一个节点发生故障都可以很容易的进行故障转移，不会造成严重影响。
其中蓝色的 shard 节点就是实际存放数据的数据节点。每个 shard 节点可以是单个 mongod 实例，也可以使一个 replica set 。通常在使用 sharding 的时候，都会同时使用 replica set 来实现高可用，以免集群内有单个节点出故障的时候影响服务，造成数据丢失。同时，可以进一步通过读写分离来分担负载。对于每个开启 sharding 的 db 来说，都会有一个 默认 shard 。初始时，第一个 chunk 就会在那里建立。新数据也就会先插入到那个 shard 节点中去。 图中紫色的 config 节点存储了元数据，包括数据的位置，即哪些数据位于哪些节点，以及集群配置信息。config 节点也是普通的 mongod 。如图所示，一组 config 节点由 3 个组成。这 3 个 config 节点并非是一个 replica set。它们的数据同步是由 mongos 执行两阶段提交来保证的。这样是为了避免复制延迟造成的元数据不同步。config 节点一定程度上实现了高可用。在一个或两个节点发生故障时，config 集群会变成只读。但此时，整个 sharding 集群仍然可以正常读写数据。只是无法进行数据迁移和自动均衡而已。