存储 on codedump notes

sqlite3.36版本 btree实现（五）- Btree的实现

Tue, 01 Feb 2022 15:55:40 +0800

《sqlite3.36版本 btree实现》系列文章：

概述 #

前面的内容里，详细介绍了页面管理器部分的内容，回顾一下页面管理器和Btree模块的分工：

页面管理器：提供页面级别的物理管理，如缓存、读取、写入、页面备份等。
Btree：根据btree数据结构提供页面在逻辑上的组织，以及单个页面内的划分。

还记得最开始，研究生产级别btree实现时的几个疑问：

数据库教科书中，演示btree算法时，使用的都是定长的简单数据。实际应用中，存储的数据都是变长的，那么应该如何存储变长的数据呢？
如果一行数据的大小，超过了一个物理页面的大小，又该如何处理？
删除一行数据之后，它留下的空间如何回收利用？而回收利用时，不可避免的会出现碎片的问题，比如原先10字节的数据被回收，用来存储9字节的数据，多出来的1字节数据就被浪费了，碎片问题应该如何解决？

这些问题，都与“一个物理页面内数据如何组织”这个核心问题息息相关，带着这些问题展开btree实现的讨论。

在下文中，不会讨论btree算法的细节，这部分不熟悉的，可以回看之前的文章或者教科书：

物理页面的数据组织 #

数据表的逻辑组织和页面类型 #

在展开具体的格式讨论之前，有必要先了解一下数据库文件的大体结构，已经不同的页面类型。

sqlite中所谓的数据库文件是单一文件，按照物理页面（2的次方）的大小来划分为多个页面。其中，每个表在数据库文件中是一棵btree的结构来组织，而不同类型的btree还区分了不同的页面。

比如下图中，将平面的数据库文件，按照颜色划分成存储两个表的btree：

数据库文件的物理页面组织和逻辑页面结构

在上图中：

上半部分表示，在物理的组织上，一个数据库文件以一个物理页面为基本单位来存储。
下半部分表示，在逻辑的组织上，不同的表都有自己的btree树形结构，这是物理页面在逻辑上的组织方式。

因为每个表都有自己的btree树形结构，如果每个表都有一个对应的根页面编号，比如图中的两个表，对应的树形结构中，根节点所在的页面分别是1和2。

接着来看不同的页面类型，以及存储上的差异。

以一个例子来说明，创建以下的数据库，插入数据，以及索引：

// 创建数据库COMPANY
CREATE TABLE COMPANY(
   ID             INT      NOT NULL,
   NAME           TEXT    NOT NULL,
   AGE            INT     NOT NULL,
   ADDRESS        CHAR(50),
   SALARY         REAL
);

// 创建索引
CREATE INDEX id_index ON COMPANY (id);

// 插入2条数据
INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) VALUES (1, 'Paul', 32, 'California', 20000.00 );
INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY)
VALUES (2, 'Allen', 25, 'Texas', 15000.00 );

// 查询数据
sqlite> select * from COMPANY;
1|Paul|32|California|20000.0
2|Allen|25|Texas|15000.0

// 查询rowid和数据
sqlite> select rowid,* from COMPANY;
1|1|Paul|32|California|20000.0
2|2|Allen|25|Texas|15000.0

在上面的流程里：

sqlite3.36版本 btree实现（四）- WAL的实现

Thu, 06 Jan 2022 21:48:18 +0800

《sqlite3.36版本 btree实现》系列文章：

概述 #

前面两节，分别讲解了sqlite中写入事务时的并发控制框架，以及journal备份文件的实现机制。

回忆一下journal备份文件的实现：

每次一个新的写事务开始之前，要首先写journal文件的文件头。
写事务过程中，如果修改了哪个页面，在修改之前需要首先将这个页面的内容写入到journal文件中。
写事务完成后，在同步所有缓存中被修改的页面到数据库文件之前，要首先将journal文件中的所有修改同步到磁盘，然后再修改数据库文件。

可以看到，journal备份的整个流程都较为原始，性能不高，所以在sqlite 3.7.0版本（SQLite Release 3.7.0 On 2010-07-21，2010-07-21）中，引入了另一种备份机制：WAL（Write Ahead Log）。

本节首先介绍WAL的实现原理，然后再展开其具体的实现。

WAL工作原理 #

从前面journal的实现中可以看到，写入journal文件中的内容，是待修改页面修改之前的内容，而WAL则相反：被修改的页面内容首先写入到WAL中。

用sqlite官网的文字来说，WAL文件的定义是这样的：

The write-ahead log or “wal” file is a roll-forward journal that records transactions that have been committed but not yet applied to the main database.

sqlite3.36版本 btree实现（三）- journal文件备份机制

Wed, 22 Dec 2021 19:15:31 +0800

《sqlite3.36版本 btree实现》系列文章：

概述 #

在上一节中（sqlite3.36版本 btree实现（二）- 并发控制框架），已经讲解了sqlite中的并发控制机制，里面会涉及到一个“备份页面”的模块：

备份所有在一个事务中会修改到的页面。
出错时回滚页面内容。

里面也提到，有两种备份文件的机制：journal文件，以及WAL文件。今天首先讲解journal文件的实现，它的效率会更低一些，也正是因为这个原因后续推出了更优的WAL机制。

journal文件格式 #

journal文件的文件名规则是：与同目录的数据库文件同名，但是多了字符串“-journal”为后缀。比如数据库文件是“test.db”，那么对应的journal文件名为“test.db-journal”。

文件头 #

偏移量	大小	描述
0	8	文件头的magic number: 0xd9, 0xd5, 0x05, 0xf9, 0x20, 0xa1, 0x63, 0xd7
8	4	journal文件中的页面数量，如果为-1表示一直到journal文件尾
12	4	每次计算校验值时算出来的随机数
16	4	在开始备份前数据库文件的页面数量
20	4	磁盘扇区大小
24	4	journal文件中的页面大小

这里大部分的字段都自解释了，不必多做解释，唯一需要注意的是随机数，因为这是用来后续校验备份页面的字段，这将在后面结合流程来说明。

sqlite3.36版本 btree实现（二）- 并发控制框架

Sat, 18 Dec 2021 15:25:05 +0800

《sqlite3.36版本 btree实现》系列文章：

概述 #

按照之前起步阶段对sqlite btree整体架构的分析，“页面管理模块”分为以下几个子模块：

