MongoDB(引擎)关于存储引擎 WiredTiger storage engine

2017/12/29 13:30
阅读数 771
 

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-optionsdb.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.filesfs.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,驱动一般会自动创建这些索引,提升速度就只能依靠这些索引了,也可以自定义一些新索引。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部