MONGODB Wiredtiger 为什么那么快?

如果有人说我精通ORACLE ,MYSQL ,那我信,但如果有人说特别精通MONGODB 的原理以及源代码,那就真的佩服了。这方面的书比较少,所以说精通MONGODB 的原理,那真是比较不容易。

为什么是胡想瞎猜,是因为如果说错了,那就等着您来指正,互相提高技术水平。

首先看一个可能被看烂了的mongodb 的整体架构图,从图中可以总结出以下list

1 mongodb 支持行 和 列存储,目前大部分状态下使用的是行存储

2 数据存储在磁盘和cache中的数据的格式应是不一样的,需要压缩,解压

3 数据的处理都是处理无压缩的数据

4 系统通过snapshot 的方式进行 MVCC 的多版本控制,减少锁的产生

5 事务产生则最先要落LOG日志,数据则在缓冲中在刷入到磁盘

由于大部分的数据处理在内存中,并且尽量降低锁,和并发之间的互斥操作,使得MONGODB 的结构相对于其他传统数据库要简单,这也是使得MONGODB 的操作相对其他数据库要快的一个原因。这就要提到 in memory ,mongodb 的寻址设计中并没有使用传统的文件系统的偏移量作为指针。如果是B+ 树三层的展现,则在内存中,非叶子节点的信息会在内存中

所以寻址都是在内存中进行的,这就会带来更高的性能,这也是有些文字中提到的,给与MONGODB 的内存不要太吝啬的一个原因。

总结 in memory 的架构

1 系统会cache trees 并且将部分page 优化,在内存中访问

2 指针遍历B+树时,不会锁定读和写,

3 保证原始的数据与更新的数据分开

4 结构化的改变 (例如 页面的merge 和 splits)都是在后台线程中处理的

当然有些数据库也在这么做,那wiredtiger 会变得更快的原因在于另一个词 no locking no lock manager ,其他的传统数据库都有锁的概念,有的数据库类似 sql server 的锁还有锁升级的概念,可想而知,越复杂的东西,其速度必然也不会快到哪里去。MONGODB 摒弃了所,通过MVCC 以及自身的特征,对正在读的数据创建snapshot ,而写的数据创建新的版本,这样读和写就分开了,通过时间戳的概念(参见之前的一篇文字),将整体的 MONGODB 与锁这个词分开。速度自然就会更快,更强。当然由于本身的设计原因,也就不用太多考虑回滚的事情。

MONGODB 快的原因还要归功于block manager ,Block mananger 主管 ,将数据在写入时就进行最大化的压缩,这样的好处是,目前的机器都拥有很强大的CPU ,但实际上大部分的瓶颈还在于磁盘,而由于将压力转到CPU 对数据的压缩LEVEL 变的很高,则读取数据 和写入数据的负担就会降低。很巧妙的利用了当前硬件的优势。同时也可以根据当前机器和所处的环境对压缩进行选择。

snappy是默认的压缩方式,LZ4 更适合 page layout ,  zlib 拥有高压缩比。

而有效的checkpoint 的方式也是促使 mongodb  wiredtiger 处理速度很快的一个因素。

从上图可以看到,页面的修改并不是在原有的空间进行,而是将改变的页面在新的页面生成,在通过指针从新的生成的页面,指向未改变的页面。将新的根地址写入到 metadata 中。这样的处理的速度要比加锁,然后改变数据的方式要快的多。并且大部分MONGODB 处理的方式多是写,和读,大量的UPDATE 的并不多见。

上面讲过的MVCC ,则系统中必然有一个旧版本的读取器,这样就算一边读取数据,一边写入数据,之间也不会进行干扰,而将这个事情变得简单的事情就是MONGODB 没有 UNDO LOG   REDO 这样会导致系统变得更复杂和缓慢的东西(参见 MYSQL  ORALCE  UNDO REDO )。

所以MONGODB WIREDTIGER 为什么这么快

1 本身的架构设计,因为没有事务需要进行逻辑上的回滚需求,写入具有原子性

2  大量使用内存的方式来处理读写数据

3  对写入数据的压缩,对I/o方面是很有帮助的

4  MVCC 以及相关的设计,无锁化的设计

5  特殊的数据更新的方式,不会有其他数据库的 page merge page split 等影响性能的困扰。

以上仅仅是个人的理解,如有失误,错误,还请您不吝赐教。

感谢