页面缓存管理。
页面备份，又分为以下两种实现：
- journal文件。
- WAL文件。
页面管理模块。

前面一节讲完了“页面缓存管理”的实现，按照自下往上的顺序，就应该到“页面备份”了。“页面备份”核心的工作是：在真正修改页面内容之前，将还未修改的页面内容备份，这样一旦系统在事务过程中宕机崩溃，就可以用这部分内容回滚还未落盘的事务修改，让系统回到一个正确的状态。

“页面备份”有两种实现方式，在早期使用的journal文件，这种方式性能不高；在3.7版本之后，sqlite引入了WAL文件来保存页面内容，这样做的效率更高。

本节就讲解这部分内容，在对这部分内容有一个总体的了解之后，继续讲解页面备份的总体流程。后面的章节再具体分析journal以及WAL的实现。

写事务的流程 #

（以下流程分析，按照sqlite官网中的文档Atomic Commit In SQLite进行讲解，图例也全部引用自官网。）

sqlite的写事务，分为以下几个流程：

1、初始化阶段（Initial State） #

初始化

如上图中，从右到左即是系统的磁盘、操作系统缓冲区、用户空间三部分，其中磁盘和操作系统缓冲区有划分为多块的空间，每一块在sqlite里被称为一个sector，蓝色部分表示是修改之前的数据。

这是系统初始时的样子。

2、拿到读锁（Acquiring A Read Lock） #

拿到读锁

在开始进行写操作之前，sqlite必须先把待修改的页面加载内存中（这就是上一节“页面缓存管理器”做的事情），后续的修改其实也是首先修改这部分加载到内存中的页面内容，因为可能一次提交会修改同一个页面中的多处内容，最后才把页面内容落盘。

所以，这一步所要做的，是首先拿到数据库文件的读锁（shared lock），需要说明的是，这个读锁是数据库级别的锁。同一时间，系统中可以存在多个读锁，但是只要系统中还存在读锁，就不再允许分配出新的写锁（write lock）。

sqlite3.36版本 btree实现（一）- 管理页面缓存

Fri, 17 Dec 2021 14:22:06 +0800

《sqlite3.36版本 btree实现》系列文章：

概述 #

页面管理模块中，很重要的一个功能是缓存页面的内容在内存中：

读页面：如果页面已经在内存，就不需要到文件中读出页面内容。
写页面：如果页面已经在内存，那么对页面的修改就只需要修改页面在内存中的数据即可，被修改了但是还没有落盘的页面，被称为“脏页面（dirty page）“。这样，多次对某个页面的修改，可能最后只需要一次落盘即可。当然，对页面的修改，如果在还没有落盘之前，系统就崩溃了，这种情况下应该如何处理，这就是“崩溃恢复”模块做的事情了。本节中，将专注在“页面缓存”这个子模块的实现。

既然要将页面缓存在内存中，就会涉及到几个功能：

如何知道哪些页面已经被缓存在内存里了？
缓存在内存中的页面如何组织管理？
缓存页面使用的内存不够用时，应该如何处理？

我们首先来了解一下“页面缓存”模块的总体划分：

页面缓存功能的模块划分

按照上图的划分，页面缓存模块分为以下几部分：

页面缓存管理器：实现了页面缓存的总体算法流程，以及提供对外的接口，但是具体到“页面缓存算法”的实现，则有赖于下面这个可用户定制的sqlite3_pcache_methods2。这部分功能在代码pcache.c中。
页面缓存算法：用户可自己定制，只要实现sqlite3_pcache_methods2结构体中的接口即可。系统中的默认实现，在文件pcache1.c中。
除此以外，还需要快速根据页面编号就能知道哪些页面已经被缓存的功能，这部分sqlite使用位图数据结构来实现，在文件bitvec.c中。

页面缓存管理器，核心功能就是维护脏页面链表，缓存页面的管理，诸如根据页面编号查找页面、淘汰页面算法等，都由“页面缓存算法”来维护。可以这样来简单的理解上面的功能划分：

“页面缓存管理器”：定义了管理页面缓存的接口、总体流程，维护管理目前在用的脏页面。
“页面缓存算法”：维护其它不在使用但还在内存中的页面，负责其淘汰、回收等实现。由“sqlite3_pcache_methods2”结构体实现，用户可以定制自己实现的“sqlite3_pcache_methods2”，系统也提供默认的实现。当内存不足以分配时，需要淘汰不常用的页面，这时候需要使用“页面缓存管理器”注册的回调函数来淘汰页面。

页面缓存两个模块的功能划分

简而言之，如果把当前在内存中的页面划分为以下两类，那么：

当前在使用的页面：即与页面编号对应的页面，由“页面缓存管理器”维护。
当前还未使用、但也在内存中的页面：即随时准备拿出来存储从磁盘中读出来的数据的页面，由“页面缓存算法”维护，比如淘汰、回收、复用等。

两种页面的划分

下面，就开始“页面缓存”这几部分功能的具体讲解。

管理页面 #

页面相关的数据数据结构 #

首先来看页面相关的数据结构，sqlite中使用PgHdr结构体来在内存中描述一个页面：

/*
** Every page in the cache is controlled by an instance of the following
** structure.
*/
struct PgHdr {
  sqlite3_pcache_page *pPage;    /* Pcache object page handle */
  void *pData;                   /* Page data */
  void *pExtra;                  /* Extra content */
  PCache *pCache;                /* PRIVATE: Cache that owns this page */
  PgHdr *pDirty;                 /* Transient list of dirty sorted by pgno */
  Pager *pPager;                 /* The pager this page is part of */
  Pgno pgno;                     /* Page number for this page */
#ifdef SQLITE_CHECK_PAGES
  u32 pageHash;                  /* Hash of page content */
#endif
  u16 flags;                     /* PGHDR flags defined below */

  /**********************************************************************
  ** Elements above, except pCache, are public.  All that follow are 
  ** private to pcache.c and should not be accessed by other modules.
  ** pCache is grouped with the public elements for efficiency.
  */
  i16 nRef;                      /* Number of users of this page */
  PgHdr *pDirtyNext;             /* Next element in list of dirty pages */
  PgHdr *pDirtyPrev;             /* Previous element in list of dirty pages */
                          /* NB: pDirtyNext and pDirtyPrev are undefined if the
                          ** PgHdr object is not dirty */
};

其中的信息，大部分在注释中已经自解释：

sqlite3.36版本 btree实现（零）- 起步及概述

