1. MongoDB 多引擎体系 -- WiredTiger
MongoDB v.3.0之前的版本,默认使用MMAP(MMap引擎)方式对内存中的数据进行写盘存储,遭受了很多诟病。比如并发受限的表锁、不支持压缩、不可控的IO操作等,MMAP甚至不能称作一个完整的存储引擎(笔者的个人观点),对数据(Btree的数据页、索引页)的操作甚至要依赖os的mmap(in_page_cache)刷盘,并且os的page 4k为IO单元对数据库本身就是不友好的,再加上其实数据库自身应该比OS更懂数据的layout,比如哪些是热数据,哪些是索引(较数据页更需要留在内存里)来组织LRU。
MongoDB v3.0版本一个重大的更新是加入了WiredTiger,也使得Mongo代码架构里支持了StorageEngine的抽象层(接口层更多细节,参见@林青 大神的文章http://www.atatech.org/articles/56080),为后面RocksDB、Memory等做了铺垫。WiredTiger引擎(后面简称wt引擎)面向多核、Page IO优化做了很多工作(比如加入HazardPointer、分离锁,为了增大并发内存Page结构和磁盘Page结构解耦以及支持变长Page-面向大吞吐设备的IO适配)。很多测试报告显示使用了wt之后Mongo的性能有很大提升。本文通过项目里对wt的子模块进行了解,主要关注cache相关设计,更多wt引擎相关请见后续文章。
2. WiredTiger整体架构
wt引擎是基于btree索引实现的,和InnoDB引擎有很多设计和名词上相似的地方,大家可以类比。wt对外的api接口是以table(类比Mysql的表和MongoDB的collection) + kv存储形式提供的,key是int64_t类型(类似MongoDB的_id),value是byte[]类型(这里通过byteArray来实现MongoDB上层schema free的bson结构)。上层通过cursor方式来实现数据的search/insert/update/remove操作。内部通过journal_log、checkpoint、cache(btree/cache_evict)、block_manager子模块协调访问IO存储(这里主要列出本文相关模块,sweep、transaction、bloom/lsm等未列出)
session 模块,负责和wt引擎上层交互的句柄,每个session会关联多个cursor,cursor属于一个session
cache 模块,主要有内存中的btree page(数据页,索引页,溢出页)构成
evict 模块,如果cache内存紧张,触发cache淘汰,便利btree,并根据lru排序淘汰
Journal 模块,WAL log,类似InnoDB的redolog,保证数据持久化,通过定时和定量阈值来flush
checkpoint 模块,类似InnoDB checkpoint机制,异步执行btree刷盘,checkpoint之后通知log模块更新log_ckpt_lsn(lsn概念和InnoDB一致)
block manager模块,负责磁盘IO的读写,cache、evict、checkpoint模块均通过该模块访问磁盘
3. cache pool
wt有个shard cache(cache pool)的概念,MongoDB并未使用。因为cache本身的功能和InnoDB buffer pool类似,这里暂且把wiredTiger的cache称作cache pool也算合理。cache pool主要存放内存中btree page为单位的页,页类型及cache pool相关运行参数可见 http://gitlab.alibaba-inc.com/dds/dds-documents/blob/develop/社区教程文档/wiredTiger_cache_运行参数.md,cache的读入和淘汰写入都是以page为单位(基本上所有存储引擎都是如此)。基本结构如图:
(图片来自WiredTiger Github官方wiki)
基本page类型:root_page(btree根节点), internal_page(索引页), leaf_page(数据页, 叶子节点)
结构:每个page被包含在一个REF里面(可以看做是page的容器), root_page/internal_page 包含一个refArray数组,包含下层节点的指针,home(红色线)指向父节点
wt的btree相较于InnoDB有些不一样的地方(详细结构见https://github.com/wiredtiger/wiredtiger/wiki/Reconciliation-overview),InnoDB的内存中的page结构和磁盘上的page结构是一样的,都是紧凑的binary,修改产生的脏页会in place的更新到原有磁盘的page上, 这样的好处是刷盘时,直接把16k的page,按字节数组的方式一次性刷下去即可。
WiredTiger将磁盘上的page读上来之后,会在内存中构建成另外一种复杂结构,这个结构较binary结构好处就是可以重新组织或嵌入具有更高并发性的结构,比如wt使用的HazardPointer,对page刷盘时,其实就是对该页的HazardPointer的'写获取'操作,并且在刷盘时保持 原有磁盘上的page不变,直接找一个新的page空间,把内存里page的修改(保存在page的modify_list中)变成磁盘page的结构写入 ,这个page刷盘的过程称为reconcile(wt里很多生僻的名词)。这样的好处是对不修改原有page,就能更好的并发,并且不像InnoDB一样,需要一个DoubleWriteBuffer保证非disk block 512B写时对原有页可能发生conrrupt。(这里有个小问题,如果是更新都写入新page,如果每次都只是更新page中很小的数据,数据的空间占用会比较大,待验证?!)
WiredTiger也提供了类似InnoDB的checkpoint机制:每个客户端的写请求会先通过journal进行持久化,这里类似redolog都是顺序IO,并且提供了类似innodb_flush_log_at_trx_commit的{j: true}参数。那么,在wt里面产生的cache脏页,就用在后台'慢慢'的刷。当写入到一定程度或者时间后,或作一次checkpoint把cache中的数据刷入磁盘,并且做fsync, 然后通知journal更新checkpoint offset,即可丢弃之前的journal。这里在每次checkpoint后,都会产生一个新的root page(也就是一个新的btree,一个bree对应一个物理文件),同时会在journal写入这个checkpoint事件。
3.1 cache pool 刷盘
写请求写入journal后就可以保证Durability,后续wt引擎遇到如下情况时,会触发cache的刷盘动作:
checkpoint
checkpoint时会遍历所有btree,把btree的所有leaf_page做reconcile操作,然后对重新分配root_page,触发的阈值包括:
journal容量达到阈值,默认2G
每隔60s执行一次
cache evict
evict线程会根据现在cache的使用量,分段扫描一些page(可能是drity page或clean page),进行淘汰,释放cache空间,主要受如下4个参数影响:
eviction_trigger:cache总使用量达到该百分比时,触发evict操作
eviction_target:触发上述参数evict后,需要将cache总使用量降低到该百分比水位,才停止evict
eviction_dirty_trigger:cache脏页使用量到该百分比时,触发evict操作
eviction_dirty_target:触发上述参数evict后,需要将cache脏页使用量降低到该百分比水位,才停止evict
(WiredTiger v2.8.1 一般情况使用情况eviction_trigger > eviction_target > eviction_dirty_trigger > eviction_dirty_target,WiredTiger v2.9之后版本对着四个参数的意义进行了调整!)
application evict
如果写入量一直很大,那么用户请求处理线程就会阻塞并参与evict的执行,这也是一种保护措施,当IO量很大时,做到同步阻塞上面的请求
4 cache evict
4.1 evict线程模型
cache evict在wt v2.8.1早期版本时,采用的是server-worker模型,1个server线程负责扫描btree找到一些page,然后进行lru排序,放入一个evict_queue中,再由worker线程消费,进行page evict动作。后面v2.8.1在MongoDB v3.2.9这个版本中,对线程模型进行了升级, 将server线程和worker线程合并(worker通过抢一把evict_pass_lock锁来成为server),相当于N个worker线程,同一时刻,有一个worker会成为server,负责执行evict_pass(扫描btree,并填充evict_queue)的工作,较少了切换的代价 。并且把原来单一的evict_queue变成了两个,降低了server、worker之间操作一个queue的概率减少冲突,增加了并发。
虽然线程模型做了调整,但从功能上还是server-worker的模式,见下图:
4.2 Btree扫描策略
每次evict_server执行cache pass是对所有btree的一次扫描,会根据当前cache情况最多扫描100个page出来。btree的扫描是迭代的,结束时会记录当前扫描道德btree的位置,下次继续从这个地方开始walk,每个btree最多扫描出10个page,如果这个btree被exclusive独占,如checkpoint正在访问这个btree,则跳过 ,这是为了让btree所有page都有可能被扫描到。如果扫描了足够多的page,则会停止本次cache pass,进入page的evict阶段。
这个扫描策略应该可以page尽可能全的被覆盖,但其实不具备LRU的特性(evict_queue里的page排序是基于LRU,也就是说扫描出来的page是会使用LRU)。如果看一下HBase或者InnoDB的分级扫描策略,就会感觉wt引擎的这种阶段性扫描在某些场景下还是不够友好的。比如 InnoDB的分级cache,会把buffer pool中的page list分成两部分,new_list和old_list,分别占5/8和3/8左右,新访问使用的page会在old_list里,如果这个page被再次访问到,则移动到new_list,如不访问则可能在old_list里被淘汰掉 。这就防止了select * from table类似这种fullScan时对buffer pool的污染 (详情可参考 http://dev.mysql.com/doc/refman/5.6/en/innodb-buffer-pool.html ),这里wt引擎其实做的还有欠缺。
4.3 LRU策略
扫描完成后的evict_queue,需要对每个里面page做评分排序,每个page的评分由page->read_gen(可理解成page的存活周期,如果经历过cache淘汰越多,但没被淘汰,就越高), 以及page类型共同决定,见代码:
/* * 获得page的评分,分数越低越容易被淘汰掉
*/
static inline uint64_t
__evict_read_genconst WT_EVICT_ENTRY *entry
WT_BTREE *btree
WT_PAGE *page
uint64_t read_gen
btree entry-btree
page entry-ref-page
// 周期最老的页,需要马上evict,给最低分WT_READGEN_OLDEST
page-read_gen WT_READGEN_OLDEST
WT_READGEN_OLDEST
// 如果dhandlebtree文件已经要被回收,同样给最低分
WT_PAGE_IS_INTERNALpage
F_ISSETbtree-dhandle, WT_DHANDLE_DEAD
WT_READGEN_OLDEST
// 如果page为空,也给最低分
__wt_page_is_emptypage
WT_READGEN_OLDEST
// 如果是internal page索引页, 则加上一个倾斜分数1000000分,
// 这里是希望索引页尽量不淘汰
read_gen page-read_gen + btree-evict_priority
WT_PAGE_IS_INTERNALpage
read_gen WT_EVICT_INT_SKEW
read_gen
按评分排序后,得到一个分数从小到大的有序队列,这个时候需要计算candidate(evict_page是即将被淘汰的页,candidate page是本次决定淘汰的页,evict > candicate),继续上代码:
FLD_ISSETcache-state, WT_EVICT_PASS_AGGRESSIVE WT_EVICT_PASS_WOULD_BLOCK
// 此时cache空间已经非常紧张了,进入aggressive模式或者application用户
// 线程淘汰模式了,则把全部evict_page变成candidate_page
evict_queue-evict_candidates entries
// 寻找第一个不是WT_READGEN_OLDEST的分数
read_gen_oldest WT_READGEN_OLDEST
candidates candidates entries ++candidates
read_gen_oldest
__evict_read_gen
evict_queue-evict_queuecandidates
read_gen_oldest WT_READGEN_OLDEST
// 此处意味着全部page的分数都是WT_READGEN_OLDEST,则全部变成
// candidate
read_gen_oldest WT_READGEN_OLDEST
evict_queue-evict_candidates entries
candidates entries /
// 如果第一个不是WT_READGEN_OLDEST的分数位置是在
// 中间位置或中间偏后面的位置,则直接取到这个点
evict_queue-evict_candidates candidates
cache-read_gen_oldest read_gen_oldest
// 去一个适中的值,差不多在这个点的值和最后点的值得3/4处
// 也就是说在当前这个点到末尾之间去一个值作为平衡点
cutoff
* read_gen_oldest + __evict_read_gen
evict_queue-evict_queueentries - /
// 在至少10%和至多50%间找一个小于cutoff的边界作为
// candidate数量
candidates + entries /
candidates entries /
candidates++
__evict_read_gen
evict_queue-evict_queuecandidates
cutoff
evict_queue-evict_candidates candidates
4.3 Cache 现存问题及CacheHang问题
上述分析了Cache相关的设计,其实可以看出evict还是有些精巧的地方,单还不够完善,尤其是在cache evict和checkpoint同时发生,或者evict_server不能找到可以evict的page时的退让策略,触发了一些线上问题,本文的下半节《MongoDB WiredTiger 存储引擎cache_pool设计 (下) -- 实践篇》将对次进行深入讨论
还没有评论,来说两句吧...