从零实现一个 k-v 存储引擎

写这篇文章的目的,是为了帮助更多的人理解 rosedb,我会从零开始实现一个简单的包含 PUT、GET、DELETE 操作的 k-v 存储引擎,你可以将其看做是一个简易版本的 rosedb,就叫它 minidb 吧(mini 版本的 rosedb)。

无论你是 Go 语言初学者,还是想进阶 Go 语言,或者是对 k-v 存储感兴趣,都可以尝试自己动手实现一下,我相信一定会对你帮助很大的。


说到存储,其实解决的一个核心问题就是,怎么存放数据,怎么取出数据。在计算机的世界里,这个问题会更加的多样化。

计算机当中有内存和磁盘,内存是易失性的,掉电之后存储的数据全部丢失,所以,如果想要系统崩溃再重启之后依然正常使用,就不得不将数据存储在非易失性介质当中,最常见的便是磁盘。

所以,针对一个单机版的 k-v,我们需要设计数据在内存中应该怎么存放,在磁盘中应该怎么存放。

当然,已经有很多优秀的前辈们去探究过了,并且已经有了经典的总结,主要将数据存储的模型分为了两类:B+ 树和 LSM 树。

本文的重点不是讲这两种模型,所以只做简单介绍。

B+ 树

B+ 树由二叉查找树演化而来,通过增加每层节点的数量,来降低树的高度,适配磁盘的页,尽量减少磁盘 IO 操作。

B+ 树查询性能比较稳定,在写入或更新时,会查找并定位到磁盘中的位置并进行原地操作,注意这里是随机 IO,并且大量的插入或删除还有可能触发页分裂和合并,写入性能一般,因此 B+ 树适合读多写少的场景。

LSM 树

LSM Tree(Log Structured Merge Tree,日志结构合并树)其实并不是一种具体的树类型的数据结构,而只是一种数据存储的模型,它的核心思想基于一个事实:顺序 IO 远快于随机 IO。

和 B+ 树不同,在 LSM 中,数据的插入、更新、删除都会被记录成一条日志,然后追加写入到磁盘文件当中,这样所有的操作都是顺序 IO。

LSM 比较适用于写多读少的场景。


看了前面的两种基础存储模型,相信你已经对如何存取数据有了基本的了解,而 minidb 基于一种更加简单的存储结构,总体上它和 LSM 比较类似。

我先不直接干巴巴的讲这个模型的概念,而是通过一个简单的例子来看一下 minidb 当中数据 PUT、GET、DELETE 的流程,借此让你理解这个简单的存储模型。

PUT

我们需要存储一条数据,分别是 key 和 value,首先,为预防数据丢失,我们会将这个 key 和 value 封装成一条记录(这里把这条记录叫做 Entry),追加到磁盘文件当中。Entry 的里面的内容,大致是 key、value、key 的大小、value 的大小、写入的时间。

所以磁盘文件的结构非常简单,就是多个 Entry 的集合。

磁盘更新完了,再更新内存,内存当中可以选择一个简单的数据结构,比如哈希表。哈希表的 key 对应存放的是 Entry 在磁盘中的位置,便于查找时进行获取。

这样,在 minidb 当中,一次数据存储的流程就完了,只有两个步骤:一次磁盘记录的追加,一次内存当中的索引更新。

GET

再来看 GET 获取数据,首先在内存当中的哈希表查找到 key 对应的索引信息,这其中包含了 value 存储在磁盘文件当中的位置,然后直接根据这个位置,到磁盘当中去取出 value 就可以了。

DEL

然后是删除操作,这里并不会定位到原记录进行删除,而还是将删除的操作封装成 Entry,追加到磁盘文件当中,只是这里需要标识一下 Entry 的类型是删除。

然后在内存当中的哈希表删除对应的 key 的索引信息,这样删除操作便完成了。

可以看到,不管是插入、查询、删除,都只有两个步骤:一次内存中的索引更新,一次磁盘文件的记录追加。所以无论数据规模如何, minidb 的写入性能十分稳定。

Merge

最后再来看一个比较重要的操作,前面说到,磁盘文件的记录是一直在追加写入的,这样会导致文件容量也一直在增加。并且对于同一个 key,可能会在文件中存在多条 Entry(回想一下,更新或删除 key 内容也会追加记录),那么在数据文件当中,其实存在冗余的 Entry 数据。

举一个简单的例子,比如针对 key A, 先后设置其 value 为 10、20、30,那么磁盘文件中就有三条记录:

此时 A 的最新值是 30,那么其实前两条记录已经是无效的了。

针对这种情况,我们需要定期合并数据文件,清理无效的 Entry 数据,这个过程一般叫做 merge。

merge 的思路也很简单,需要取出原数据文件的所有 Entry,将有效的 Entry 重新写入到一个新建的临时文件中,最后将原数据文件删除,临时文件就是新的数据文件了。

这就是 minidb 底层的数据存储模型,它的名字叫做 bitcask,当然 rosedb 采用的也是这种模型。它本质上属于类 LSM 的模型,核心思想是利用顺序 IO 来提升写性能,只不过在实现上,比 LSM 简单多了。


介绍完了底层的存储模型,就可以开始代码实现了,我将完整的代码实现放到了我的 Github 上面,地址:

