曦轩_个人页

MongoDB 执行计划 & 优化器简介 (上)

最近，由于工作需求去了解一下Query是如何在MongoDB内部进行处理，从而丢给存储引擎的。里面涉及了Query执行计划和优化器的相关代码，MongoDB整体思路设计的干净利落，有些地方深入挖一下其实还是能有些优化点的。本文会涉及一条Query被parse之后一路走到引擎之前，都做了那些事情，分析基于MongoDB v3.4.6代码。由于篇幅过长，文章分为上下两篇，分别介绍执行计划 & 优化器和

RocksDB TransactionDB事务实现分析

## 基本概念 #### 1. LSN (log sequence number) RocksDB中的每一条记录(KeyValue)都有一个LogSequenceNumber(后面统称lsn)，从最初的0开始，每次写入加1。该值为逻辑量，区别于InnoDB的lsn为redo log物理写入字节量。 这个lsn在RocksDB内部的memtable中是`单调递增`的，在WriteA

RocksDB事务实现TransactionDB分析

本文主要对RocksDB中事务实现TransactionDB做分析，设计事务并发、隔离级别、MVCC等实现细节

MongoDB WiredTiger 存储引擎cache_pool设计 (下) -- 实践篇

MongoDB WiredTiger 存储引擎cache_pool设计 (上) -- 原理篇

## 1. MongoDB 多引擎体系 -- WiredTiger MongoDB v.3.0之前的版本，默认使用`MMAP(MMap引擎)`方式对内存中的数据进行写盘存储，遭受了很多诟病。比如`并发受限的表锁、不支持压缩、不可控的IO`操作等，MMAP甚至不能称作一个完整的存储引擎(笔者的个人观点)，对数据(Btree的数据页、索引页)的操作甚至要依赖os的mmap(in_page_ca