mongodb 系列 ~ WT引擎

  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。

 7  WT 引擎文件组成

     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