MongoDB（引擎）关于存储引擎 WiredTiger storage engine

最新推荐文章于 2024-03-12 17:00:39 发布

weixin_33974433

最新推荐文章于 2024-03-12 17:00:39 发布

阅读量700

点赞数

文章标签：数据库运维 python

原文链接：https://my.oschina.net/u/435872/blog/1596625

版权

2019独角兽企业重金招聘Python工程师标准>>>

WiredTiger 在3.2版本成为mongodb的默认存储引擎。所以这里讲的就是WiredTiger了。

Document Level Concurrency

WiredTiger提供了document-level concurrency control 的写操作，这么说，多个client可以在同一时间内修改同一collection的不同文档。对于大多数读写操作，WiredTiger都会使用最佳的并发控制，在global、database、collection等级别上只使用了意向锁（intent lock）。如果存储引擎检测到两个操作冲突了，则导致mongodb将其中一个操作重新执行。

Snapshots and Checkpoints

MongoDB配置WiredTiger在每60秒或者2GB日志数据就创建一个checkpoint（快照）。在写入一个checkpoint时，前一个checkpoint仍然是有效的，所以在此时MongoDB如果崩溃了，还是可以回退到最新的有效checkpoint，并依靠日志来恢复最近的改变。在新的checkpoint成功变成有效的，之前的旧checkpoint pages就会被释放。

Journal

MongoDB在没有新的checkpoint生成之前，会持续地打日志，使用的是snappy compression library来压缩日志，但是也可以指定其他的压缩算法，这可通过storage.wiredTiger.engineConfig.journalConpressor来设置。甚至设置storage.journal.enabled=false来关闭日志系统，这样可以减少花费，但是所做的修改也就很危险。

MongoDB配置了WiredTiger在内存指定缓冲区中进行记录，等到达 128 kb 时再写到磁盘中去。将内存中的记录写入磁盘有下面一些条件：

每经过100ms。
新的checkpoint出现，或者日志数据到达2GB。
如果设置了write concern 的j:true选项，存储引擎立刻写入log file。

最小的log记录是128字节，如果等于小于128字节则不使用压缩。log file的大小规定为100M，所以存储引擎大约每100M的日志数据就创建一个log file，一般会预先创建一些log file（通常是在首次启动mongod实例之前，此功能可以关闭）。除非写操作特别多，否则一般情况下只会有两三日志文件。正常关闭mongod时会清空所有的日志文件，而非正常关闭则会留下一些文件。

如果在日志信息仍在内存缓冲区的时候mongd突然崩溃（如断电），这些日志数据就会丢失。最有可能丢失的就是崩溃前的100ms再加上写进日志文件的这一时间段。serverStatus
命令中有log的统计信息。

如果频繁写日志文件会导致效率的下降，这时可以将journal目录转移到其他文件系统中，就不会影响到数据库正常的读写操作效率。但这会带来的一个问题是，对数据库使用snapshot时不能够对这两个部分单独进行操作，而是需要使用fsyncLock()将数据库锁起来，等snapshot操作都完成之后再使用fsyncUnlock()解锁。

Compression

MongoDB提供collection压缩和index压缩。默认是使用block compression来压缩collection，和使用prefix compression来压缩index。
对于collection，可以更改指定压缩算法或者禁用压缩，使用storage.wiredTiger.collectionConfig.blockCompressor设置即可。
对于index，可以使用storage.wiredTiger.indexConfig.prefixCompression来关闭prefix压缩。
甚至，针对每个collection和index的压缩，可以使用具体的压缩算法，参考create-collection-storage-engine-options和db.collection.createIndex()。不过，默认的压缩算法在大多数平均情况下都有出色的表现，很好平衡了效率和执行需求。

Cache

MongoDB使用了双Cache，一个是WiredTiger Cache，一个是文件系统Cache。默认情况下，从3.2起WiredTiger将使用60%的RAM减去1GB或者使用1GB，取其中的大者。在3.0中要么使用1GB，要么50%的物理内存，取其中的大者。可以参考storage.wiredTiger.engineConfig.cacheSizeGB
和 --wiredTigerCacheSizeGB进行配置Cache大小，但是要避免超过默认的大小，值得注意的是，storage.wiredTiger.engineConfig.cacheSizeGB仅仅限制了WiredTiger Cache的大小，这只是mongod的一部分，而不是mongod所使用内存的上限。MongoDB假设了这只有一个instance在一个node上而已，如果有多个的话，更加需要调整一下Cache大小。