https://github.com/roseduan/minidb

文章当中就截取部分关键的代码。

首先是打开数据库,需要先加载数据文件,然后取出文件中的 Entry 数据,还原索引状态,关键部分代码如下:

func Open(dirPath string) (*MiniDB, error) {   // 如果数据库目录不存在,则新建一个   if _, err := os.Stat(dirPath); os.IsNotExist(err) {      if err := os.MkdirAll(dirPath, os.ModePerm); err != nil {         return nil, err      }   }
   // 加载数据文件   dbFile, err := NewDBFile(dirPath)   if err != nil {      return nil, err   }
   db := &MiniDB{      dbFile:  dbFile,      indexes: make(map[string]int64),      dirPath: dirPath,   }
   // 加载索引   db.loadIndexesFromFile(dbFile)   return db, nil}

复制代码

再来看看 PUT 方法,流程和上面的描述一样,先更新磁盘,写入一条记录,再更新内存:

func (db *MiniDB) Put(key []byte, value []byte) (err error) {     offset := db.dbFile.Offset   // 封装成 Entry   entry := NewEntry(key, value, PUT)   // 追加到数据文件当中   err = db.dbFile.Write(entry)
   // 写到内存   db.indexes[string(key)] = offset   return}

复制代码

GET 方法需要先从内存中取出索引信息,判断是否存在,不存在直接返回,存在的话从磁盘当中取出数据。

func (db *MiniDB) Get(key []byte) (val []byte, err error) {   // 从内存当中取出索引信息   offset, ok := db.indexes[string(key)]   // key 不存在   if !ok {      return   }
   // 从磁盘中读取数据   var e *Entry   e, err = db.dbFile.Read(offset)   if err != nil && err != io.EOF {      return   }   if e != nil {      val = e.Value   }   return}

复制代码

DEL 方法和 PUT 方法类似,只是 Entry 被标识为了 DEL ,然后封装成 Entry 写到文件当中:

func (db *MiniDB) Del(key []byte) (err error) {   // 从内存当中取出索引信息   _, ok := db.indexes[string(key)]   // key 不存在,忽略   if !ok {      return   }
   // 封装成 Entry 并写入   e := NewEntry(key, nil, DEL)   err = db.dbFile.Write(e)   if err != nil {      return   }
   // 删除内存中的 key   delete(db.indexes, string(key))   return}

复制代码

最后是重要的合并数据文件操作,流程和上面的描述一样,关键代码如下:

func (db *MiniDB) Merge() error {   // 读取原数据文件中的 Entry   for {      e, err := db.dbFile.Read(offset)      if err != nil {         if err == io.EOF {            break         }         return err      }      // 内存中的索引状态是最新的,直接对比过滤出有效的 Entry      if off, ok := db.indexes[string(e.Key)]; ok && off == offset {         validEntries = append(validEntries, e)      }      offset += e.GetSize()   }
   if len(validEntries) > 0 {      // 新建临时文件      mergeDBFile, err := NewMergeDBFile(db.dirPath)      if err != nil {         return err      }      defer os.Remove(mergeDBFile.File.Name())
      // 重新写入有效的 entry      for _, entry := range validEntries {         writeOff := mergeDBFile.Offset         err := mergeDBFile.Write(entry)         if err != nil {            return err         }
         // 更新索引         db.indexes[string(entry.Key)] = writeOff      }
      // 删除旧的数据文件      os.Remove(db.dbFile.File.Name())      // 临时文件变更为新的数据文件      os.Rename(mergeDBFile.File.Name(), db.dirPath+string(os.PathSeparator)+FileName)
      db.dbFile = mergeDBFile   }   return nil}

复制代码

除去测试文件,minidb 的核心代码只有 300 行,麻雀虽小,五脏俱全,它已经包含了 bitcask 这个存储模型的主要思想,并且也是 rosedb 的底层基础。

理解了 minidb 之后,基本上就能够完全掌握 bitcask 这种存储模型,多花点时间,相信对 rosedb 也能够游刃有余了。

进一步,如果你对 k-v 存储这方面感兴趣,可以更加深入的去研究更多相关的知识,bitcask 虽然简洁易懂,但是问题也不少,rosedb 在实践的过程当中,对其进行了一些优化,但目前还是有不少的问题存在。

有的人可能比较疑惑,bitcask 这种模型简单,是否只是一个玩具,在实际的生产环境中有应用吗?答案是肯定的。

bitcask 最初源于 Riak 这个项目的底层存储模型,而 Riak 是一个分布式 k-v 存储,在 NoSQL 的排名中也名列前茅:

豆瓣所使用的的分布式 k-v 存储,其实也是基于 bitcask 模型,并对其进行了很多优化。目前纯粹基于 bitcask 模型的 k-v 并不是很多,所以你可以多去看看 rosedb 的代码,可以提出自己的意见建议,一起完善这个项目。

最后,附上相关项目地址:

minidb:https://github.com/roseduan/minidb

rosedb:https://github.com/roseduan/rosedb

参考资料:

https://riak.com/assets/bitcask-intro.pdf

https://medium.com/@arpitbhayani/bitcask-a-log-structured-fast-kv-store-c6c728a9536b

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/23ce313ad1d423f6bbf8a3e15
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券