mongodb的优缺点及应用场景,谈谈mongodb，mysql的区别和具体应用场景

mongodb的优缺点及应用场景,谈谈mongodb，mysql的区别和具体应用场景详细介绍

本文目录一览： mongodb使用场景是什么？

使用场景：
（1）网站数据：MongoDB适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
（2）缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。
（3）大尺寸，低价值的数据。
（4）高伸缩性的场景：MongoDB适合由数十或数百台服务器组成的数据库。
（5）用于对象及JSON数据的存储：MongoDB的BSON数据格式适合文档化格式的存储及查询。
功能
1、面向集合的存储：适合存储对象及JSON形式的数据。
2、动态查询：MongoDB支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
3、完整的索引支持：包括文档内嵌对象及数组。MongoDB的查询优化器会分析查询表达式，并生成一个高效的查询计划。
4、查询监视：MongoDB包含一系列监视工具用于分析数据库操作的性能。
5、复制及自动故障转移：MongoDB数据库支持服务器之间的数据复制，支持主－从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。
6、高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。
7、自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器
使用场景：
（1）网站数据：MongoDB适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
（2）缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。
（3）大尺寸，低价值的数据。
（4）高伸缩性的场景：MongoDB适合由数十或数百台服务器组成的数据库。
（5）用于对象及JSON数据的存储：MongoDB的BSON数据格式适合文档化格式的存储及查询。
mongodb设计特点：
（1）面向集合存储，容易存储对象类型的数据。在MongoDB 中数据被分组存储在集合中，集合类似RDBMS 中的表，一个集合中可以存储无限多的文档。
（2）模式自由，采用无模式结构存储。在MongoDB 中集合中存储的数据是无模式的文档，采用无模式存储数据是集合区别于RDBMS 中的表的一个重要特征。
（3）支持完全索引，可以在任意属性上建立索引，包含内部对象。MongoDB的索引和RDBMS 的索引基本一样，可以在指定属性、内部对象上创建索引以提高查询的速度。除此之外，MongoDB 还提供创建基于地理空间的索引的能力。
（4）支持查询。MongoDB 支持丰富的查询操作，MongoDB 几乎支持SQL中的大部分查询。
（5）强大的聚合工具。MongoDB 除了提供丰富的查询功能外，还提供强大的聚合工具，如count、group 等，支持使用MapReduce 完成复杂的聚合任务。

谈谈mongodb，mysql的区别和具体应用场景

谈谈mongodb，mysql的区别和具体应用场景
个是关系型数据库一个是非关系型数据库,各自有不同的特点应用在不同的场景和需求下,建议先多了解二者的区别,自然明白各自使用
（1）mysql数据库：
属于关系型数据库。
在不同的引擎上有不同的存储方式。
查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。
开源数据库的份额在不断增加，mysql的份额页在持续增长。
缺点就是在海量数据处理的时候效率会显著变慢。
（2）mongodb数据库：
非关系型数据库(nosql
),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性（self-describing），呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。
存储方式：虚拟内存+持久化。
查询语句：是独特的mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
成熟度与广泛度：新兴数据库，成熟度较低，nosql数据库中最为接近关系型数据库，比较完善的db之一，适用人群不断在增长。
分析一下mysql和mongodb应用场景
1.如果需要将mongodb作为后端db来代替mysql使用，即这里mysql与mongodb
属于平行级别，那么，这样的使用可能有以下几种情况的考量：
(1)mongodb所负责部分以文档形式存储，能够有较好的代码亲和性，json格式的直接写入方便。(如日志之类)
(2)从data
models设计阶段就将原子性考虑于其中，无需事务之类的辅助。开发用如nodejs之类的语言来进行开发，对开发比较方便。
(3)mongodb本身的failover机制，无需使用如mha之类的方式实现。
2.将mongodb作为类似redis
，memcache来做缓存db，为mysql提供服务，或是后端日志收集分析。
考虑到mongodb属于nosql型数据库，sql语句与数据结构不如mysql那么亲和
，也会有很多时候将mongodb做为辅助mysql而使用的类redis
memcache
之类的缓存db来使用。
亦或是仅作日志收集分析。

对比MySQL，你究竟在什么时候更需要MongoDB(转载)

