mongodb与mysql相比的优缺点

与关系型数据库相比,MongoDB的优点:

①弱一致性(最终一致),更能保证用户的访问速度:

举例来说,在 传统的关系型数据库中,一个COUNT类型的操作会锁定数据集,这样可以保证得到“当前”情况下的精确值。这在某些情况下,例如通过ATM查看账户信息的 时候很重要,但对于Wordnik来说,数据是不断更新和增长的,这种“精确”的保证几乎没有任何意义,反而会产生很大的延迟。他们需要的是一个“大约” 的数字以及更快的处理速度。

但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求,则它们会堆积起来,造成许多问题。我们使用 了下面的优化方式来避免锁定:每次更新前,我们会先查询记录。查询操作会将对象放入内存,于是更新则会尽可能的迅速。在主/从部署方案中,从节点可以使用 “-pretouch”参数运行,这也可以得到相同的效果。使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。

②文档结构的存储方式,能够更便捷的获取数据。

对于一个层级式的数据结构来说,如果要将这样的数据使用扁平式的,表状的结构来保存数据,这无论是在查询还是获取数据时都十分困难。

③内置GridFS,支持大容量的存储。

GridFS是一个出色的分布式文件系统,可以支持海量的数据存储。内置了GridFS了MongoDB,能够满足对大数据集的快速范围查询。

④内置Sharding。

提供基于Range的AutoSharding机制:一个collection可按照记录的范围,分成若干个段,切分到不同的Shard上。

Shards可以和复制结合,配合Replicasets能够实现Sharding+fail-over,不同的Shard之间可以负载均 衡。查询是对客 户端是透明的。客户端执行查询,统计,MapReduce等操作,这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务,适当的时 候可以无痛的升级。MongoDB的Sharding设计能力最大可支持约20petabytes,足以支撑一般应用。

这可以保证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、删除记录不释放空间:这很容易理解,为避免记录删除后的数据的大规模挪动,原记录空间不删除,只标记“已删除”即可,以后还可以重复利用。

4、可以定期运行db.repairDatabase()来整理记录,但这个过程会比较缓慢

③MongoDB没有如MySQL那样成熟的维护工具,这对于开发和IT运营都是个值得注意的地方。

原文发布于微信公众号 - php(phpdaily)

原文发表时间:2016-07-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术分享

.NET应用架构设计—表模块模式与事务脚本模式的代码编写

阅读目录: 1.背景介绍 2.简单介绍表模块模式、事务脚本模式 3.正确的编写表模块模式、事务脚本模式的代码 4.总结 1.背景介绍 要想正确的设计系统架...

19610
来自专栏原创

五个最佳案例带你解读Node.js的前后之道

Node.js 是什么? Node.js采用C++语言编写而成,浏览器内核V8做为执行引擎;Node不是JS应用、而是一个Javascript的运行环境。Nod...

35310
来自专栏更流畅、简洁的软件开发方式

通用权限的思路。只是一个简单的思路。

面对权限,我们要解决几个的问题。 第一个就是:我们的软件里面有哪些功能? —— 给用户自己维护角色作准备 比如添加新闻、添加产品、客户信息维护、合同管理等等...

1777
来自专栏码农之路_构建基础

基于汇编的 C/C++ 协程 - 背景知识

近几年来,协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案,并且说明其在异步开发模式中的应用。

1633
来自专栏函数式编程语言及工具

ScalaPB(0): 找寻合适的内部系统微服务集成工具

1142
来自专栏企鹅号快讯

一文教会你数据库性能调优

前言 微软工程师的一个工程师曾经对性能调优有一个非常形象的比喻:剥洋葱 。我也非常认可,让我们来一层一层拨开外面它神秘的面纱。 ? 六大因素 下面祭出的是我们在...

1659
来自专栏王磊的博客

服务端接口中的那些坑

TOP1:版本意识与兼容性问题。    对于一个好的程序员来说,思考的时间>=写代码的时间,如果思路不对写的代码越多,错的也越多,任何时候思考是保证高效工作最省...

3835
来自专栏Java后端生活

UUID

1284
来自专栏王亚昌的专栏

UNIX编程艺术之“文本化”

    本章的标题表达了作者的主旨:Good Protocols Make Good Practice。的确,好的协议或文件格式,会大大提升使用者的效率。这里的...

1052
来自专栏CSDN技术头条

轻博客始祖Tumblr:哈希以支撑2.3万Blog请求/秒

【编者按】Tumblr是目前全球最大的轻博客网站,也是轻博客网站的始祖。当下已有超过1.96亿博客,930亿帖子,每秒2万3千请求。近日,该公司网站可靠性工程师...

1805

扫描关注云+社区