基于上一篇文章,我们已经知道了日志结构的存储引擎-bitcask的基本原理。在这个基础上,继续讨论SSTable(Sorted String Table)。
回顾一下bitcask的key-value,它在段文件中是无序的,假设按key排序,并且要求每个key在每个段中只能出现一次,排好序再写入到段文件中,这种格式的段文件称之为SSTable。
一、SSTable比bitcask有什么优点?
1,由于key在一个段中只出现一次且有序,可以使用类似合并排序的方式,在段文件合并时,即使文件大于可用内存也可简单高效合并。如下图:
2,在文件中查找特定key时,不再需要在内存中保存所有key的索引,假设正在查找key-handiwork,且不知道该key在段文件中的准确偏移量。但是知道key-handbag和key-handsome的偏移量,考虑到key是有序的,只需要从handbag扫描到handsome,假设key存在,就能找到。这是稀疏索引的一种设计思路。通常对于段文件中的每几千字节,只需要一个key就足够了。如下图
二、如何构建和维护SSTable?
1,当写入时,在内存中维护平衡树结构,用于key-value排序,当这个树内存大于某个阈值(通常为几M)时,将其作为SSTable文件写入磁盘。由于树已经维护了按key排序的key-value对,写磁盘可以很高效。当SSTable写入磁盘的同时,写入可以继续添加到一个新的内存表。
2,为避免数据库崩溃时,最近写入到内存但还没落地到磁盘的数据丢失,在数据写入内存表前,先在日志文件中追加写该数据,每当内存表写入段文件时,该日志文件就可以被丢弃。否则就用该文件恢复崩溃时丢失的数据。
3,为了处理读请求,首先尝试从内存读取,然后从最新的段文件读到最旧的段文件。当一个key不存在时,这种扫描算法就很慢。为了优化这种访问,维护一个额外的布隆过滤器,如果key不存在布隆过滤器中,那么key肯定不存在。
4,同样类似bitcask,后台进程周期性合并段文件。
三,基于合并和压缩排序文件原理的存储引擎,通常都被称为LSM-Tree。如leveldb、RocksDB都是基于LSM-Tree的思想实现。受到了google的bigtable论文的启发。
参考《数据密集型应用系统设计》
原文出自:https://blog.csdn.net/daiyudong2020/article/details/104706867
End;