<think>嗯,用户问的是MongoDB 8.0中用什么替代journal配置。首先,我需要确认MongoDB的版本情况。记得MongoDB在4.0之后做了一些调整,特别是关于存储引擎的部分。默认的存储引擎是WiredTiger,而之前的MMAPv1已经被弃用了。Journaling在WiredTiger中的作用是确保数据的持久性,通过预写日志(Write Ahead Log, WAL)来恢复未写入数据文件的操作。 然后,用户提到的是MongoDB 8.0,但根据我的记忆,MongoDB的最新版本可能还没到8.0。比如,当前稳定版可能是5.x或者6.x?这可能是一个需要注意的地方。用户可能混淆了版本号,或者MongoDB确实发布了8.0?需要查证一下。不过,假设问题正确,继续思考。 在MongoDB的更新中,尤其是WiredTiger引擎,是否在某个版本之后移除了journal配置?比如,从MongoDB 4.0开始,WiredTiger引擎的journaling是默认启用的,并且不可禁用,所以配置选项可能被移除了。因此,用户可能发现之前的journal配置参数不再可用,需要了解替代方案。 原来的journal配置选项比如storage.journal.enabled,在4.0之后如果使用WiredTiger的话,这个选项可能已经无效了,因为journal无法被禁用。这时候,用户可能想调整journal相关的行为,比如日志提交间隔、日志文件大小等,但原来的配置方式可能发生了变化。 可能的替代方案包括调整WiredTiger的日志相关配置。例如,在storage.wiredTiger.engineConfig中设置journalCompressor,或者在storage.wiredTiger.engineConfig中配置journal的路径等。另外,关于日志的提交频率,可以通过writeConcern来调整,或者在启动参数中使用--journalCommitInterval参数设置。 用户可能是在升级到新版本后,发现之前的journal配置不再适用,想知道如何调整类似的设置。需要解释在MongoDB新版本中,journaling的配置可能已经被整合到WiredTiger的配置中,或者某些参数被废弃,改用其他方式管理。 另外,数据持久性的保证除了journaling之外,还可以通过副本集和写关注(write concern)来增强。例如,使用多数写关注或者启用j: true选项来确保数据写入journal后才确认。这可能也是用户需要考虑的方面。 总结回答的结构应该是:确认MongoDB版本中journal的变化,说明WiredTiger引擎下journal的默认行为,原来的journal配置参数是否被替代,如何调整相关参数,以及替代方案如写关注和副本集的使用。</think> MongoDB 8.0(实际截至2023年10月,MongoDB最新稳定版本为6.x,尚未发布8.0)中,如果你指的是 **WiredTiger存储引擎**(默认存储引擎)的日志(Journal)配置,需注意以下调整: -- ### **核心变化与替代方案** 1. **Journal 默认不可禁用** 自 MongoDB 4.0 起,WiredTiger 引擎的 Journal 日志**默认强制启用**且无法关闭(`storage.journal.enabled` 参数已移除)。这是为了确保数据持久性,防止崩溃时数据丢失。 2. **替代配置方向** 若需调整 Journal 行为,可通过以下参数优化: - **提交间隔** 控制日志刷盘频率(默认100ms): ```yaml storage: journal: commitIntervalMs: 100 # 单位毫秒,可适当调整 ``` - **日志压缩** 减少日志体积(如使用 `snappy` 或 `zstd`): ```yaml storage: wiredTiger: engineConfig: journalCompressor: snappy ``` - **日志存储路径** 分离日志与数据目录以提升性能: ```yaml storage: dbPath: /data/db journal: enabled: true directoryPerDB: true # 单独指定日志路径(需在启动时配置) ``` 3. **数据持久化的其他保障** - **写关注(Write Concern)** 使用 `{ j: true }` 强制数据写入 Journal 后才确认操作: ```javascript db.collection.insert({ ... }, { writeConcern: { j: true } }) ``` - **副本集冗余** 通过多节点副本集分散风险,结合 `w: "majority"` 提高容灾能力。 --- ### **为何移除 Journal 配置?** MongoDB 设计上强化了数据安全性,避免用户误禁用 Journal 导致数据丢失风险。WiredTiger 的 Journal 机制在性能与可靠性间已优化平衡,多数场景无需手动调整。 --- ### **实践建议** - **保持默认配置**:除非有明确性能瓶颈或特殊需求,否则建议沿用 Journal 默认设置。 - **监控与调优**:通过 `mongostat` 或云监控工具观察 Journal 写入频率,必要时调整 `commitIntervalMs`。 - **结合副本集**:生产环境务必部署副本集,而非依赖单节点 Journal。 如有具体场景(如高性能写入或资源受限环境),可进一步细化调整策略。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值