mongodb的存储引擎

mongodb版本为3.4

mongodb存储引起的一些概述

存储引擎是MongoDB的核心组件,负责管理数据如何存储在硬盘和内存上。从MongoDB 3.2 版本开始,MongoDB 支持多数据存储引擎,MongoDB支持的存储引擎有:WiredTiger,MMAPv1和In-Memory。

从mongodb3.2开始默认的存储引擎是WiredTiger,3.3版本之前的默认存储引擎是MMAPv1,mongodb4.x版本不再支持MMAPv1存储引擎。

MongoDB不仅能将数据持久化存储到硬盘文件中,而且还能将数据只保存到内存中;In-Memory存储引擎用于将数据只存储在内存中,只将少量的元数据和诊断日志(Diagnostic)存储到硬盘文件中,由于不需要Disk的IO操作,就能获取索取的数据,In-Memory存储引擎大幅度降低了数据查询的延迟(Latency)

WiredTiger存储引擎

从mongodb3.2开始mongodb默认支持WiredTiger存储引擎,对于3.2之前的版本可以使用参数指定存储引擎。

storage:
engine: wiredTiger
wireTiger:
[存储引擎的参数设置]

WiredTiger是各种操作应用的理想选择,因此是MongoDB的默认存储引擎。它应该是所有新应用程序的起点,除了您需要内存或加密存储引擎的特定功能的情况。

WiredTiger存储引擎的主要优势:

最大化可用缓存: WiredTiger最大限度地利用可用内存作为缓存来减少I / O瓶颈。使用了两个缓存:WiredTiger缓存和文件系统缓存。WiredTiger缓存存储未压缩的数据并提供类似内存的性能。操作系统的文件系统缓存存储压缩数据。当在WiredTiger缓存中找不到数据时,WiredTiger将在文件系统缓存中查找数据。

mongodb的存储引擎

在移动到WiredTiger缓存之前,在文件系统缓存中找到的数据首先经过解压缩过程。

WiredTiger缓存在保存尽可能多的工作集时表现最佳。但是,为需要它的其他进程(如操作系统,包括文件系统缓存)保留内存也很重要。这也包括MongoDB本身,整体上消耗的内存比WiredTiger主动使用的内存多。

MongoDB默认为WiredTiger缓存大小约为RAM的60%。离开文件系统缓存的最小量是可用内存的20%。任何较低的操作系统都可能受限于资源。

高吞吐量: WiredTiger使用“写入时复制” - 当文档更新时,WiredTiger将制作文档的新副本并确定最新版本以返回给读者。此方法允许多个客户端同时修改集合中的不同文档,从而实现更高的并发性和吞吐量。当应用程序使用具有多个内核的主机(越多越好)并且多个线程正在写入不同的文档时,实现最佳写入性能。

减少存储空间并改善磁盘IOP: WiredTiger使用压缩算法来减少磁盘上存储的数据量。不仅存储减少了,而且随着从磁盘读取或写入更少的位,IOP性能也会提高。某些类型的文件比其他文件压缩得更好。文本文件是高度可压缩的,而二进制数据可能不是可压缩的,因为它可能已经被编码和压缩。使用压缩时,WiredTiger会产生额外的CPU周期,但用户可以配置压缩方案以优化CPU开销与压缩比。Snappy是默认的压缩引擎,在高压缩率和低CPU开销之间提供了良好的平衡。Zlib将实现更高的压缩比,但会产生额外的CPU周期。

压缩(索引和journals日志):索引可以在内存和磁盘上压缩。WiredTiger利用前缀压缩来压缩索引,节省RAM使用以及释放存储IOP。默认情况下,使用Snappy压缩压缩journals日志。

多核可扩展性:随着CPU制造商缩小到更小的平版印刷,功耗变得越来越成问题,处理器趋势已转向多核架构,以维持摩尔定律的节奏。WiredTiger在设计时考虑了现代的多核架构,并提供跨多核系统的可扩展性。危险指针,无锁算法和快速锁存等编程技术可最大限度地减少线程之间的争用。线程可以执行操作而不会相互阻塞 - 从而减少线程争用,更好的并发性和更高的吞吐量。

WiredTiger允许用户为其读取指定隔离级别。读取操作可以返回大部分副本集已接受或提交到磁盘的数据视图。这样可以保证应用程序只读取在发生故障时仍然存在的数据,并且在将新的副本集成员提升为主要成员时不会回滚。

【以上关于wiredTiger存储引擎的介绍来自官方文档的一片博客:存储引擎