Fri, 17 Dec 2021 10:19:05 +0800

《sqlite3.36版本 btree实现》系列文章：

起步 #

在去年大体把btree以及b+tree算法流程研究了之后，我写了两篇博客：

（鉴于b+tree只是btree的一个特例，下面描述将仅使用“btree”，不再严格区分两者。）

但是，这两篇文章仅仅只是让我懂得了最基本的原理。懂得原理，只是能做出toy级别的实现，拿btree类的存储引擎来说，要做到生产级产品，至少还有以下几个问题我当时不知道怎么做的：

如何处理不同大小的数据的存储？
删除一个数据之后，如何复用其留下的空间？
错误、崩溃恢复怎么做？
跟磁盘文件是如何交互的？
页面缓存模块如何实现？

等等等等，还有太多我还没有弄清楚的实现细节。

（我甚至还在微博上发问，得到了两个质量很高的回答，见本文最后的彩蛋部分。）

对LSM类存储引擎有了解的人都知道，Leveldb这个项目在LSM领域属于入门级别的生产级实现，即这个领域最精简、但是又能放心在某些要求不高的场景下用于生产的项目。在这之后，我一直在找那种btree领域的“leveldb”，很遗憾一直都没有找到，我分别看了目前WiredTiger、innodb、sqlite的对应实现，都太复杂了，看不下去。

直到有一天，无意间发现了这个项目：madushadhanushka/simple-sqlite: Code reading for sqlite backend，看介绍，作者把sqlite2.5里b-tree相关的部分代码抽取出来了，我编译运行了一下用例都能正常跑，代码量不过几千行，我只花了几天就看完了。

虽然按照Release History Of SQLite上的记载，sqlite 2.5版本是2002年的版本了，但是这个版本还是某种程度回答了我在上面的疑问。

趁热打铁，我又找来更新一些的sqlite 3.6.10代码继续看这部分的实现，这次花了更多的时间才看完，但是又增强了我的信心。由于这个版本的sqlite，还未实现btree的wal，还只是用了journal文件来做崩溃恢复（无论wal还是journal，都会在后面文章展开详细讨论），所以在有足够的信心之后，我接下来又继续看当时（2021.10月份）最新的sqlite 3.36版本的实现，这部分的实现对比3.6.10来说，在btree部分最大的变化就是多了wal的实现，在已经清楚3.6.10的前提下，再增加了解这部分的实现，也并不是什么难事了。

以上，简单描述了我探索一个生产级btree实现的初过程，btree类存储引擎的实现博大精深，更复杂者还有很多（WiredTiger、innodb、tokudb…），但是无疑从低版本sqlite开始的探索流程，终于让我打开了走上这条路的一扇大门。

本系列文章就sqlite 3.36版本的btree实现展开描述，希望对那些和我一样对“生产级btree类存储引擎实现”有好奇心的人有一点帮助。

当然，如果你还是觉得吃力，可以先从madushadhanushka/simple-sqlite: Code reading for sqlite backend这里看起。这里并不建议对btree原理没有了解的人直接上手sqlite的实现，如果需要了解原理请参考相关文章或者我上面给出的我写的两篇博客。这系列文章中，将不再对btree原理做过多描述，将假设读者已经了解这部分内容。

Memcached的存储原理解析（续）

Thu, 12 Aug 2021 08:40:04 +0800

概述 #

在前面的Memcached的存储原理解析一文中，简单分析了memcached的存储原理，但是最近在照搬memcached的实现原理到项目中时，发现前面的梳理还不够细致，有一些细节没有谈及，因此重新整理一篇文章。

slab #

memcached是根据slab为基础单位来管理空闲空间的。slab的大体原理如下图：

slabclass的分级存储

slabs.c中定义了类型为slabclass_t、大小为MAX_NUMBER_OF_SLAB_CLASSES的数组slabclass，用于分级存储。

数组中的每个slabclass_t元素，其能分配出去的内存大小递增，由如下的规则决定：

每个数组可分配的内存大小都要8字节对齐（CHUNK_ALIGN_BYTES）,这个大小保存在slabclass_t的size成员中。
数组的第一个slabclass_t元素的可分配内存大小为sizeof(item) + settings.chunk_size。这之后的slabclass_t可分配内存大小，都在上一个的元素的基础上放大factor倍，同时还要8字节对齐。
每次分配一个页面的大小由配置项settings.slab_page_size来决定，因此每一个slabclass_t元素的一个页面能容纳的item数量为settings.slab_page_size / slabclass[i].size。

以上图为例，假设第一级存储的item大小不超过56字节，每个slab之间的增长因子是1.2，那么下一个slab存储的item内存大小就是56*1.2=72字节。

在当前还有空闲可用内存的情况下，每一次分配新的空间，都是以page（page=1MB）为单位的，然后再根据该slab的item大小划分为多个空闲可用item。

slabclass_t类型中最重要的是以下两个成员：

slab_list：保存已经分配出去的page数组，分配一个page的内存之后，需要将page根据该slab的size划分成多个空闲的item，挂载到下面提到的slots链表中。当最后需要回收分配出去的内存时，直接遍历slab_list中的成员回收内存即可。
slots：保存空闲item链表。空闲item来源有两部分，一部分是从page中分配但是还未使用的item，还有一部分是曾经被使用后来释放回来的item，上图中使用了不同的颜色进行了区分。

当需要分配一块大小的内存时，首先需要根据其大小，计算出该尺寸最终对应到上面的哪个元素，这个数组索引在Memcached中被称为clsid，这个计算索引的过程参见函数slabs_clsid。

比如：

slabclass[0].size = 56，fator参数为1.2，那么slabclass[1].size = (56 * 1.25)向上对齐8位 = 72，以此类推。
假设需要分配的内存大小为60，就会去找slabclass_t.size >= 60的第一个slabclass，在这个例子中返回的clsid是1，也就是slabclass[1]。
内存分配时根据大小向上取满足条件的第一个slab的做法，优点在于方便了内存的分配管理，缺陷是会浪费掉部分空间，比如上面的例子中，将大小为72的slab用于60的内存，那么12字节的空间就被浪费掉了。

从上面可以看到，slabclass_t用于管理空闲内存，当需要分配新item时，会依次做如下的检查：

如果slots链表中还有空闲item，直接摘下来使用；
否则，如果当前还没有达到内存分配的阈值，就分配一个新的page出来，将page按照该slab的大小划分为多个item，这些新分配出来的item都挂载到slots链表中。
如果以上两步都不满足了，说明当前已经没有可用的内存和空闲item，需要进行淘汰了。

