对于使用MongoDB的新人来说，它是一个NoSQL的文档数据库。 文档包括一组键值对并且是MongoDB中的基本数据单元。
它绝对是现在最受欢迎的nosql数据库之一。 它广泛接受并适合各种用途（尽管不是全部）。
在这篇文章中，我想简要介绍一下我过去几年因使用MongoDB的经验而总结的它好的地方、不好之处及拙劣的地方。
好的地方
以下是关于MongoDB的一些好的东西。
灵活的数据模型
在今天动态的用例和每一个变化中的应用程序中，拥有灵活的数据模型是一个福音。灵活的数据模型意味着没有预定义的模式，并且文档可以基于任何键保存任何值集合。
表达式查询语法
MongoDB的查询语言非常有表现力，易于理解。很多人会说它不像SQL。但是我们为什么需要拘于SQL？我们需要更进一步设计更具表现力和简单的查询语言。
易于学习
MongoDB易于快速学习和入门。基本的安装，设置和执行将不会超过几个小时。更强大的设置可能很复杂，但稍后我会再讨论一下。
您应该可以在项目中轻松使用MongoDB数据库。
性能
查询性能是MongoDB的强项之一。它将大部分可工作的数据存储在RAM中。所有数据都保留在硬盘中，但在查询期间，它不会从硬盘中获取数据。它相当于从本地RAM获取，因此能够提供更快的速度。在这里，重要的是要有正确的索引和足够大的RAM来从MongoDB的性能中获益。
可扩展的和可靠的
MongoDB可使用分片进行高度扩展。在nosql数据库中，水平可扩展是一个很大的加分。 MongoDB也不例外。
由于其副本集并且在更多节点中异步复制数据，因此也是高度可靠的。
异步的驱动程序
使用Async驱动程序的非阻塞IO对于为速度而构建的所有现代应用程序至关重要。 MongoDB具有大多数流行语言的异步驱动程序支持。
文档
拥有良好的文档可以使开发人员的生活变得更加轻松，特别是当此技术对开发人员而言是新技术时。
文本搜索
如果您正在建立一个需要在所有数据中搜索的网站，文本搜索是至关重要的。例如，具有文本搜索启用数据库的电子商务网站对用户来说可以更有利可图。
服务端脚本
如果您需要在服务器端执行某些操作，而不是在应用程序中执行这些操作，则可以在MongoDB中执行此操作。将您的mongo语句列表放在.js文件中，然后执行mongo yourFile.js
文档=对象
有一个文档数据库的好处是，您的对象可以直接作为单个文档存储在MongoDB中。这里不需要ORM。
不好之处
我们看了MongoDB的好的一面。但以下几件却是它不好的地方。我相信批评者对这部分更感兴趣。如果我们在错误的用例中使用它，那么MongoDB可能是邪恶的。
事务
现在很少应用程序需要事务。但是有一些应用程序仍然需要它。不幸的是MongoDB不支持事务。因此，如果您需要为每个用户请求更新多个文档或集合，请勿使用MongoDB。它可能导致数据损坏，因为没有ACID保证。回滚必须由您的应用程序处理。
没有触发器
在RDBMS中，我们有很多触发器，这在很多情况下都拯救了我们。 但MongoDB却缺少这种奢侈品。
存储
MongoDB需要比其他流行数据库更多的存储空间。MongoDB 3.0中引入的WiredTiger解决了存储问题，但是使用WiredTiger可能不是大多数应用程序的理想选择。
磁盘清理
MongoDB不会自动清理磁盘空间。因此，如果文档被重写或删除，则磁盘空间不会被释放。它可通过重启或必须手动完成。
拙劣之处
有时拙劣之处比不好的地方更糟糕。在使用该技术之前，了解这部分很重要。如果不了解它并不会阻止您使用该产品，但它可以使您的生活非常艰难。
自我层级
如果您有一个数据模型，对象可以拥有一个递归的子对象（即，相同的对象类型是一个对象的子对象，并且持续进行n个级别），MongoDB文档可能变得非常难看。索引，搜索和排序这些递归嵌入式文档可能非常困难。
Join(连接)
MongoDB中Join两个文档也不简单。虽然MongoDB 3.2支持左外连接（查找），但还不成熟。如果您的应用程序需要在单个查询中从多个集合中提取数据，则可能无法进行。因此，您必须进行多个查询，这可能会使您的代码看起来有点混乱。
索引
虽然速度被公布为MongoDB的一大优点，但只有您有正确的索引，才能实现。如果最终的索引是错误的或复合索引的顺序不正确，MongoDB可能是最慢的数据库之一。
如果你有很多需要过滤和排序的字段，你可能需要在一个集合上建立很多索引，这当然不是很好。
重复的数据
由于MongoDB不支持明确定义的关系，因此可能会出现大量重复数据。更新这个重复数据可能很困难，并且由于缺乏ACID，我们最终会损坏数据。
结论
总的来说，MongoDB是一个很好的数据库。前提是它适合你的用例。如果不是，则它会变得很丑陋。