下面关于mongodb的存储引擎详细介绍来自官方文档:

文档级并发

WiredTiger使用文档级并发控制进行写操作。因此,多个客户端可以同时修改集合的不同文档。

对于大多数读写操作,WiredTiger使用乐观并发控制。WiredTiger仅在全局,数据库和集合级别使用意图锁。当存储引擎检测到两个操作之间的冲突时,会发生写入冲突,导致MongoDB透明地重试该操作。

一些全局操作(通常是涉及多个数据库的短期操作)仍然需要全局“实例范围”锁定。其他一些操作(例如删除集合)仍需要独占数据库锁。

checkpoint

在Checkpoint操作开始时,WiredTiger提供指定时间点(point-in-time)的数据库快照(Snapshot),该Snapshot呈现的是内存中数据的一致性视图。当向Disk写入数据时,WiredTiger将Snapshot中的所有数据以一致性方式写入到数据文件(Disk Files)中。一旦Checkpoint创建成功,WiredTiger保证数据文件和内存数据是一致性的,因此,Checkpoint担当的是还原点(Recovery Point),Checkpoint操作能够缩短MongoDB从Journal日志文件还原数据的时间。

当WiredTiger创建Checkpoint时,MongoDB将数据刷新到数据文件(Disk Files)中,在默认情况下,WiredTiger创建Checkpoint的时间间隔是60s,或产生2GB的Journal文件。在WiredTiger创建新的Checkpoint期间,上一个Checkpoint仍然是有效的,这意味着,即使MongoDB在创建新的Checkpoint期间遭遇到错误而异常终止运行,只要重启,MongoDB就能从上一个有效的Checkpoint开始还原数据。

当MongoDB以原子方式更新WiredTiger的元数据表,使其引用新的Checkpoint时,表明新的Checkpoint创建成功,MongoDB将老的Checkpoint占用的Disk空间释放。使用WiredTiger 存储引擎,如果没有记录数据更新的日志,MongoDB只能还原到上一个Checkpoint;如果要还原在上一个Checkpoint之后执行的修改操作,必须使用Jounal日志文件。

journal日志

WiredTiger使用预写日志的机制,在数据更新时,先将数据更新写入到日志文件,然后在创建Checkpoint操作开始时,将日志文件中记录的操作,刷新到数据文件,就是说,通过预写日志和Checkpoint,将数据更新持久化到数据文件中,实现数据的一致性。WiredTiger 日志文件会持久化记录从上一次Checkpoint操作之后发生的所有数据更新,在MongoDB系统崩溃时,通过日志文件能够还原从上次Checkpoint操作之后发生的数据更新。

压缩

使用WiredTiger,MongoDB支持对所有集合和索引进行压缩。压缩可以以额外的CPU为代价最大限度地减少磁盘的使用。

默认情况下WiredTiger存储引擎使用snappy方式压缩所有集合,前缀压缩方式压缩索引。

对于集合的压缩还可以使用zlib方式压缩。

storage:
joural:
enabled: true #启用journal日志,false为关闭
engine: wiredTiger #指定存储引擎
wiredTiger:
cacheSizeGB: 8 #来指定mongodb使用内存的多少-8G
engineConfig: #存储引擎的配置
journalCompressor: snappy #指定journal日志的压缩方式
indexConfig: #索引配置
prefixCompression: true #前缀压缩开启
collectionConfig:
blockCompressor: snappy #指定集合的压缩方式

内存使用

在上面提到过:【最大化可用缓存: WiredTiger最大限度地利用可用内存作为缓存来减少I / O瓶颈。使用了两个缓存:WiredTiger缓存和文件系统缓存。WiredTiger缓存存储未压缩的数据并提供类似内存的性能。操作系统的文件系统缓存存储压缩数据。当在WiredTiger缓存中找不到数据时,WiredTiger将在文件系统缓存中查找数据。】

mongodb从3.4版本开始默认使用内存为下面两个中的最大一个:

  • 50% of (RAM - 1 GB)
  • 256MB

默认情况下,WiredTiger对所有集合使用Snappy块压缩,对所有索引使用前缀压缩。压缩默认值可在全局级别配置,也可以在集合和索引创建时单独指定压缩级别。

wiredTiger内部缓存中的数据与磁盘格式使用不同的表示形式:

【官方文档总结--站位】

disk回收:

当从MongoDB中删除文档(Documents)或集合(Collections)后,MongoDB不会将Disk空间释放给OS,MongoDB在数据文件(Data Files)中维护Empty Records的列表。当重新插入数据后,MongoDB从Empty Records列表中分配存储空间给新的Document,因此,不需要重新开辟空间。为了更新有效的重用Disk空间,必须重新整理数据碎片。