讲到item的淘汰，就涉及到下面的LRU算法了。

LRU算法 #

旧的LRU算法及其问题 #

以往的LRU算法，基本做法都是这样的：

创建一个LRU链表，每次新加入的元素都放在链表头。
如果元素被访问了一次，同样从当前链表中摘除放到链表头。
需要淘汰元素时，从链表尾开始找可以淘汰的元素出来淘汰。

这个算法有如下几个问题：

元素被访问一次就会被放到LRU链表的头部，这样即便这个元素可以被淘汰，也会需要很久才会淘汰掉这个元素。
由于上面的原因，从链表尾部开始找可以淘汰的元素时，实际可能访问到的是一些虽然不常被访问，但是还没到淘汰时间（即有效时间TTL还未过期）的数据，这样会一直沿着链表往前找很久才能找到适合淘汰的元素。由于这个查找被淘汰元素的过程是需要加锁保护的，加锁时间一长影响了系统的并发。

经典的LRU链表实现

综上，经典的LRU链表问题的核心在于：

只需要一次被访问就能让元素远离被淘汰的地方。
以及如何高效定位到更可能被淘汰的元素。

从Memcached 1.5版本开始，引入了所谓的分段LRU算法（Segmented LRU）来解决这些问题。

改进的分段LRU算法（Segmented LRU） #

分段LRU算法中将LRU链表根据活跃度分成了三类：

HOT_LRU：存储热数据的LRU链表。
WARM_LRU：存储温数据（即活跃度不如热数据）的LRU链表。
COLD_LRU：存储冷数据的LRU链表。

需要说明的是：热（参数settings.hot_lru_pct）和暖（参数settings.warm_lru_pct）数据的占总体内存的比例有限制，而冷数据则无限。

Memcached的存储原理解析

Thu, 01 Jul 2021 14:00:22 +0800

概述 #

最近工作上的需要，需要做一个LRU形式管理内存的分配器，首先想到的就是Memcached这个项目。早些年粗略的看过一些，有个大体的了解，这一次看下来发现其LRU算法做了不少的改动。

本文解析Memcached内存管理这部分的内容，基于Memcached 1.6.9版本。

Memcached将单个KV数据的存储，都放在item这个结构体中，每个item数据同时存在于这几个数据结构之中：

slabclass_t：以分级存储机制来提供内存的数据结构（下面展开详细讨论slabclass）。
链表：当item被使用时，存储在LRU链表中（下面详细讨论LRU链表）；当item被释放之后，空闲的item形成一个链表以备再次使用。
hash表：用于根据键值查找数据的数据结构。

hash表自不必多说，Memcached中将item组织成一个名为primary_hashtable的hash数组，根据键值查找元素时，首先计算出键值的hash值，再到对应的数组元素中遍历查找数据。

slabclass_t结构体以分级的方式分配内存给item，这样做有以下几个好处：

统一了内存的管理，避免了内存的碎片化。
分配、释放内存时都能到对应的slab中。

slabclass_t #

定义 #

slabs.c中定义了类型为slabclass_t、大小为MAX_NUMBER_OF_SLAB_CLASSES的数组slabclass，用于分级存储。

数组中的每个slabclass_t元素，其能分配出去的内存大小递增，由如下的规则决定：

每个数组可分配的内存大小都要8字节对齐（CHUNK_ALIGN_BYTES）,这个大小保存在slabclass_t的size成员中。
数组的第一个slabclass_t元素的可分配内存大小为sizeof(item) + settings.chunk_size。这之后的slabclass_t可分配内存大小，都在上一个的元素的基础上放大factor倍，同时还要8字节对齐。
每次分配一个页面的大小由配置项settings.slab_page_size来决定，因此每一个slabclass_t元素的一个页面能容纳的item数量为settings.slab_page_size / slabclass[i].size。

slabclass的分级存储

比如：

slabclass[0].size = 56，fator参数为1.2，那么slabclass[1].size = (56 * 1.25)向上对齐8位 = 72，以此类推。
假设需要分配的内存大小为60，就会去找slabclass_t.size >= 60的第一个slabclass，在这个例子中返回的clsid是1，也就是slabclass[1]。
内存分配时根据大小向上取满足条件的第一个slab的做法，优点在于方便了内存的分配管理，缺陷是会浪费掉部分空间，比如上面的例子中，将大小为72的slab用于60的内存，那么12字节的空间就被浪费掉了。

每一个slab中，需要维持两类空间：

按照页面大小来分配的一整页空间，每个页面又按照该slab的大小划分成了多个不同的chunk。
管理使用已被释放的item。

在slabclass_t结构体中，以下几个成员用来维护该class的内存信息：

slab_list：保存页面的数组，其大小保存在slabs成员中。
sl_curr：可用的item数量。
slots：保存在该slabclass_t中空闲item的链表头。

slabclass结构体示意图

即：

在Memcached的这一套内存管理体系中，一个页面被称为一个slab，其大小为settings.slab_page_size；页面中可以分割成多个slot用来分配内存，一个slot的大小由该slabclass的初始大小及factor来决定，但是需要向上补齐为8位对齐的大小。
一个slabclass中，有预分配好的页面数组，也有被回收的元素组成的空闲slot链表，分配元素时优先从空闲链表中分配（见函数do_slabs_alloc）。

内存分配 #

既然Memcached是一个LRU形式的内存分配器，所以其内存是有限制的，系统中定义了如下几个全局变量来保存当前系统的内存分配信息：

static size_t mem_limit：内存分配的上限。
static size_t mem_malloced：当前分配的内存大小。
static void *mem_base：保存内存的起始地址。
static void *mem_current：保存内存分配的当前地址。

在初始化时，系统首先会根据mem_limit分配一大块内存出来。

boltdb 1.3.0实现分析（四）

Sun, 26 Jul 2020 17:55:11 +0800

本文基于boltdb 1.3.0对其实现进行分析。boltdb是etcd系统存储数据使用的KV嵌入式DB，使用Go编码实现，内部是一个B+树结构体。关于etcd、raft协议以及B+树，可以参考之前的文章：

Raft算法原理

etcd Raft库解析

Etcd存储的实现

B树、B+树索引算法原理（上）

B树、B+树索引算法原理（下）

本文的写作，主要参考了《区块的持久化之BoltDB》系列文章以及boltdb 源码分析

