“Mongodb 存储引擎笔记”的版本间的差异
来自Dennis的知识库
Dennis zhuang(讨论 | 贡献) (→MMAPv1 引擎) |
Dennis zhuang(讨论 | 贡献) (→概述) |
||
第9行: | 第9行: | ||
* 文档大小统计, totalSize = indexSize + dataSize, 而 storageSize 是实际占用大小,包括未使用的空间。 | * 文档大小统计, totalSize = indexSize + dataSize, 而 storageSize 是实际占用大小,包括未使用的空间。 | ||
− | === WT 引擎配置项目 === | + | === WT 引擎 === |
+ | |||
+ | * 文档级别锁,部分操作如删除 collection 仍然需要 db 级别的独占锁,以及一些跨多个数据库的操作,需要 instance 级别锁。 | ||
+ | * MVCC 隔离。 | ||
+ | * checkpoint 机制,每个 60 秒创建一个检查点,加快恢复,哪怕没有启用日志。 | ||
+ | * uses write-ahead transaction log in combination with checkpoints to ensure data durability | ||
+ | |||
+ | |||
+ | ==== WT 引擎配置项目 ==== | ||
<code> | <code> |
2017年5月23日 (二) 06:56的版本
目录 |
概述
- 同一个 replica set 可以使用不同的存储引擎。
- 默认 wiredtiger 使用 snappy block compression;zlib 压缩算法,索引使用 prefix compression。
- Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either: 50% of RAM minus 1 GB, or 256 MB.容器使用需要调整 storage.wiredTiger.engineConfig.cacheSizeGB
- WT 引擎 60秒或者超过 2g 日志数据,写入一次 checkpoint
- WT日志数据写入磁盘,从3.2开始是50毫秒间隔。
- 文档大小统计, totalSize = indexSize + dataSize, 而 storageSize 是实际占用大小,包括未使用的空间。
WT 引擎
- 文档级别锁,部分操作如删除 collection 仍然需要 db 级别的独占锁,以及一些跨多个数据库的操作,需要 instance 级别锁。
- MVCC 隔离。
- checkpoint 机制,每个 60 秒创建一个检查点,加快恢复,哪怕没有启用日志。
- uses write-ahead transaction log in combination with checkpoints to ensure data durability
WT 引擎配置项目
storage: wiredTiger: engineConfig: cacheSizeGB: 内部数据缓存大小,从 3.4 开始,是 50% 可用内存减去 1G,或者 256MB。 journalCompressor: 日志压缩,默认压缩算法 snappy,可以选择 zlib。 directoryForIndexes: 默认为 false,如果为 true,将数据和索引会分成两个目录 index/collection 存储。 collectionConfig: blockCompressor: 数据压缩算法,默认也是 snappy indexConfig: prefixCompression: 默认为 true,对索引使用前缀压缩。可以节省内存和磁盘占用。
MMAPv1 引擎
- 使用 mmap() 将文件映射到内存。
- 写数据是 60 秒,写日志是间隔 100 毫秒,通过 storage.syncPeriodSecs 和 storage.journal.commitIntervalMs 修改。
- 文件比数据更大,因为:
- 预分配文件,可以通过 storage.mmapv1.smallFiles 来减少初始文件大小,并限制最大 512m
- oplog.rs 文件,也是预先创建的 capped collection,默认占用 5% 的磁盘空间(64位安装),通常不建议改这个。
- 日志文件
- 空记录,已删除的 collection 和文档都会保留在文件里。mongodb 会复用这些空间的,但是不会归还给 os。为了更有效的使用这些空间,你可以减少碎片,使用 compact 命令。compact 需要额外的 2g 磁盘空间来运行。compact 只是减少文件碎片,但是也不会归还空间给 os,想要归还可以用 repairDatabase 命令。repairDatabase 需要更大的磁盘空间来运行——等于你当前的数据集合大小,加上 2g。归还也可以通过重新同步来,特别是 secondary 成员。
- page faults,发生在写入或者读取,当要写或者读的部分不在内存的时候发生,通常是因为内存不足引起的。分成 soft 和 hard, hard 读磁盘, soft 只是在 os 的文件缓存里移动。
- 在更新的时候,如果文档增大, 文档可能需要在 disk 搬迁,为了减少这种影响, mongodb 使用 padding 对齐技术。对齐是自动的,也不建议手动。
- 3.0 开始,MMAPv1 用的是 power of 2 大小做对齐,也可以在创建 collection 或通过 collMod 命令修改为 noPadding 策略。
MMAPv1 配置项目
storage: mmapv1: preallocDataFiles: 默认false,是否预分配文件 nsSize: 默认16mb, namespace 文件(.ns结尾)的默认大小,每个collection和index作为一个 namespace, 16MB 可以容纳 24000 个 namespace。 quota: enforced: 默认false,是否限制单个 db 的最大数据文件数目,如果设置了,最大为8个个文件,可以通过 maxFilesPerDB 修改 maxFilesPerDB: 默认8,见 enforced smallFiles: 默认false,如果设置为 true,将减少数据文件初始大小,并限制最大为 512m,同时减少日志文件从 1g 到 128m。 journal: debugFlags: 测试 debug flags commitIntervalMs: 被 storage.journal.commitIntervalMS 替代,日志落盘间隔,默认是 100ms。