本引擎会自主决定哪些数据保存在内存中，哪些数据会刷新到磁盘中。而且，两种引擎不能混淆使用，即用Wired Tiger创建的数据库不能用MMAPv1去打开，这是两种不同的文件存储方式以及管理方式的。

关于MMAPv1 storage engine

每个文档中的所有field都位于同一块连续的内存中，而storage engine在为文档申请内存块的时候都是会留出一部分内存供后来填充用的，即为每个文档申请的实际内存大小都会大于其真实大小（一般是以2的指数增长）。当填充的多余部分内存用光了之后，就会引起重新为该文档申请新内存的操作。

Document Level Lock

本引擎也提供了锁的机制，对于document级别的写操作保证了不会冲突，而是进行有序的执行。

MongoDB 系统的限制与门槛

BSON文档
最大BSON文档的大小是16MB，如果超过这个限制，可以尝试使用GridFS API来存储大文件。
嵌套深度
MongoDB目前支持的内嵌文档的嵌套深度是不超过100层。
Namespace 长度
支持的最大的集合namespace为120 Bytes，其中包括了数据库名称，还有dot等等，即<database>.<collection>。
Namespace 的数量
在3.0之前使用的默认存储引擎就会有一些限制，比如Namespace的数量受限制于namespace文件的大小，现在的默认存储引擎WiredTiget就没有这些限制了。
Namespace 文件的大小
之前MMAPv1默认的namespace文件的大小限制为16MB，但是可以通过nsSize来配置它，只要不超过2047字节。但WiredTiger现在没有这个限制。
固定集合Capped Collection。如果是通过max参数来创建的固定集合，那么集合大小不能超过232。而在创建固定集合的时候没有指定集合大小，那么集合中可以包含任意多个文档。
MMAPv1存储引擎限制了每个数据库不能够超过16000个数据文件，即不超过32TB，可通过storage.mmapv1.smallFiles来设置为8TB。
MMAPv1不能够处理数据大小超过操作系统的虚存空间大小。而WiredTiger没有此限制。
MMAPv1限制了数据库中的文档数量，与索引数量和namespace文件大小相关。WiredTiger没有此限制。
针对具体情况，可以使用no padding模式的申请内存方式，这样每次申请的内存大小就刚刚好了。

GridFS 大文档存储

如果存储的文档超过了16MB，那么就需要选择这种方式来存储了。将大文档分割成小部分或chunk，然后分别作为小文档存储起来，分别存储于两个集合collection中，其中一个集合存储的是文件chunk，另一个存储的是元数据（这里有详细介绍 GridFS Collections）。默认的chunk大小为255kB，即除了最后一块，其他都是255kB（自从v 2.4.10改为255kB的）。
在需要查询大文件的时候，引擎会重组所有的chunk。可以针对文件中的某个范围进行查询，比如跳过视频的片头。这种存储方式也支持16MB以下的文档存储的，当经常需要查询文件中的某个范围的时候就能派上用场了。

一般情况下，GridFS使用两个分别名为fs.files和fs.chunks的文件来保存所有的大文件信息。一对文件称之为“桶”，可以创建多对，也可以选择其他名称。chunks中的每个文档都是一个chunk，就像下面这样：

{ 
  "_id" : <ObjectId>, 
  "files_id" : <ObjectId>,
  "n" : <num>,   //sequence of this chunk
  "data" : <binary>
}

files中的每个文档代表着GridFS中的一个大文件。除了部分是可选的，文档格式大致如下：

{ 
  "_id" : <ObjectId>, 
  "length" : <num>, 
  "chunkSize" : <num>, 
  "uploadDate" : <timestamp>, 
  "md5" : <hash>, 
  "filename" : <string>, 
  "contentType" : <string>, 
  "aliases" : <string array>, 
  "metadata" : <dataObject>
}

那效率如何呢？GridFS对每个chunks和files集合使用了index，驱动一般会自动创建这些索引，提升速度就只能依靠这些索引了，也可以自定义一些新索引。

转载于:https://my.oschina.net/u/435872/blog/1596625