本篇文章带大家了解关于mongodb的相关知识,介绍一下MongoDB中的存储引擎,希望对大家有所帮助!
上次我们说到了关于 mongodb 的集群,分为主从集群和分片集群,对于分片集群中的分片这里需要注意如下几点,一起来回顾一下:
某些分片键(分片键是集合中每个文档中存在的索引字段或复合索引字段)会导致所有的读或者写请求都操作在单个数据块或者分片上,这样就会导致单个分片服务器负荷过重,那么自增长的分片键容易导致写的问题【推荐:MongoDB视频教程】
对于粗粒度的分片键,可能会导致许多文档使用相同的分片键
这样的话这些文档就不能被分割为多个数据块,这就会限制了mongodb 的均匀分布数据能力
分片键与查询是没有关联的,这样会造成糟糕的查询性能
对于以上注意点,咱们做到心中有数,实际工作中遇到类似的问题,就可以尝试学着处理了
今天我们简单了解一下mongodb 的存储引擎是个啥
说到 mongodb 的存储引擎,我们要知道是在 mongodb 3.0 的时候引入了可插拔存储引擎的概念
现在主要有这几个引擎:
在存储引擎刚出来的时候,默认是使用的 MMAPV1 存储引擎的
MMAPV1 引擎,看名字我们大概就知道他是使用的是 mmap 来做的,运用的是 linux 内存映射的原理
现在不使用 MMAPV1 引擎,是因为WiredTiger 存储引擎更优,例如对比一下 WiredTiger 就有如下优势:
WiredTiger 能更好的发挥多核系统的处理能力
WiredTiger锁的粒度更小
MMAPV1引擎使用表级锁,当某个单表上有并发的操作,吞吐就会受到限制
而 WiredTiger 使用文档级的锁 ,这就带来并发及吞吐的提高
WiredTiger 使用前缀压缩,比起 MMAPV1 更节省对内存空间的损耗
并且 WiredTiger 还提供压缩算法, 这样就可以大大降低对硬盘资源的消耗
通过上图我们可以看出, WiredTiger写入磁盘的原理也是很简单的
我们用手指头都可以想到,mongodb 的设计者怎么会让这种情况存在,那么必然会有解决方案,如下
如上图,图中多了一个journaling buffer
和journal 文件
存放 mongodb 增删改 指令的缓冲区
类似于关系数据库中的事务日志
引入 Journaling 的目的是:
Journaling 能够使 mongodb 数据库由于意外故障后快速恢复
Journaling 的日志功能,看上去有点像是 redis 中的 aof 持久化一样,也只能说是类似
在 mongodb 2.4 的时候,就已经是默认会开启 Journaling日志功能的,我们启动 mongod 实例的时候,服务就会去检查是否需要恢复数据
因此就不会有上述 mongodb 丢数据的情况了
另外这里我们要知道,journaling 的日志功能,当mongodb 需要进行写操作的时候,也就是 增,删,改的时候,journaling 是会写日志的,这会影响性能
但是mongodb 读取操作的时候,是不会记录到缓存中的,因此也不会记录到 journaling 日志中,因此读操作没有影响
今天就到这里,学习所得,若有偏差,还请斧正
Das obige ist der detaillierte Inhalt von一文深析MongoDB存储引擎(附原理图). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!