前面的章节中，分别讲解了boltdb的页面结构、Bucket结构以及事务相关的逻辑，最后一节讲解boltdb如何实现MVCC。

MVCC概述 #

数据库的ACID特性中，Isolation即隔离性是一个较难实现的特性。

一个数据库被修改时，在这次事务提交之前，不希望其他事务操作读到修改的结果。一种常见的办法就是加锁，但是锁的粒度如果很大，就会影响数据库的并发性能，即在写操作完成之前不能进行其他操作。

MVCC（Multiversion concurrency control，多版本并发控制）是解决这个问题的一种方式。它的做法是：保存数据库中的多个版本，修改的是一个版本，而同时进行的读操作读取到的数据是旧版本的数据，这样即便读到了旧的数据也不影响，只要不是写操作中间的数据就好。

readCommitted

如上图所示，事务A修改了x的值为2，在这个事务提交之前，读事务B读取到的还是修改之前的值1，因为存在有两个该数据的不同版本，并且并没有因为有写操作同时存在而必须等待写操作完成才能进行读操作。在事务A提交之后，才能读到新的值2。（但是这个图里还有另外的问题，即同一个读事务的过程中，前后读到了同一个数据两次不同的值，这叫“不可重复读”，这就是另外一个问题了不在这里展开讨论。）

本节讲解boltdb如何实现MVCC操作，在开始讨论之前先看看boltdb如何管理数据库文件的。

映射文件的使用 #

boltdb通过mmap系统调用将数据库文件映射到内存中，64位体系下一个进程的虚拟内存空间有128TB，足够映射一个文件了。在把磁盘文件映射到内存之后，对磁盘文件的读写可以直接使用读写内存的操作，由操作系统内核来决定什么时候将哪部分的虚拟内存换入、换出物理内存。

看上去这个好像方便了很多，其实并不建议在存储引擎中使用内存映射这样“偷懒”的技术。原因在于：操作系统内核除了知道什么时候换入换出物理内存之外，对数据库的其他操作一无所知，并不能很精准的控制其行为。

db-mmap

对数据库进行内存映射的操作在函数db.mmap函数中进行，大体流程如下：

func (db *DB) mmap(minsz int) error {
	db.mmaplock.Lock()
  defer db.mmaplock.Unlock()
  
  // 计算至少要多大的文件大小才能满足minsz需求
	// Memory-map the data file as a byte slice.
	if err := mmap(db, size); err != nil {
		return err
  }
    
}

这个函数只有在以下两种情况会被调用到：

db初始化时，即初次加载db文件到内存映射中。
当前文件不够大，需要进行扩容时，即在db.allocate中分配新页面而当前页面不足需要扩充文件大小时。

后者也被称为remmap操作，即以新的大小重新映射文件进行内存中。为了避免每次增加了文件大小都需要重新进行文件内存映射操作，实际上boltdb是对文件大小做了over allocate操作，具体的计算新文件大小的逻辑在函数DB.mmapSize函数中实现的，这里不做展开了。

boltdb 1.3.0实现分析（三）

Sat, 25 Jul 2020 11:26:33 +0800

本文基于boltdb 1.3.0对其实现进行分析。boltdb是etcd系统存储数据使用的KV嵌入式DB，使用Go编码实现，内部是一个B+树结构体。关于etcd、raft协议以及B+树，可以参考之前的文章：

Raft算法原理

etcd Raft库解析

Etcd存储的实现

B树、B+树索引算法原理（上）

B树、B+树索引算法原理（下）

本文的写作，主要参考了《区块的持久化之BoltDB》系列文章以及boltdb 源码分析

在前面的文章里，分别介绍了boltdb的几种页面格式、Bucket以及Cursor结构，本文介绍boltdb的事务（Transaction）。

概述 #

boltdb支持事务的ACID特性，使用MVCC来做并发控制，同时可以执行一个写事务和多个读事务：

原子性（Atomicity）：未提交的写事务操作都在内存中。在提交写事务的时候，按照B+树数据、freelist、meta元数据的顺序写入文件。在meta元信息写入之前，都可以进行回滚（rollback）操作，只有meta元信息写入成功才能认为写操作执行成功。
隔离性（Isolation）：每个读事务开始的时候获得一个版本号，读事务涉及到的页面不会被同时进行的写事务所覆盖；而每次写事务都会更新一个版本号。
持久性（Durability）：写事务在提交的时候，会将这次写操作修改的数据（dirty page）分配新的页面，写入文件持久化。

本节首先讲解boltdb的事务基本实现，下一节讲解boltdb事务如何实现MVCC。

事务初始化 #

boltdb中，任何一次读写操作，都有一个事务与之对应。这时候首先会调用DB.Begin函数返回一个事务，而传入的参数会根据情况分别创建写和读事务：

func (db *DB) Begin(writable bool) (*Tx, error) {
	if writable {
		return db.beginRWTx()
	}
	return db.beginTx()
}

可以看到，根据是否是写事务，会分别调用beginRWTx和beginTx来创建读写事务和只读事务。

DB结构体中，仅有一个写事务成员，而读事务则可以同时存在多个，因此同一个时间只能有一个写事务：

type DB struct {
  // ...
	rwtx     *Tx				// 同一时间只能有一个未完成的写事务
	txs      []*Tx			// 保存未完成的读事务的，读事务可以有多个，写事务一个时间只能有一个，就在rwtx里面
}

beginTx

了解了在DB中如何使用事务，下面来看事务结构体的定义：

type Tx struct {
	writable       bool	// 是否写事务
	managed        bool	//
	db             *DB	// 对应的db
	meta           *meta	// 对应的meta数据指针
	root           Bucket	
	pages          map[pgid]*page	// 涉及到的page
	stats          TxStats
	commitHandlers []func()	// commit回调函数数组

	WriteFlag int
}

成员释义如下：

boltdb 1.3.0实现分析（二）

Sat, 11 Jul 2020 09:33:06 +0800

本文基于boltdb 1.3.0对其实现进行分析。boltdb是etcd系统存储数据使用的KV嵌入式DB，使用Go编码实现，内部是一个B+树结构体。关于etcd、raft协议以及B+树，可以参考之前的文章：

Raft算法原理

etcd Raft库解析

Etcd存储的实现

B树、B+树索引算法原理（上）

B树、B+树索引算法原理（下）

本文的写作，主要参考了《区块的持久化之BoltDB》系列文章以及boltdb 源码分析