WiredTiger使用compact 命令,移除集合(Collection)中数据和索引的碎片,并将unused的空间释放,调用语法:

db.runCommand ( { compact: '<collection>' } )
#在执行compact命令时,MongoDB会对当前的database加锁,阻塞其他操作。在compact命令执行完成之后,mongod会重建集合的所有索引

把已经含有数据的mongdb的存储引擎更改为WiredTiger

当前mongdb实例存储引擎为mmapv1,如下:

systemLog:
destination: file
logAppend: true
path: /data/mongod/log/mongod.log storage:
engine: "mmapv1"
dbPath: /data/db
journal:
enabled: true processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile # network interfaces
net:
port:
bindIp:

mmapv1的配置

#数据大小如下
> show dbs;
admin .078GB
local .078GB
mydb .453GB

开始更改mongdb实例的存储引擎:

1.备份原来的数据库文件:

[root@test2 data]# mkdir db_back          #创建备份目录
[root@test2 bin]# ./mongodump -o /data/db_back/ #备份数据
--09T17::54.684+ writing admin.system.indexes to
--09T17::54.685+ done dumping admin.system.indexes ( documents)
--09T17::54.685+ writing admin.system.version to
--09T17::54.686+ done dumping admin.system.version ( document)
--09T17::54.686+ writing mydb.test to
--09T17::57.676+ [###############.........] mydb.test / (63.6%)
--09T17::58.632+ [########################] mydb.test / (100.0%)
--09T17::58.632+ done dumping mydb.test ( documents)
[root@test2 bin]#

2.停止mongodb实例

kill `netstat -lntp |grep mongod | awk '{print $NF}' | cut -d "/" -f1`

3.修改配置文件

storage:
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB:
journalCompressor: none
collectionConfig:
blockCompressor: none
indexConfig
prefixCompression: false

4:把现在dbpath中的数据,改名备份起来!

[root@test2 data]# mv db db_mmapv1
[root@test2 data]# mkdir db #然后再重新创建一个db目录

5:启动mongodb实例

[root@test2 bin]# ./mongod -f ../conf/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process:
child process started successfully, parent exiting
[root@test2 bin]#

6:导入之前导出的数据

[root@test2 bin]# ./mongorestore --dir=/data/db_back/                    #导入数据
--09T17::10.586+ preparing collections to restore from
--09T17::10.599+ reading metadata for mydb.test from /data/db_back/mydb/test.metadata.json
--09T17::10.646+ restoring mydb.test from /data/db_back/mydb/test.bson
--09T17::13.546+ [########................] mydb.test .1MB/.4MB (37.0%)
--09T17::16.546+ [##################......] mydb.test .7MB/.4MB (78.5%)
--09T17::18.354+ [########################] mydb.test .4MB/.4MB (100.0%)
--09T17::18.354+ no indexes to restore
--09T17::18.354+ finished restoring mydb.test ( documents)
--09T17::18.354+ done
[root@test2 bin]# ./mongo #查看数据
MongoDB shell version v3.4.2
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.
Server has startup warnings:
--09T17::26.586+ I STORAGE [initandlisten]
--09T17::26.586+ I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
--09T17::26.586+ I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
--09T17::26.688+ I CONTROL [initandlisten]
--09T17::26.688+ I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
--09T17::26.688+ I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
--09T17::26.688+ I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
--09T17::26.688+ I CONTROL [initandlisten]
> show dbs
admin .000GB
local .000GB
mydb .077GB #数据占有空间明显变小了

比较两个存储引擎,数据目录文件的不同

[root@test2 db]# pwd
/data/db
[root@test2 db]# ls #当前正在使用的wiredTiger存储引擎
collection--.wt diagnostic.data index--.wt _mdb_catalog.wt storage.bson WiredTiger.lock
collection--.wt index--.wt index--.wt mongod.lock WiredTiger WiredTiger.turtle
collection--.wt index--.wt journal sizeStorer.wt WiredTigerLAS.wt WiredTiger.wt
[root@test2 db]# ls ../db_mmapv1/ #之前备份的mmapv1存储引擎的目录
admin. admin.ns diagnostic.data journal local. local.ns mongod.lock mydb. mydb. mydb. mydb.ns storage.bson _tmp
[root@test2 db]#
上一篇:【python】-- 多进程的基本语法 、进程间数据交互与共享、进程锁和进程池的使用


下一篇:mongodb 物理删除数据