默认情况下，对比事务安全，MongoDB更关注高的插入速度。如果你需要加载大量低价值的业务数据，那么MongoDB将很适合你的用例。但是必须避免在要求高事务安全的情景下使用MongoDB，比如一个1000万美元的交易。 不可靠环境保证高可用性 设置副本集（主-从服务器设置）不仅方便而且很快，此外，使用MongoDB还可以快速、安全及自动化的实现节点（或数据中心）故障转移。 未来会有一个很大的规模 数据库扩展是非常有挑战性的，当单表格大小达到5-10GB时，MySQL表格性能会毫无疑问的降低。如果你需要分片并且分割你的数据库，MongoDB将很容易实现这一点。 使用基于位置的数据查询 MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。 非结构化数据的爆发增长 给RDBMS增加列在有些情况下可能锁定整个数据库，或者增加负载从而导致性能下降，这个问题通常发生在表格大于1GB（更是下文提到BillRun系统中的痛点——单表格动辄几GB）的情况下。鉴于MongoDB的弱数据结构模式，添加1个新字段不会对旧表格有任何影响，整个过程会非常快速；因此，在应用程序发生改变时，你不需要专门的1个DBA去修改数据库模式。 缺少专业的数据库管理员 如果你没有专业的DBA，同时你也不需要结构化你的数据及做join查询，MongoDB将会是你的首选。MongoDB非常适合类的持久化，类可以被序列化成JSON并储存在MongoDB。需要注意的是，如果期望获得一个更大的规模，你必须要了解一些最佳实践来避免走入误区。 个人理解：如果说写负载和单表太大，解决方案都是通过分片来实现横向扩展，其实mysql也是支持的。这不算理由。我能使用Mongodb的场景是：你不需要太多的事务和多表关联，那么使用Mongodb可以获得更大的性能提升。或者schema-free的使用场景。对比MySQL，你究竟在什么时候更需要MongoDB(转载)标签：多表关联strong系统表关联理解表格没有实现json

为什么MongoDB适合大数据的存储

Mongo是一个高性能，开源，无模式的文档型数据库，它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。Mongo使用C++开发，提供了以下功能：
◆面向集合的存储：适合存储对象及JSON形式的数据。
◆动态查询：Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
◆完整的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。
◆查询监视：Mongo包含一个监视工具用于分析数据库操作的性能。
◆复制及自动故障转移：Mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。
◆高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。
◆自动分片以支持云级别的伸缩性（处于早期alpha阶段）：自动分片功能支持水平的数据库集群，可动态添加额外的机器。
MongoDB的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。根据官方网站的描述，Mongo适合用于以下场景：
◆网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
◆缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
◆大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
◆高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
◆用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。
自然，MongoDB的使用也会有一些限制，例如它不适合：
◆高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
◆传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
◆需要SQL的问题
MongoDB支持OS X、Linux及Windows等操作系统，并提供了Python，PHP，Ruby，Java及C++语言的驱动程序，社区中也提供了对Erlang及.NET等平台的驱动程序。

mongodb和mysql5.7的json哪个更好，优缺点比较

与关系型数据库相比，MongoDB的优点：
①弱一致性（最终一致），更能保证用户的访问速度：
举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的精确值。这在某些情况下，例 如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延 迟。他们需要的是一个“大约”的数字以及更快的处理速度。
但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：
每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。
使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。
②文档结构的存储方式，能够更便捷的获取数据。
对于一个层级式的数据结构来说，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难。
举例1：
就拿一个“字典项”来说，虽然并不十分复杂，但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库 中的主键和外键表现出来，但把它看作一个“文档”而不是“一系列有关系的表”岂不更好？使用 “dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便 且快速。
举例2：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客， 评论与投票作为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操作。
CODE↓
> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" }]
})
> db.blogposts.find( { "author.name" : "Jane" } )
> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",
comments : [{ by: "Abe", text: "First" },
{ by : "Ada", text : "Good post" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )
> db.blogposts.ensureIndex( { "comments.by" : 1 } );
举例③：
MongoDB是一个面向文档的数据库，目前由10gen开发并维护，它的功能丰富，齐全，完全可以替代MySQL。在使用MongoDB做产品原型的过程中，我们总结了MonogDB的一些亮点：
使用JSON风格语法，易于掌握和理解：MongoDB使用JSON的变种BSON作为内部存储的格式和语法。针对MongoDB的操作都使用JSON风格语法，客户端提交或接收的数据都使用JSON形式来展现。相对于SQL来说，更加直观，容易理解和掌握。
Schema-less，支持嵌入子文档：MongoDB是一个Schema-free的文档数据库。一个数据库可以有多个Collection，每 个Collection是Documents的集合。Collection和Document和传统数据库的Table和Row并不对等。无需事先定义 Collection，随时可以创建。
Collection中可以包含具有不同schema的文档记录。 这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档可以有10个属 性，属性的类型既可以是基本的数据类型（如数字、字符串、日期等），也可以是数组或者散列，甚至还可以是一个子文档（embed document）。这 样，可以实现逆规范化（denormalizing）的数据模型，提高查询的速度。
③内置GridFS，支持大容量的存储。
GridFS是一个出色的分布式文件系统，可以支持海量的数据存储。
内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。
④内置Sharding。
提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。
Shards可以和复制结合，配合Replica sets能够实现Sharding+fail-over，不同的Shard之间可以负载均衡。查询是对 客户端是透明的。客户端执行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务，适当的 时候可以无痛的升级。MongoDB的Sharding设计能力最大可支持约20 petabytes，足以支撑一般应用。
这可以保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。
⑤第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)
现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。
而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。
而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。不少知名大公司和网站也在生产环境中使用MongoDB，越来越多的创新型企业转而使用MongoDB作为和Django，RoR来搭配的技术方案。
⑥性能优越：
在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数 据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。
与关系型数据库相比，MongoDB的缺点：
①mongodb不支持事务操作。
所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)
②mongodb占用空间过大。
关于其原因，在官方的FAQ中，提到有如下几个方面：
1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长 了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。
3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