在上一节里面，系统的介绍了Boltdb中几种类型页面的格式，有了这些基础，本节开始介绍boltdb中的Bucket结构。

Bucket #

概述 #

在上一节中，Bucket类比于mysql中的table，在boltdb中，meta页面中有一个成员bucket，其存储了整个数据库根bucket的信息，而一个数据库中存储的其他table的信息，则作为子bucket存储到Bucket中。这几个数据结构的关系如下：

type DB struct {
  // ...
	meta0    *meta
	meta1    *meta  
}

type meta struct {
  // ...
	root     bucket	// 根bucket的信息
}

type Bucket struct {
	*bucket

  // ...
  buckets  map[string]*Bucket // 存储子bucket的对应关系
}

type bucket struct {
	// 根节点的page id
	root pgid // page id of the bucket's root-level page
	// 单调递增的序列号
	sequence uint64 // monotonically incrementing, used by NextSequence()
}

在bucket数据结构中，两个成员的作用是：

boltdb 1.3.0实现分析（一）

Thu, 25 Jun 2020 21:43:17 +0800

本文基于boltdb 1.3.0对其实现进行分析。boltdb是etcd系统存储数据使用的KV嵌入式DB，使用Go编码实现，内部是一个B+树结构体。关于etcd、raft协议以及B+树，可以参考之前的文章：

Raft算法原理

etcd Raft库解析

Etcd存储的实现

B树、B+树索引算法原理（上）

B树、B+树索引算法原理（下）

本文的写作，主要参考了《区块的持久化之BoltDB》系列文章以及boltdb 源码分析

概述 #

boltdb是etcd项目使用的kv存储引擎，代码量不大，不算测试用例的话仅有几千行代码量，是入门存储引擎不错的参考项目。

boltdb中与mysql这类的关系数据库相对应的概念列举如下：

boltdb	mysql
db	database
bucket	table

即：在boltdb中，db代表一个数据库，对应一个db文件；而一个数据库中可能有多个表，对应的概念就是boltdb中的bucket。

另外，对B+树有了解的都知道，B+树中为了减少磁盘读写次数，每次读写都是以页为单位的，对应到boltdb中用page数据结构表示，page只是描述磁盘上一个页面的数据结构，当一个页面读取到内存中时，就使用node结构体来描述。另外，既然落地到磁盘的单位是页，就需要有数据结构来管理页面的分配，这部分使用freelist这个数据结构来管理。

page-struct

以下，首先展开对页面相关核心数据结构的分析。

数据库文件的磁盘布局和页面 #

前面提到过，boltdb中以页面为单位来进行磁盘的读写操作，一个页面的大小一般而言与操作系统的页面一致，即4K大小。在boltdb中，分为以下几种类型的页面：

存储meta元数据的页面。
存储freelist，即管理页面数据的页面。
Branch页面，存储B+树索引节点，也就是内部节点的页面。
Leaf页面，存储B+树数据节点，也就是叶子节点的页面。

boltdb代码中定义页面类型如下：

const (
	branchPageFlag   = 0x01
	leafPageFlag     = 0x02
	metaPageFlag     = 0x04
	freelistPageFlag = 0x10
)

这四种页面，在boltdb的数据库文件的布局大体如下：

boltdb-layout

从上图中可以看出：

最开始的两个页面是两个meta页面，至于为什么是两个，后面再展开讨论。
紧跟着的一个页面是freelist页面。
从上面可知，数据库文件中最开始的三个页面存的都是管理信息，此后数据数据型的branch以及leaf页面了。

接下来就这几种页面具体的结构展开说明，不过在此之前还是首先来看看page结构体，它用于表示一个磁盘页面的数据结构。

page结构体 #

page结构体的定义如下：

type pgid uint64

type page struct {
    id       pgid
    flags    uint16
    count    uint16
    overflow uint32
    ptr      uintptr
}

其中：

B树、B+树索引算法原理（下）

Mon, 15 Jun 2020 22:44:21 +0800

这一段时间由于在阅读boltdb代码的缘故，找机会学习了B树及B+树的算法原理，这个系列会花两个篇幅分别介绍这两种数据结构的实现，其用于数据库索引中的基本原理。

在上一篇文章中，介绍了数据库索引的简单概念，以及B树的结构及核心算法，这一篇将继续介绍B树的变形B+树。

B+树的定义及性质 #

B+树之于B树，最大的不同在于：

B树的数据可以存储在内部节点上，也可以存储在叶子节点上。
而在B+树中，内部节点上仅存放数据的索引，数据只存储在叶子节点上。在内部节点中的键值，被称为“索引”，由于是数据索引，因此可能出现同一个键值，既出现在内部节点，也出现在叶子节点中的情况。

内部节点的“索引”，应该满足以下条件：

大于左边子树的最大键值；
小于等于右边子树的最小键值。

同时，B+树为了方便范围查询，叶子节点之间还用指针串联起来。

以下是一颗B+树的典型结构：

b+tree

由于采用了这样的结构，B+树对比B树有以下优点：

索引节点上由于只有索引而没有数据，所以索引节点上能存储比B树更多的索引，这样树的高度就会更矮。按照我们上一篇中介绍数据库索引的内容，这种面向磁盘的数据结构，树的高度越矮，磁盘寻道的次数就会越少。
因为数据都集中在叶子节点了，而所有叶子节点的高度相同，那么可以在叶子节点中增加前后指针，指向同一个父节点的相邻兄弟节点，给范围查询提供遍历。比如这样的SQL语句：select * from tbl where t > 10，如果使用B+树存储数据的话，可以首先定位到数据为10的节点，再沿着它的next指针一路找到所有在该叶子节点右边的叶子节点数据返回。而如果使用B树结构，由于数据既可以存储在内部节点也可以存储在叶子节点，范围查询可想而知是很繁琐的。

核心算法 #

插入算法 #

B+树的插入算法与B树的很相近，都是：

首先判断待插入数据节点是否已经溢出，如果是就首先拆分成两个节点，然后再插入数据。
由于内部节点上的数据是索引，所以在插入完成之后调整父节点指针。

比如在下图的B+树中，向这里插入新的数据10：

slide01b

由于插入节点[7,11]在插入之后并没有溢出，所以可以直接变成[7,10,11]：

slide01c

而如下图的B+树中，插入数据4：

slide02b

由于所在节点[2,3,5]在插入之后数据溢出，因此需要分裂为两个新的节点，同时调整父节点的索引数据：

