Mongo性能优化实战:如何通过WiredTiger引擎提升MongoDB的性能和数据安全性 | 客服服务营销数智化洞察_晓观点
       

Mongo性能优化实战:如何通过WiredTiger引擎提升MongoDB的性能和数据安全性

MongoDB,作为一款流行的NoSQL数据库,其存储引擎的选择直接影响到数据库的性能和稳定性。本文将深入探讨MongoDB中的WiredTiger存储引擎,分析其读写模型、缓存机制、检查点(Checkpoint)策略以及日志系统,帮助大家理解WiredTiger如何通过高效的数据管理策略来提升MongoDB的性能和数据安全性。

一、wiredTiger 简介

mongodb 3.0默认存储引擎为MMAPV1,还有一个新引擎wiredTiger可选,或许可以提高一定的性能。

wiredTiger引擎:3.0新增引擎,官方宣称在read、insert和复杂的update下具有更高的性能。所有的write请求都基于“文档级别”的lock,因此多个客户端可以同时更新一个colleciton中的不同文档,这种更细颗粒度的lock,可以支撑更高的读写负载和并发量。因为对于生产环境,更多的CPU可以有效提升wireTiger的性能,因为它是的IO是多线程的。

二、WiredTiger 读写模型

读缓存

理想情况下,MongoDB 可以提供近似内存式的读写性能。WiredTiger 引擎实现了数据的二级缓存,第一层是操作系统的页面缓存,第二层则是引擎提供的内部缓存。

读取数据时的流程如下:

Mongo性能优化实战:如何通过WiredTiger引擎提升MongoDB的性能和数据安全性

数据库发起 Buffer I/O 读操作,由操作系统将磁盘数据页加载到文件系统的页缓存区。

引擎层读取页缓存区的数据,进行解压后存放到内部缓存区。

在内存中完成匹配查询,将结果返回给应用。

MongoDB 为了尽可能保证业务查询的“热数据”能快速被访问,其内部缓存的默认大小达到了内存的一半,该值由 wiredTigerCacheSize 参数指定,其默认的计算公式如下:

wiredTigerCacheSize=Math.max(0.5*(RAM-1GB),256MB)

在线调整mongodb wiredTiger缓存大小:

use admin
// 调整为1G大小
db.adminCommand({setParameter:1, wiredTigerEngineRuntimeConfig:'cache_size=1G'}) 

写缓冲

当数据发生写入时,MongoDB 并不会立即持久化到磁盘上,而是先在内存中记录这些变更,之后通过 CheckPoint 机制将变化的数据写入磁盘。为什么要这么处理?主要有以下两个原因:

如果每次写入都触发一次磁盘 I/O,那么开销太大,而且响应时延会比较大。

多个变更的写入可以尽可能进行 I/O 合并,降低资源负荷。

(1)CheckPoint(检查点)机制

快照(snapshot)描述了某一时刻(point-in-time)数据在内存中的一致性视图,而这种数据的一致性是 WiredTiger 通过 MVCC(多版本并发控制)实现的。当建立 CheckPoint 时,WiredTiger 会在内存中建立所有数据的一致性快照,并将该快照覆盖的所有数据变化一并进行持久化(fsync)。成功之后,内存中数据的修改才得以真正保存。默认情况下,MongoDB 每 60s 建立一次 CheckPoint,在检查点写入过程中,上一个检查点仍然是可用的。这样可以保证一旦出错,MongoDB 仍然能恢复到上一个检查点。

调整脏数据及checkpoint参数:

use admin
db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "eviction=(threads_min=8,threads_max=16),checkpoint=(wait=120,log_size=2GB),eviction_trigger=95,eviction_target=10"})

(2)Journal日志

Journal 是一种预写式日志(write ahead log)机制,主要用来弥补 CheckPoint 机制的不足。如果开启了 Journal 日志,那么 WiredTiger 会将每个写操作的 redo 日志写入 Journal 缓冲区,该缓冲区会频繁地将日志持久化到磁盘上。默认情况下,Journal缓冲区每 100ms 执行一次持久化。此外,Journal 日志达到 100MB,或是应用程序指定journal:true,写操作都会触发日志的持久化。一旦 MongoDB 发生宕机,重启程序时会先恢复到上一个检查点,然后根据 Journal 日志恢复增量的变化。由于 Journal 日志持久化的间隔非常短,数据能得到更高的保障,如果按照当前版本的默认配置,则其在断电情况下最多会丢失 100ms 的写入数据。

WiredTiger 写入数据的流程:

应用向 MongoDB 写入数据(插入、修改或删除)。

数据库从内部缓存中获取当前记录所在的页块,如果不存在则会从磁盘中加载(Buffer I/O)。

WiredTiger 开始执行写事务,修改的数据写入页块的一个更新记录表,此时原来的记录仍然保持不变。

如果开启了 Journal 日志,则在写数据的同时会写入一条 Journal 日志(Redo Log)。该日志在最长不超过 100ms 之后写入磁盘。

数据库每隔 60s 执行一次 CheckPoint 操作,此时内存中的修改会真正刷入磁盘。

更改journal提交时间:

storage:
  journal:
    commitIntervalMs: 100

Journal 日志的刷新周期可以通过参数storage.journal.commitIntervalMs指定,MongoDB 3.4 及以下版本的默认值是 50ms,而 3.6 版本之后调整到了 100ms。由于 Journal 日志采用的是顺序 I/O 写操作,频繁地写入对磁盘的影响并不是很大。

CheckPoint 的刷新周期可以调整storage.syncPeriodSecs参数(默认值 60s),在 MongoDB 3.4 及以下版本中,当 Journal 日志达到 2GB 时同样会触发 CheckPoint 行为。如果应用存在大量随机写入,则 CheckPoint 可能会造成磁盘 I/O 的抖动。在磁盘性能不足的情况下,问题会更加显著,此时适当缩短 CheckPoint 周期可以让写入平滑一些。

咨询方案 获取更多方案详情                        
(1)
研发专家-Halk研发专家-Halk
上一篇 2024年5月25日 上午9:23
下一篇 2024年5月29日 下午5:50

相关推荐