请问使用mongodb数据库有哪些优势？

　　MongoDB的优势还有哪些？
无论是消费群体还是企业用户，针对目前大多数Web应用，MongoDB都能够轻松地对实体进行建模，以下这些场景都有MongoDB的用武之地：
●账户和用户资料
●CMS
●表格数据处理
●用户生成的内容系统
●消息系统
●系统设置
●任何形式的日志数据系统
●图形数据系统
●基于地理位置的数据系统
数据即接口
数据结构能体现开发者的程序和构想，所以我们始终在寻找方法，让数据结构更有表达力，从而更好地进行应用的建模。
所以回到MongoDB为何流行的话题上，并不是它的扩展性有多好，而是因为数据结构。同其他的NoSQL数据库技术相比，MongoDB的扩展性并不是最出色的，但是它在数据结构上的创新，能够让我们更加轻松地、更直观地对事物进行建模，这对于应用是最重要的 ,也是MongoDB流行的真正原因。像MongoDB这样的数据库，在未来将成为操作型数据存储的主要数据库范式，而关系型数据库将起到专用工具的作用。
对于大多数用例，在代码和数据库中使用相同的基础数据模型是具有重要意义的，因为它能够极大地简化应用开发的过程，并消除复杂的映射层。因此一个基于JSON的文档数据库，如MongoDB将是也将是未来数据库技术创新的出发点。
下面是一个瑭锦TANJURD总结 MongoDB 优缺点的列表，希望对打算使用 MongoDB 的同学，能有一些作用：
优势：
快速!(当然，这和具体的应用方式有关，通常来说，它比一般的关系型数据库快5位左右。)
很高的可扩展性 – 轻轻松松就可实现PB级的存储(但是可能我们并不需要PB级的存储，10TB可能就够了)
他有一个很好的 replication 模式 (replica sets)
有很完善的Java API
他的存储格式是Json的，这对Java来说非常好处理，对javascirpt亦然。
运维起来非常方便，你不用专门为它安排一个管理员。
它有一个非常活跃的社区(我提出的一个bug在20分钟内就能得到修复。多谢Elliot)
他的版本控制非常清楚。
MongoDB 背后的公司(10gen)已经准备好了明天在 MongoDB 上面的投入的资金了。
劣势
应用经验缺乏，我们都没有相关NoSQL 产品的使用经验。
项目相对来说还比较新。
和以往的存储相比，数据的关系性操作不再存在。

redis 和 mongodb 比起来优缺点是什么？