slide02g

[2,3,4,5]分裂成了[2,3]和[4,5]，因此需要在这两个节点之间新增一个索引值，这个值应该满足：

大于左子树的最大值。
小于等于右子树的最小值。

综上，需要在父节点中新增索引4和两个指向新节点的指针。

删除算法 #

B+树的删除算法，与B树类似，分为以下几步：

首先查询到键值所在的叶子节点，删除该叶子节点的数据。
如果删除叶子节点之后的数据数量，满足B+树的平衡条件，则直接返回不用往下走了。
否则，就需要做平衡操作：
- 如果该叶子节点的左右兄弟节点的数据量可以借用，就借用过来满足平衡条件。
- 否则，就只能与相邻的兄弟节点合并成一个新的子节点了。
在上面平衡操作中，如果是进行了合并操作，就需要向上修正父节点的指针：删除被合并节点的键值以及指针。由于做了删除操作，可能父节点也会不平衡，那么就按照前面的步骤也对父节点进行重新平衡操作，这样一直到某个节点平衡为止。

下面结合B-tree=delete1、B-tree=delete2 的图示对删除算法展开具体的分析。

从叶子节点中删除数据 #

从叶子节点中删除数据分为三种情况：

删除之后的数据量足够，不需要进行重平衡操作；
删除之后的数据量不够，但是可以从兄弟节点那里借用数据，重新达到平衡；
删除之后的数据量不够，兄弟节点的数据也不够，那么需要合并成一个新的节点，同时在父节点中删除索引和指针。

以下针对后面两种需要做重平衡的操作展开分析。

借用兄弟节点数据进行重平衡操作 #

在下图中，从叶子节点中删除数据之后，只剩下数据[11]：

B树、B+树索引算法原理（上）

Tue, 09 Jun 2020 18:40:46 +0800

这一段时间由于在阅读boltdb代码的缘故，找机会学习了B树及B+树的算法原理，这个系列会花两个篇幅分别介绍这两种数据结构的实现，其用于数据库索引中的基本原理。

B树数据库索引原理 #

在一堆数据中查找一个数据时，常用的数据结构有二叉查找树（binary search tree，简称BST）、哈希桶等。以BST为例，常见的实现有AVT、红黑树等，由于这类型的树是平衡的，每次比较操作都会去掉当前数据量一半的数据，因此查找的时间复杂度为O(log2n)。

bst-example

但是这类型数据结构的问题在于，由于每个节点只能容纳一个数据，导致树的高度很高，逻辑上挨着的节点数据可能离的很远。如果是在内存中操作数据的话，这样问题并不大。

考虑在磁盘中存储数据的情况，与内存相比，读写磁盘有以下不同点：

读写磁盘的速度相比内存读写慢很多。
因为上面的原因，因此每次读写磁盘的单位要比读写内存的最小单位大很多。

因为读写磁盘的这个特点，因此对应的数据结构应该尽量的满足“局部性原理”：“当一个数据被用到时，其附近的数据也通常会马上被使用”，为了满足局部性原理，应该：将逻辑上相邻的数据在物理上也尽量存储在一起。这样才能减少读写磁盘的数量。

所以，对比起一个节点只能存储一个数据的BST类数据结构来，要求这种数据结构在形状上更“胖”、更加“扁平”，即：每个节点能容纳更多的数据，这样就能降低树的高度，同时让逻辑上相邻的数据都能尽量的存储在物理上也相邻的硬盘空间上，减少磁盘读写。

以下图为例：

disk-ds

图中从根节点出发，查找数据14的过程中，经过的第二个节点中有键值[3,7,13]，这三个值在“逻辑”上是相邻的，如果它们在磁盘上的存储也能做到在“物理”上相邻，那么只需要一次读操作就能把这个节点的数据从磁盘上加载到内存中进行数据比较，这样整个查找过程就只需要两次磁盘读操作。

在这里，一个节点越“胖”，意味着扇出（fanout）越大，同时高度越低，这两个性质决定了：

高扇出：邻近键值的数据局部性更好。
低高度：遍历期间的寻道次数更少。

可以证明，查找数据的次数（searchnum）与degree、以及数据总量有以下关系：

btree-num

B树和B+树就是两种利用磁盘局部性原理进行优化的树结构，B+树基于B树做了一些改进，这里首先将介绍B树的原理。本系列将用两篇文章讲解这两种数据结构的原理，并且提供Python实现代码。

B树的定义及性质 #

在B树中，分为两种节点：

内部节点（internal node）：存储了数据以及指向其子节点的指针。
叶子节点（leaf node）：与内部节点不同的是，叶子节点只存储数据，并没有子节点。

一个数据，既可能存在内部节点上，也可能存在叶子节点上，这一点是与后面讲到的B+树最大的不同，后者只会将数据存储在叶子节点上。

创建B树时，需要输入一个degree参数（以下简写为t），该参数决定了每个节点上数据量的多少，即节点的“胖”、“瘦”程度，而节点的胖瘦程度又会影响整棵树的高度，因为越胖的节点树高度就会越矮。

为了维持B树的平衡性，需要满足以下的属性：

在每个节点上的键值，以递增顺序排列，即node.keys[i] <= node.keys[i+1]。
在一个键值左边的子树，其键值大于该键值右边子树的所有键值，即node.keys[i] > max(node.child[i]的所有键值)；同时，在一个键值右边的子树，其键值的最小值都不小于该键值，即node.keys[i] <= min(node.child[i + 1]的所有键值)。具体情况可以在下面的图中进行说明。
在内部节点中，指向子节点的指针数量总是存储数据节点的数量+1，即：num(node.child) = num(node.keys) + 1。
所有叶子节点的高度一致。
无论是内部节点还是叶子节点，其存储的键值数量在[t-1,2t-1]之间，如果数量不满足此条件，需要做重平衡操作。如果少于t-1，需要借用或合并数据；反之，如果数据量大于2t-1，则需要分裂成两个节点。

我们来看下面的图示，该图中的B树，t参数的值为2（需要特别说明的是，一棵树中每个存储数据的地方，应该既有键值（key）也有数据（value），本文中为了简单起见，存储的数据只有键值。）：

btree-example

在上图中：

