mongodb使用哪些存储引擎 mongodb存储引擎有哪些

主机教程 建站分享 2个月前 (10-08) 33次浏览

文章摘要:mongodb使用哪些存储引擎 mongodb存储引擎有哪些

mongodb使用的存储引擎有:1、WiredTiger存储引擎是mongodb3.2的默认存储引擎;2、MM […]

mongodb使用的存储引擎有:1、WiredTiger存储引擎是mongodb3.2的默认存储引擎;2、MMAPv1是mongodb基于内存映射最初的存储引擎;3、In-Memory是一种内存存储引擎,它是非持久性的,不会持久化数据。

一、mongodb存储引擎种类

mongodb主要有3种存储引擎,分别是:

(1) WiredTiger

(2) MMAPv1

(3) In-Memory

下面分别介绍这三种存储引擎。

二、WiredTiger

MongoDB 3.0版本开始启用,64位版本。

MongoDB 3.2 成为默认存储引擎

(1) 文档级别的并发

WiredTiger 对写操作执行文档级别的并发控制,也就是说,在同一时间,可以修改一个集合中的不同文档。

针对大多数的读写操作,WiredTiger采取乐观的并发控制机制。WiredTiger 在全局、数据库和集合级别身上仅使用意向锁。当存储引擎检测到两个操作产生冲突时,其中一个操作会引发一个写冲突,促使mongodb显式的的重新执行该操作。

一些全局的操作,典型的有涉及多个库的短暂操作,需要实例锁;

一些像删除集合的操作,还需要排他锁。

(2) 快照和检查点

WiredTiger 使用多版本的并发控制(MVCC)。

一个操作开始时,WiredTiger 会为事务提供一个实时的数据快照,快照呈现内存中数据的一致性视图。

将数据写入磁盘时,WiredTiger 以一致性的方式将快照中的所有数据写入磁盘。检查点确保数据文件中所有的数据是一致的,并且包含最后一个检查点。检查点可以作为回复数据的点。mongodb配置WiredTiger 来创建检查点(即将快照数据写入磁盘),创建的时机是:每60秒或者当日志文件达到2G。

在写一个新检查点的过程中,上一个检查点仍然是有效的,如果写的过程中出现宕机或者其他异常,一旦重启成功,mongodb会从上一个有效的检查点恢复数据。

当WiredTiger的元数据表关联到新的检查点时,该新的检查点才是可访问和持久的,此时,会释放老检查点的页。

(3) 日志文件系统Journal

默认提交时间间隔为100毫秒。

WiredTiger使用预写事务日志与检查点结合的方式来确保数据持久化。即开启Journal功能,Journal会记录在两个检查点之间的所有修改,当mongodb突然退出并重启之后,WiredTiger会根据Journal中的记录恢复最后一个检查点之后发生的数据修改。

Journal用snappy库压缩。用storage.wiredTiger.engineConfig.journalCompressor指定其他的压缩算法或者不采用压缩策略。WiredTiger 最小的日志记录大小是128字节,如果记录为128字节或者更小,则不会压缩该条记录。

将storage.journal.enabled设置为False,则不会启动Journaling。

对单实例而言,如果禁用journal意味着我们会丢失mongodb异常终止后上一个有效检查点之后的所有数据。对于复制集(主从的mongodb集群)中的一些成员来说,复制过程可能提供充分的持久性保证。

(4) 压缩

使用WiredTiger存储引擎,mongodb支持压缩所有集合和索引。压缩以使用额外的CPU为代价来降低存储消耗。WiredTiger 对集合采用块压缩(使用snappy压缩库或者zlib),对索引采用前缀压缩。可以通过配置来更改压缩方式,换用其他压缩算法或者不进行压缩。再建立一个集合或者一个索引的时候,可以为其制定压缩方式。对于大多数的工作负载,默认的压缩设置会平衡存储效率和处理需求。

(5) 内存使用

使用WiredTiger存储引擎,MongoDB 既会使用WiredTiger的内部缓存,也会使用文件系统的缓存.

从MongoDB3.4开始,WiredTiger 内部缓存会使用下面两个数中的较大者:

a. RAM的50% 减去1 GB

b. 256MB

对于文件系统缓存,MongoDB会自动使用除WiredTiger内部缓存以及其他进程占用内存的所有空闲内存。文件系统中的缓存会被压缩。

想要调整WiredTiger的内部缓存, 可以参考storage.wiredTiger.engineConfig.cacheSizeGB和wiredTigerCacheSizeGB.

避免增加WiredTiger内部缓存的大小超过其默认值。

三、MMAPv1

MMAPv1是MongoDB基于内存映射的最初的存储引擎,它在大量的读写和就地更新的任务上有很好的表现。从3.2版本开始,MMAPv1 不在是默认的存储引擎。

注意:big-endian架构不支持MMAPv1存储引擎,如果在大端机器上采用该存储引擎,会报错。Endian表示数据在存储器中的存放顺序,采用大端方式 进行数据存放符合人类的正常思维,而采用小端方式进行数据存放利于计算机处理。大端指低地址存放最高有效字节,小端是指低地址存放最低有效字节。

例如:我们要存储一个16进制的数0x31323334;

小端机器的存储方式为:

低地址 –> 高地址

34 33 32 31

大端机器的存储方式为:

低地址 –> 高地址

31 32 33 34

(1) Journal

为了确保所有的数据都被持久化到磁盘,MongoDB默认将所有修改都保存到磁盘的日志文件中,MongoDB写日志文件要比写数据文件频繁。

storage.syncPeriodSecs:设置数据文件存储时间间隔,默认60秒。不要在生产环境设置该参数,在几乎所有场景,你都应该用该默认的参数,如果将该参数设置为0,MongoDB 将不会同步内存映射文件到磁盘。

