探究MongoDB数据库的高速写入能力 (mongodb数据库写入速度)

近年来,随着大数据、等技术的崛起,数据存储和处理成为了各个行业关注的焦点。作为一种非关系型数据库,MongoDB(繁殖自humongous,意为庞大)由于其高效的写入能力、水平扩展以及半结构化等特点享有越来越广泛的应用。

MongoDB的高速写入能力是其得以广泛应用的关键因素之一,下面就让我们从多个角度深入探究MongoDB的写入性能。

一、MongoDB整体架构

MongoDB的底层存储是基于BSON(Binary ON)的文档存储形式,既支持内存和非持久化存储,也支持磁盘和持久化存储。这使得MongoDB能够实现非常灵活的存储多种数据类型的日志和文档数据。

MongoDB整体架构中,主要组件包括:

1.客户端:与MongoDB进行交互的应用程序,可以通过多种语言的驱动程序访问数据库。

2.MongoDB实例:一个可运行的MongoDB进程,可以在单节点或多节点集群环境中运行,负责处理客户端请求和数据操作。

3.:一组逻辑上相关的BSON文档,对于中的每个文档,有一种数据模式称为文档模型。

4.文档:MongoDB最小的数据单元,虽然有着多种数据类型,但无需遵循相同的数据结构。

5.索引:可用于加速查询和确保唯一性的数据结构,MongoDB提供了各种索引类型,如单键索引、组合索引、文本索引、地理位置索引等。

二、MongoDB的写入性能优化

MongoDB的高速写入性能来自于其内部的一些特性和优化手段:

1.预分配空间

在MongoDB中,对于文档的插入和修改,通常是在磁盘上写入一块新的空间,但是如果写入频率过高,则可能会引发磁盘IO瓶颈。因此,MongoDB采用了一种称为“预分配”的机制,即在执行大量写操作之前,先预分配一定大小的文件空间,避免在写操作时频繁地申请磁盘空间,从而优化了写入性能。

2.内存映射

MongoDB在内存映射文件时,将文件直接映射到内存,这样就可以直接访问内存并避免了没有必要的磁盘IO操作。在使用MMap存储引擎时,MongoDB还使用了堆栈式分配机制,即将内存映射文件分片,减少内存映射文件时的内存压力。

3.批量写入

MongoDB通过批量写入机制,将相邻的一组文档数据写入磁盘,以减少磁盘IO操作的数量,同时将批量写入与预分配机制结合使用,避免了大量的文件IO操作,从而提高了写入速度。

三、MongoDB性能测试

为了更好地理解MongoDB的写入性能,我们进行了一系列的性能测试:

1.单节点写入性能测试

我们使用了官方的Java驱动对MongoDB进行单线程和多线程的写入测试。在单线程测试中,写入速度为1025次/秒,而在使用50个线程的多线程测试中,写入速度达到了7153次/秒,由此可见,MongoDB具有出色的单节点写入性能。

2.多节点写入性能测试

我们在多节点集群环境下进行了多线程写入性能测试,测试结果显示,MongoDB的写入性能可以在多节点环境中很好地水平扩展,并能够支持高并发的写入请求。在分布式集群中,MongoDB使用了分片机制来聚合数据,充分利用各节点的存储空间,并负载均衡读写请求,从而提高写入性能。

四、应用场景

作为一种快速、高效的非关系型数据库,MongoDB广泛应用于多个领域,例如:

1.流媒体和实时分析

对于流媒体和实时分析应用,MongoDB采用了可扩展的架构和高速写入机制,能够快速地读取和存储大量数据。

2.电子商务

电子商务平台需要快速地记录其用户的交易记录,并对这些数据进行高效地分析,以便预测客户行为和市场趋势。MongoDB提供了灵活的数据模型和高速写入机制,为电商企业提供了高效且可扩展的存储和分析解决方案。

3.数据日志

针对企业中各种数据日志的需求,MongoDB的非关系型存储提供了扩展性和快速读写能力,可存储大量的日志数据并支持实时查询和分析。

MongoDB具有出色的写入性能,并且能够在多节点集群环境中水平扩展。对于对写入性能和分析速度有高要求的应用,MongoDB提供了可扩展和高性能的存储和分析解决方案。而对于电商、数据日志等领域,MongoDB也提供了适用的存储和分析解决方案。

相关问题拓展阅读:

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 : “Ada”, text : “Good post” }>

})

> db.blogposts.find( { “author.name” : “Jane” } )

> db.blogposts.findOne({ title : “My First Post”, “author.name”: “Jane”,

comments :

{ by : “Ada”, text : “Good post” } >

})

> db.blogposts.find( { “comments.by” : “Ada” } )

> db.blogposts.ensureIndex( { “comments.by” : 1 } );

举例③:

MongoDB是一个面向文档的数据库,目前由10gen开发并维护,它的功能丰富,齐全,完全可以替代MySQL。在使用MongoDB做产品原型的过程中,我们总结了MonogDB的一些亮点:

使用ON风格语法,易于掌握和理解:MongoDB使用ON的变种BSON作为内部存储的格式和语法。针对MongoDB的操作都使用ON风格语法,客户端提交或接收的数据都使用ON形式来展现。相对于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 数据库

游戏服务器开发中,玩家的账号,背包,装备,物品,排名等数据都需要落地存储在闷者数据库中。行业中主流的数据库当属mysql,优点是免费开源,从端游时代过渡过来的程序员,求茄罩耐稳保守的话大多数会选用mysql数据库做存储。但是游戏中要存储的数据表会经常改动,导致数据库的表会频繁更新改动表结构,如果游戏数据量达到千万级别,对所有的表刷新改动会是一项很恐怖的事情,期间如果再出错,运维跟开发人员估计全都GG。

为了应对方便扩展,提升读写速度,NoSQL数据库(非关系型数据库)诞生。在NoSQL中应用比较广泛的当属mongodb和redis,由于对开发者友好,方便快速开发迭代高可用复制集满足数据高可靠、服务高可用的需求,运维简单,故障自动切换可扩展分片集群海量数据存储被游戏服务器广泛应用。现在的项目《鹿鼎记》用redis做颤春高速缓存角色列表信息数据。

关于mongodb数据库写入速度的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。


数据运维技术 » 探究MongoDB数据库的高速写入能力 (mongodb数据库写入速度)