由于t=2，所有所有节点的键值数量在[1,3]之间。
所有叶子节点的高度相同。
以左边的内部节点为例，其第一个键值为3，即该节点的keys[0]=3，而该键值的左边子树的键值为[1,2]，都小于3，即keys[0]>max(child[0]的所有键值)；而其右边子树的键值为[4,5,6]，都不小于3，即keys[0]<=min(child[1]的所有键值)。

B树算法原理 #

了解了B树的性质，下面讨论B树中的两个核心操作：插入及删除。这两个操作的核心，都是在操作如果破坏了B树的平衡性之后，进行重新平衡以满足B树的性质。

插入数据 #

向B树中插入一个数据，可能会导致节点的数据变满，即不满足上面提到的节点数据数量在[t,2t-1]这个性质。此时需要对节点进行分裂节点操作：

将数据变满（即节点数据量为2t）的节点，分为左右两个数据量分别为t-1的节点，同时将中间的数据提升到父节点的合适位置上。
如果父节点由于新增了这个被提升的数据导致了变满，就继续上面的分裂节点操作。
沿着树向上一直执行该操作，直到不再变满为止。

分裂操作的示意图如下：

Leveldb代码阅读笔记

Fri, 15 Feb 2019 08:52:47 +0800

本文基于leveldb 1.9.0代码。

整体架构 #

leveldb

如上图，leveldb的数据存储在内存以及磁盘上，其中：

memtable：存储在内存中的数据，使用skiplist实现。
immutable memtable：与memtable一样，只不过这个memtable不能再进行修改，会将其中的数据落盘到level 0的sstable中。
多层sstable：leveldb使用多个层次来存储sstable文件，这些文件分布在磁盘上，这些文件都是根据键值有序排列的，其中0级的sstable的键值可能会重叠，而level 1及以上的sstable文件不会重叠。

在上面这个存储层次中，越靠上的数据越新，即同一个键值如果同时存在于memtable和immutable memtable中，则以memtable中的为准。

另外，图中还使用箭头来表示了合并数据的走向，即：

memtable -> immutable memtable -> level 0 sstable -> level 1 sstable -> ... -> level N sstable。

以下将针对这几部分展开讨论。

Log文件 #

写入数据的时候，最开始会写入到log文件中，由于是顺序写入文件，所以写入速度很快，可以马上返回。

来看Log文件的结构：

一个Log文件由多个Block组成，每个Block大小为32KB。
一个Block内部又有多个Record组成，Record分为四种类型：
- Full：一个Record占满了整个Block存储空间。
- First：一个Block的第一个Record。
- Last：一个Block的最后一个Record。
- Middle：其余的都是Middle类型的Record。
Record的结构如下：
- Header部分
  - 32位长度的CRC Checksum：存储这个Record的数据校验值，用于检测Record合法性。
  - 16位长度的Length：存储数据部分长度。
  - 8位长度的Type：存储Record类型，就是上面说的四种类型。
- 数据部分

log-file

memtable #

memtable用于存储在内存中还未落盘到sstable中的数据，这部分使用跳表（skiplist）做为底层的数据结构，这里先简单描述一下跳表的工作原理。

如果数据存放在一个普通的有序链表中，那么查找数据的时间复杂度就是O(n)。跳表的设计思想在于：链表中的每个元素，都有多个层次，查找某一个元素时，遍历该链表的时候，根据层次来跳过（skip）中间某些明显不满足需求的元素，以达到加快查找速度的目的，如下图所示：

skiplist

在以上这个跳表中，查找元素6的流程，大体如下：

构建一个每个链表元素最多有5个元素的跳表。
由于6大于链表的第一个元素1，因此如果存在必然在1之后的元素中，因此进入元素1的指针数组中，从上往下查找元素4：
- 第一层：指向的指针为Nil空指针，不满足需求，继续往下查找；
- 第二层：指向的指针保存的数据为4，小于待查找的元素4，因此如果元素6存在也必然在4之后，因此指针跳转到元素4所在的位置，继续从上往下开始查找。
到了元素4所在的指针数组，开始从上往下继续查找：
- 第一层：指向的指针保存的数据为6，查找完毕。

从上面的分析过程中可以看到：

跳表是一种以牺牲更多的存储空间换取查找速度，即“空间换时间”的数据结构。
跳表的每一层也都是一个有序链表。
如果一个元素出现在第i层的链表中，那么也必然会在第i层以下的链表中出现。
链表的每个节点中，垂直方向的数组存储的数据都是一样的，水平方向的指针指向链表的下一个元素。
最底层的链表包含所有元素，也就是说，在最底层数据结构退化为一个普通的有序链表。

sstable文件 #

大体结构 #

首先来看sstable文件的整体结构，如下图：

存储 on codedump notes

sqlite3.36版本 btree实现（五）- Btree的实现

概述 #

物理页面的数据组织 #

数据表的逻辑组织和页面类型 #

sqlite3.36版本 btree实现（四）- WAL的实现

概述 #

WAL工作原理 #

sqlite3.36版本 btree实现（三）- journal文件备份机制

概述 #

相关命令 #

journal文件格式 #

文件头 #

sqlite3.36版本 btree实现（二）- 并发控制框架

概述 #

写事务的流程 #

1、初始化阶段（Initial State） #

2、拿到读锁（Acquiring A Read Lock） #

sqlite3.36版本 btree实现（一）- 管理页面缓存

概述 #

管理页面 #

页面相关的数据数据结构 #

sqlite3.36版本 btree实现（零）- 起步及概述

起步 #

Memcached的存储原理解析（续）

概述 #

slab #

LRU算法 #

旧的LRU算法及其问题 #

改进的分段LRU算法（Segmented LRU） #

Memcached的存储原理解析

概述 #

slabclass_t #

定义 #

内存分配 #

boltdb 1.3.0实现分析（四）

MVCC概述 #

映射文件的使用 #

boltdb 1.3.0实现分析（三）

概述 #

事务初始化 #

boltdb 1.3.0实现分析（二）

Bucket #

概述 #

boltdb 1.3.0实现分析（一）

概述 #

数据库文件的磁盘布局和页面 #

page结构体 #

B树、B+树索引算法原理（下）

B+树的定义及性质 #

核心算法 #

插入算法 #

删除算法 #

从叶子节点中删除数据 #

借用兄弟节点数据进行重平衡操作 #

B树、B+树索引算法原理（上）

B树数据库索引原理 #

B树的定义及性质 #

B树算法原理 #

插入数据 #

Leveldb代码阅读笔记

整体架构 #

Log文件 #

memtable #

sstable文件 #

大体结构 #