storage.journal.commitIntervalMs:默认值为100毫秒或30毫秒,取值范围是0~500毫秒,取值越低,数据持久性越高,但是会牺牲磁盘性能。

默认日志存储时间间隔为100毫秒。但是如果日志文件被存储在于数据文件不同的区块设备上,例如physical volume, RAID device, or LVM volume,默认日志提交间隔会变为30毫秒,此外, when a write operation with j:true is pending, 提交的时间间隔将要变成设置值的三分之一。

在许多情况下,MongoDB 和操作系统更新数据到磁盘要比设置的时间间隔频繁的多,所以,以上的设置值只是理论上的最大值。

当mongod实例异常退出时,MongoDB 可以根据这些数据文件恢复数据库。

(2) 记录存储特性

所有记录都是连续的存储在磁盘上,当一条记录被更新并且超出原来分配的记录大小,则需要重新分配一个记录,之后将文档移动到新记录中,并且更新与文档相关的所有索引。这显然比原地更新记录要花费更多的时间,同时还会导致存储碎片。

从3.0版本开始,分配策略有所改变。

(3) 记录分配策略

从3.0版本开始,MongoDB使用Power of 2 Sized Allocations策略,将一个文档存储到一条记录中,同时记录中还有额外的空间,这些额外的空间允许更新操作带来的文档大小的增长,使得重新分配内存的可能新降到最低。

不同的分配策略支持不同种类的操作:

the power of 2 allocations:对insert/update/delete操作更加有效; 采用该策略之后,所有记录的大小均为2的n次幂字节。对于大于2MB的文档,分配将要向上取整到2MB的倍数。该策略有以下两个关键特性:

能重新使用释放的记录来减少碎片。

能减少文档移动,但是不能完全消除重新分配的情况。

exact fit allocations(No Padding Allocation Strategy):对没有更新和删除操作的集合更理想。

对于那些没有改变文档大小操作或者只有插入操作的集合,我们可以将the power of 2 allocations设置为无效。在3.0版本以前,MongoDB 通过动态计算填充大小来作为文档大小的因素。

(4) 内存使用

采用MMAPv1存储引擎,MongoDB自动使用机器所有空闲的内存作为它的缓存,系统资源监控显示,MongoDB用了许多内存,但是它的使用是动态的,当其他进程需要使用内存时,MongoDB会放弃部分缓存所占用的内存给其他进程。

从技术上来说,操作系统的虚拟内存子系统管理着MongoDB内存,这意味着MongoDB会尽可能多的使用空闲内存,当需要的是有也会切换到磁盘,部署足够的内存来适应工作数据集将会获得做好的性能。

三、In-Memory(内存存储引擎)

(1) 并发性

内存存储引擎使用文档级别的并发控制,可以在同一时刻对不同文档进行更新操作。

(2) 内存使用

内存存储引擎要求它的所有数据必须符合在命令行参数(–inMemorySizeGB)或者在YAML配置文件中设置的内存大小。

默认情况下,内存存储引擎使用物理RAM的50%减去1 GB的内存。

如果一个写操作超出指定的内存大小,mongodb将会报错,错误信息如下:

“WT_CACHE_FULL: operation would overflow cache”

(3) 持久化

内存存储引擎是非持久性的,不会持久化数据。非持久化的数据包括应用程序数据,系统数据,例如用户、权限、索引、副本设置配置、分片集群配置等。数据库正常或者异常关闭的情况下,数据均不可恢复。

在采用内存存储引擎,或者其他存储引擎但是关闭了Journal功能是,必须将writeConcernMajorityJournalDefault参数设置为False。

(4) 部署结构

除了作为单实例运行,采用内存存储引擎的mongod实例也可以作为副本集或者分片集群的一部分。

作为副本集的一部分

例如,一个有三个成员的副本集,其结构可以为:

两个mongod实例运行在In-Memory存储引擎上

另外一个mongod实例运行在WiredTiger存储引擎上,并将该实例配置为隐藏成员。

在该配置结构下,只有采用IN-memory的数据库实例会被选举为最主要者,客户端只会连接到该实例上。即使两个使用In-memory的数据库实例均死机或者重启,他们都会从运行在WiredTiger的实例上同步数据。隐藏的数据库实例会将用户数据、索引和其他复制配置信息都持久化到磁盘上。

作为分片集群的一部分

例如,一个有三个成员的分片集群,其结构可以为:

两个mongod实例运行在In-Memory存储引擎上

另外一个mongod实例运行在WiredTiger存储引擎上,并将该实例配置为隐藏成员。

为分片加inmem标签。如果该分片的名字为”shardC”,则连接mongos ,然后运行sh.addShardTag(“shardC”, “inmem”),对于其他的分片,分别添加一个persisted 标签,

sh.addShardTag(“shardA”, “persisted”)

sh.addShardTag(“shardB”, “persisted”)

对于每个应该驻留在内存中的分片集合,分配给整块范围的inmem标签。

sh.addTagRange(“test.analytics”, { shardKey: MinKey }, { shardKey: MaxKey }, “inmem”)

对于每个应该驻留在持久化中的分片集合,分配给整块范围的persisted标签。:

sh.addTagRange(“salesdb.orders”, { shardKey: MinKey }, { shardKey: MaxKey }, “persisted”)

对于内存中的分片,创建一个数据库或者移动一个数据库。


声明:
若非注明,本站文章源于互联网收集整理和网友分享发布,如有侵权,请联系站长处理。
文章名称:mongodb使用哪些存储引擎 mongodb存储引擎有哪些
文章链接:https://www.7966.org/post/9762.html
转载请注明出处

喜欢 (0)