未加星标

[译] MongoDB 的好坏丑

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

对刚刚接触 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 有每日的数据转储备份。

本文数据库(综合)相关术语:系统安全软件

分页:12
转载请注明
本文标题:[译] MongoDB 的好坏丑
本站链接:http://www.codesec.net/view/481315.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(37)