本篇文章给大家分享的是有关如何分析MongoDB的好坏,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
对刚刚接触 MongoDB 的人来说, MongoDB就是一个NoSQL类型的文档数据库. 文档中包含的键值对,构成了MongoDB的数据基本单位。
不过可以肯定的是MongoDB的确是当前***的NoSQL数据库. 它已被广泛接受并且适合各种各样的场合 (尽管不是所有项目都使用它)。
我将根据过去几年来我使用MongoDB所得出的经验,简短的介绍下MongoDB的好处、坏处和它丑陋的地方。
好处
自 MongoDB 流行以来,它的好处应该多于坏处和丑陋的地方. 如若不是,开发者们也不会接受它. 下面是一些MongoDB好的方面。
灵活的数据模型
当今动态的用户案例以及不断变化的应用,拥有一个灵活的数据模型是一种福音。灵活的数据模型意味着没有预先定义的模式,文档可以基于任何键值持有任何值的集合。
富有表现力的查询语法
MongoDB的查询语句是非常具有表现力且易于理解的。许多人会说这不像SQL语句。但是当我们能向前发展,且查询语句更简单并具表现力的时候,为什么我们还要坚持类似SQL的查询语句呢?
容易学习
MongoDB很容易学习,并且能快速上手。基本的安装、执行不会超过几个小时。 更强大的设置可能是复杂的,但是我会晚点再谈论这方面。
根据上面这些特点想必你应该很容易把它揉进你的项目中。
性能
查询性能是MongoDB的长处. 它把大多数可操作的数据存储在内存中. 所有的数据是固化在硬盘中的, 但在查询过程中, 它不会从硬盘中过去数据(那样太慢). 它直接从本地内存中获取数据,因此速度就会更快. 所以,为数据设置正确的索引并且提供足够的内存便能发挥MongoDB的性能优势。
可伸缩性和可靠性
MongoDB 具有很高的可伸缩性, 在碎片数据使用方面. 横向可伸缩性在大多数NoSQL数据库中是一大亮点. MongoDB 也不例外。
它也是高度可靠的,因为它的副本集数据被异步的复制到更多的节点。
异步驱动
对于所有的现代应用程序而言使用异步的非阻塞IO是提速的关键。MongoDB异步驱动程序支持***的语言。
文档
拥有一个良好的文档可以让开发人员的生活变得容易很多,特别是当开发人员面对的是新技术。MongoDB有出色的文档。
文本搜索
如果你正在建设一个网站, 需要搜索您的所有数据,文本搜索是必不可少的。例如,一个使用具有文本搜索的数据库的电子商务网站对用户来说更有利。
服务端脚本
如果你有一些操作需要在服务端而不是应用端执行,在MongoDB中,你可以那么做。把mongo语句放在一个.js文件中,并用mongo命令执行js文件。
文档 = 对象
文档数据库的优点是对象可以在MongoDB中存储为一个单独的文档。 这边不需要对象关系映射(ORM)。
缺点
我们已经看到了有关MongoDB的各种优点,接下来要说下缺点了。我敢肯定批评家对这部分更感兴趣。如果使用不当,MongoDB可能会做坏事。
现今,实际上很少有应用程序需要事务,但是有一些程序还是需要的。不幸的是, MongoDB不支持事务。因此当一个请求中需要修改多个文档或多个集合时就不要使用MongoDB。由于没有ACID保证它可能会导致数据损坏。回滚操作必须由你的应用程序来处理。
没有触发器
在关系式数据库中,有触发器,在很多情况下它是十分有用的。但是在MongoDB中就没这个了。
存储
相比其他流行的数据库MongoDB需要更多的存储。 在 MongoDB 3.0中引入的WiredTiger解决了这个问题,但是对于大多数应用程序来说使用WiredTiger不甚理想。
磁盘清理
MongoDB不会自动清理磁盘空间。因此如果文档被修改了或删除了,磁盘空间不会被释放。你必须通过手动或重启来释放。
丑陋的
有时,丑陋可能比坏更糟糕。使用一项技术之前了解它的不足是很重要的。它不会阻止你使用它,但它可以让你的活的非常艰难。
层次结构
如果你有一个是递归包含孩子数据对象的数据模型 (如, 一个对象拥有与它相同数据类型的孩子对象并且层级很多), MongoDB的文档结构就会变得非常丑陋。对这些递归嵌入的文档进行索引、搜索和排序将非常困难。
Join(连接)
MongoDB中join两个文档是不容易的,虽然MongoDB 3.2支持左外连接 (lookup), 但它尚未成熟。如果你的应用程序需要在一个查询中实现获取多个集合中的数据,那可能无法实现。因此你必须使多个查询,这可能会让你的代码看起来有点乱。
索引
虽然MongoDB标榜速度是它的一大亮点,但它依赖于你建立了正确的索引。如果你建立的索引很糟糕或不正确顺序的复合索引,那么 MongoDB可能是最慢的数据库。
如果你有很多的过滤条件和排序字段,你可能会在一个集合上建立很多的索引,当然这是不好的一个做法。
重复数据
你可能会有大量重复的数据,MongoDB不支持关系式。修改这些重复数据可能会比较困难,且由于缺少事务支持,我们还可能会损坏数据。
结论
综述,只要你恰当的使用,MongoDB是一个优秀的数据库,否则它会给你带来麻烦。在不恰当的地方使用它你将会吃到苦头。
认真的分析以及咨询专家。正确的使用你绝对会爱上它。
至于坏的和丑陋的部分,你可以一些使用设计模式来解决其中的一些问题,在我的文章解释了 MongoDB设计模式。
MongoDB的***实践
下面列出了几个MongoDB的***实践:
硬件
确保你的数据集能放入内存中
使用压缩
每台服务器运行单个MongoDB
对于写入数据较多的应用使用固态硬盘
数据模型
一条记录的所有数据都存在一个文档中
避免大尺寸的文档
避免不必要的长字段名
去掉不必要的索引
删除其它索引前缀的索引
应用程序
只修改变化的字段
避免否定式查询
对于复杂的查询运行explain()(查看执行计划)
在可能的情况下使用覆盖查询.
在需要的时候使用批量插入.
安装和配置
拥有至少一个从库和一个仲裁
当数据非常重要时应设置参数 write concern 为2
有每日的数据转储备份。
以上就是如何分析MongoDB的好坏,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。