1 版本支持 WT 引擎 3.2版本之后,默认引擎
2 锁粒度
0 读是共享锁 写是排它锁
1 针对写锁:WT引擎锁粒度是基于文档级别,同一DB下的不同文档可以并发访问,但是当多个写操作修改同一个文档时，必须以序列化方式执行,如果该文档正在被修改，其他写操作必须等待，直到在该文档上的写操作完成之后，其他写操作相互竞争，获胜的写操作在该文档上执行修改操作。
2 针对读锁: 多个读操作是可以并发的,但是当有写操作时就会阻塞读操作,直到完成
3 参数与特性
config- cache_size=512M
1 cacheSizeGB 指的就是Cache size，包括数据和索引。
2 MongoDB在做诸如聚合、排序、连接管理等操作时需要额外的内存。因此，必须确保有足够的内存可供使用，否则，MongoDB进程有被OOM killer杀死的风险。
3 查看状态命令 db.serverStatus().wiredTiger.cache
4 cacheSizeGB默认值是(RAM – 1GB) / 2 推荐设置
config-directoryForIndexes:true
1 将数据和索引进行分开目录存储
config-blockCompressor:snappy
1 snappy消耗cpu少,zlib压缩率更高,但是消耗更多cpu config-prefixCompression: true
4 配置文件一览
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 10
directoryForIndexes: true
collectionConfig:
blockCompressor: zlib
indexConfig:
prefixCompression: true
5 事务三种隔离级别
RU RC 串行化
6 恢复机制
核心机制:
一是将内存里面发生修改的数据写到数据文件进行持久化保存，确保数据一致性；
二是实现数据库在某个时刻意外发生故障，再次启动时，缩短数据库的恢复时间
生成checkpoint点时机
- 按一定时间周期：默认60s，执行一次checkpoint；
- 按一定日志文件大小：当Journal日志文件大小达到2GB（如果已开启），执行一次checkpoint；
- 任何打开的数据文件被修改，关闭时将自动执行一次checkpoint。
1 db目录-包含默认库(local,admin,config)
2 jonurnal目录-journal
3 diagnostic.data目录-收集服务器信息目录,暂时无法手动进行分析
4 WiredTiger.wt文件是mongoDB的元数据文件，存储了其他数据库表的元数据信息。
5 _mdb_catalog.wt ： 里存储了所有集合的元数据，包括集合对应的WT table名字，集合的创建选项，集合的索引信息等，WT存储引擎初始化时，会从_mdb_catalog.wt里读取所有的集合信息，并加载元信息到内存
6 sizeStorer.wt-存储所有集合的容量信息,如文档数,文档总大小等-感觉像myisam的元数据
7 WiredTiger WiredTiger.turtle 都是引擎配置文件-引擎启动的相关加载内存参数(个人理解)
8 lock 分为mongo和wt 理解的就是内部wt也启动一个相应进程、
总结 大体分为 元数据存储信息文件和引擎配置文件和启动lock文件
八 WT和tickets
1 WiredTiger使用
tickets来控制可以同时被存储引擎处理的读/写操作数。默认值都是128 2 db.serverStatus().wiredTiger.concurrentTransactions 可以观察读写tickets的消耗情况
3 db.adminCommand( { setParameter: 1, wiredTigerConcurrentRead/WriteTransactions: xx } ) 进行调节读写操作数限制
九 内存结构
1 WT引擎内存cachesize推荐为总内存的一半,剩下的内存会优化数据库服务
OS FILE->FS CACHE->WT CACHE(这层才是可读的数据)
2 注意脏页的占比,最好不要超过5%->通过mongostat观察分析dirty占有率->ditry page
如果脏页比太高,要么提高磁盘性能 要么做业务限流
3 注意 读缓存使用率不能超过80%->通过mongostat观察分析used占有率-> clean page