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将在文件系统缓存中查找数据。

在移动到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: 27017
  bindIp:

mmapv1的配置

#数据大小如下
> show dbs;
admin  0.078GB
local  0.078GB
mydb   0.453GB

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

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

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

2.停止mongodb实例

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

3.修改配置文件

storage:
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4
      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: 14436
child process started successfully, parent exiting
[root@test2 bin]#

6：导入之前导出的数据

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

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

[root@test2 db]# pwd
/data/db
[root@test2 db]# ls                               #当前正在使用的wiredTiger存储引擎
collection-0-1470999101568290858.wt  diagnostic.data                 index-4-1470999101568290858.wt  _mdb_catalog.wt  storage.bson      WiredTiger.lock
collection-2-1470999101568290858.wt  index-1-1470999101568290858.wt  index-6-1470999101568290858.wt  mongod.lock      WiredTiger        WiredTiger.turtle
collection-5-1470999101568290858.wt  index-3-1470999101568290858.wt  journal                         sizeStorer.wt    WiredTigerLAS.wt  WiredTiger.wt
[root@test2 db]# ls ../db_mmapv1/                 #之前备份的mmapv1存储引擎的目录
admin.0  admin.ns  diagnostic.data  journal  local.0  local.ns  mongod.lock  mydb.0  mydb.1  mydb.2  mydb.ns  storage.bson  _tmp
[root@test2 db]#

posted @ 2018-11-09 16:53 夜间独行的浪子阅读(8745) 评论(0) 编辑收藏举报

刷新页面返回顶部