一、优点：
1、支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）
2、支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。
3、支持通过Replication进行数据复制，通过master-slave机制，可以实时进行数据的同步复制，支持多级复制和增量复制，master-slave机制是Redis进行HA的重要手段。
二、缺点：
1、Redis只能使用单线程，性能受限于CPU性能，故单实例CPU最高才可能达到5-6wQPS每秒（取决于数据结构，数据大小以及服务器硬件性能，日常环境中QPS高峰大约在1-2w左右）。
2、支持简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。
3、Redis在string类型上会消耗较多内存，可以使用dict（hash表）压缩存储以降低内存耗用。
扩展资料：
redis使用注意事项：
1、注意垃圾回收：Redis是一个提供持久化功能的内存数据库，如果不指定上面值的过期时间，并且也不进行定期的清理工作，那么Redis内存占用会越来越大，当有一天超过了系统可用内存，那么swap上场，离性能陡降的时间就不远了。
2、使用key值前缀来作命名空间：虽然说Redis支持多个数据库（默认32个，可以配置更多），但是除了默认的0号库以外，其它的都需要通过一个额外请求才能使用。所以用前缀作为命名空间可能会更明智一点。
3、Redis并不支持Sharding，但是当数据量超过单机内存时，不得不考虑Sharding的事（注意Slave不是用来做Sharding操作的，只是数据的一个备份和读写分离而已）。
参考资料来源：百度百科-Redis
参考资料来源：百度百科-mongodb

mysql mongodb区别

前言：
MySQL与MongoDB都是开源的常用数据库，但是MySQL是传统的关系型数据库，MongoDB则是非关系型数据库，也叫文档型数据库，是一种NoSQL的数据库。它们各有各的优点，关键是看用在什么地方。所以我们所熟知的那些SQL语句就不适用于MongoDB了，因为SQL语句是关系型数据库的标准语言。
一、关系型数据库-MySQL
1、在不同的引擎上有不同的存储方式。
2、查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。
3、开源数据库的份额在不断增加，mysql的份额页在持续增长。
4、缺点就是在海量数据处理的时候效率会显著变慢。
二、非关系型数据库-MongoDB
非关系型数据库(nosql ),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性，呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。
1、存储方式：虚拟内存+持久化。
2、查询语句：是独特的MongoDB的查询方式。
3、适合场景：事件的记录，内容管理或者博客平台等等。
4、架构特点：可以通过副本集，以及分片来实现高可用。
5、数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
6、成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。
三、MongoDB优势与劣势
优势：
1、在适量级的内存的MongoDB的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。
2、MongoDB的高可用和集群架构拥有十分高的扩展性。
3、在副本集中，当主库遇到问题，无法继续提供服务的时候，副本集将选举一个新的主库继续提供服务。
4、MongoDB的Bson和JSon格式的数据十分适合文档格式的存储与查询。
劣势：
1、 不支持事务操作。MongoDB本身没有自带事务机制，若需要在MongoDB中实现事务机制，需通过一个额外的表，从逻辑上自行实现事务。
2、 应用经验少，由于NoSQL兴起时间短，应用经验相比关系型数据库较少。
3、MongoDB占用空间过大。

mongodb数据库有哪些优势

1. 文档存储
数据存储以BSON/JSON文档，这对于Web应用程序有很大的意义。开发者API喜欢以JSON形式传输，这使得整个项目的数据表示可采用统一的模型。所有这一切都无需任何前期架构设计。
2. 可扩展性
MongoDB被用在一些规模庞大的环境中，FourSquare/Craiglist都在使用它。通过分片数据缩放处理理论上可实现更高的吞吐量。
3. 简单的复制
就像分片技术一样，MongoDB范围内复制过程同样简单好用，在副本机器上还有大量的复制选项。灵活的功能可满足用户应用的需求。
4. 易于查询
MongoDB以文档的形式存储数据，不支持事务和表连接。因此查询的编写、理解和优化都容易得多。简单查询设计思路不同于SQL模式，嵌入文档在特定的环境下可得到更好的查询，然而这需要先加入集合。如果需要执行多个请求到数据库则需要加入其到客户端。在MongoDB时ODM工具（如Doctrine2）将发挥自身的优势。
5. 安全性
由于MongoDB客户端生成的查询为BSON对象，而不是可以被解析的字符串，所以可降低受到SQL注入的攻击的危险。最常见的攻击类型为针对Web应用程序的攻击，在MongoDB上使用Doctrine2 ODMs 查询语言可减轻攻击风险。
6. 支持
用户在选择数据库时总是喜欢积极和充满活力的，这点非常重要。MongoDB在业界有非常大的影响力，用户也会定期的组织活动。MongoDB的标签在StackOverFlow是非常活跃的。你永远不会陷入困境，因为总有人与你讨论并解决问题。
7. 价格
MongoDB是免费的！
当然远不止这些优势，但是也有很多劣势。