[LevelDB] 0.2 BitCask存储引擎

----《大规模分布式存储系统：原理解析与架构实战》读书笔记

最近一直在分析OceanBase的源码，恰巧碰到了OceanBase的核心开发者的新做《大规模分布式存储系统：原理解析与架构实战》.看完样章后决定入手，果真物有所值。对于准备学习分布式的同窗，这是一本不错的书籍，相对系统，全面的介绍了分布式的相关技术和项目，基本都是干货。还有一半是在介绍OceanBase的内容，对我来讲，正是踏破铁鞋无觅处，接下来会有几篇专门研究存储引擎的读书笔记哟。废话很少说，转入正题。

1.存储的介质与读写

谈存储，那么理解存储的介质的特性显然很重要，书中谈了不少硬件结构，但最重要的结论，都浓缩在存储介质对比这张表中了。

磁盘介质对比

类别	每秒读写(IOPS)次数	每GB价格(元)	随机读取	随机写入
内存	千万级	150	友好	友好
SSD盘	35000	20	友好	写入放大问题
SAS磁盘	180	3	磁盘寻道	磁盘寻道
SATA磁盘	90	0.5	磁盘寻道	磁盘寻道

从表中能够看出，内存的随机读写能力最强，远超SSD盘和磁盘。可是咱们都知道，内存没法持久化。如今许多公司在性能要求高的地方都使用了SSD盘，相对SAS和SATA磁盘，随机读取速度有了很大的提高。可是对于随机写入，存在写入放大问题。

写入放大问题与SSD盘的特性有关，SSD盘不能随机写入，只能整块整块的写入。最简单的例子，好比要写入一个4KB的数据，最坏的状况就是，一个块里已经没有干净空间了，可是有无效数据能够擦除，因此主控就把全部的数据读出来，擦除块，再加上这个4KB新数据写回去，这个操做带来的写入放大就是: 实际写4K的数据，形成了整个块（512KB）的写入操做，那就是128倍放大。此外，SSD盘的寿命也有写入次数相关。

若是使用SSD来做为存储引擎的存储介质，最好从设计上减小或避免随机写入，使用顺序写入取而代之。

 

2.Bitcask存储模型介绍

存储系统的基本功能包括：增、删、读、改。其中读取操做有分为顺序读取和随机读取。

 

整体来讲，大部分应用使用读的功能最多，解决读的性能是存储系统的重要命题。通常来讲。快速查找的思想基本源自二分查找法和哈希查询。例如关系数据库中经常使用的B+存储模型就是使用二分查找的思想，固然，实际实现比二分查找复杂不少。B+存储模型支持顺序扫描。另一类则是基于哈希思想的键值模型，这类模型不支持顺序扫描，仅支持随机读取。

今天要讨论的Bitcask模型是一种日志型键值模型。所谓日志型，是指它不直接支持随机写入，而是像日志同样支持追加操做。Bitcask模型将随机写入转化为顺序写入。有两个好处：

• 提升随机写入的吞吐量，由于写操做不须要查找，直接追加便可
• 若是使用SSD做为存储介质，可以更好的利用新硬件的特性

Bitcask中存在3种文件，包括数据文件,索引文件和线索文件(hint file,姑且就叫线索文件吧)。数据文件存储于磁盘上，包含了原始的数据的键值信息；索引文件存在于内存，用于记录记录的位置信息，启动Bitcask时，它会将全部数据的位置信息所有读入一个内存中的哈希表，也就是索引文件；线索文件(hint file)并非Bitcask的必需文件，它的存在是为了提供启动时构建索引文件的速度。

2.1 日志型的数据文件

Bitcask的数据文件组织以下图：任意时刻，系统中只有一个数据文件支持写入，称为active data file。其他的数据文件都是只读文件，称为older data file。

 

 

 

文件中的数据结构很是简单，是一条一条的数据写入操做，每一条数据的结构以下：

 

 

上面数据项分别为：后面几项的crc校验值,时间戳,key，value，key的大小，value的大小。
数据文件中就是连续一条条上面格式的数据，以下图：

 

 

2.2 索引哈希表

索引哈希表记录了所有记录的主键和位置信息，索引哈希表的值包含了：记录文件的编号,value长度,value的在文件中的位置和时间戳。Bitcask的整体数据结构以下图：

 

 

2.3 线索文件(hint file)

Bitcask启动时要重建索引哈希表，若是数据量特别大，则会致使启动很慢。而线索文件(hint file)则是用来加速启动时重建哈希表的速度。线索文件(hint file)的记录与数据文件的格式基本相同，惟一不一样的是数据文件记录数据的值，而线索文件(hint file)则是记录数据的位置。

 

 

这样在启动的时候就能够不用读数据文件，而是读取线索文件(hint file)，一行行重建便可，大大加快了哈希表的重建速度。

3. Bitcask功能介绍

上节提到，存储系统的基本功能包括：增、删、读、改。那么Bitcask中如何实现的呢？

1. 如何增长记录？
   用户写入的记录直接追加到活动文件，所以活动文件会愈来愈大，当到达必定大小时，Bitcask会冻结活动文件，新建一个活动文件用于写入，而以前的活动文件则变为了older data file。写入记录的同时还要在索引哈希表中添加索引记录。

2. 如何删除记录？
   Bitcask不直接删除记录，而是新增一条相同key的记录，把value值设置一个删除的标记。原有记录依然存在于数据文件中，而后更新索引哈希表。

3. 如何修改记录？
   Bitcask不支持随机写入。由于对于存储系统的基本功能中的增和改，实际上都是同样的，都是直接写入活动数据文件。同时修改索引哈希表中对应记录的值。(这个时候，实际上数据文件中同一个key值对应了多条记录，根据时间戳记录来判断，以最新的数据为准。)

4. 如何读取记录?
   读取时，首先从索引哈希表中定位到记录在磁盘中位置，而后经过IO读取出对应的记录。

5. 合并(Marge)操做
   Bitcask这种只增不减地不断写入，必然会是数据文件不断的膨胀。而其中有许可能是被标记删除和修改后留下的无用记录。合并操做就是为了剔除这部分数据，减少数据文件大小。
   merge操做，经过按期将全部older data file中的数据扫描一遍并生成新的data file（没有包括active data file 是由于它还在不停写入）。若是同一个Key有多条记录，则只保留最新的一条。从而去掉数据文件中的冗余数据。并且进行合并(Marge)操做时，还能够顺带生成线索文件(hint file)。合并(Marge)操做一般会在数据库较闲的时候进行，好比凌晨一两点等。

4.总结

Bitcask是一个精炼的键值存储模型。采用日志型的数据结构，只追加不改写就记录，提升了随机写入的吞吐量，经过创建哈希表来加快查询速度，按期合并数据文件，并生成线索文件(hint file)，提升启动时重建哈希表的速度。

这是我参考了网上的一个python实现，并增长了部分功能后的代码:https://github.com/Winnerhust/Code-of-Book/blob/master/Large-Scale-Distributed-Storage-System/bitcask.py
除了增删读写外,主要还实现了：

• 数据文件合并，合并时能够选择生成线索文件(hint file)
• 可使用线索文件(hint file)启动