迭代器的设计和实现是 leveldb 的精华之一. 前几篇文章都多少提到了迭代器的使用, 本篇让我们深入一下迭代器的设计实现, 也为接下来的几篇剖析打下基础.

本文基于内部分享 <“抄"能力养成系列 – GFS 设计> 整理.

2003 年开始 Google 陆续放出三套系统的设计(GFS/MapReduce/Bigtable), 在互联网届掀起云计算狂潮一直影响至今. 该论文一出, 便催生了 Hadoop 中的 HDFS 的诞生. GFS 作为发轫, 目前许多业界知名的分布式系统设计仍然有着它的影子. 下面就让我们一起看看 GFS 的设计, 希望为各位后续系统研发提供灵感。(Salute to Jeff).

本文基于内部分享 <“抄"能力养成系列 – Gorilla 的设计和实现> 整理.

Gorilla 是 Facebook 于 2015 年开放的一个快速, 可扩展的, 内存式时序数据库. 它的一些设计理念影响了后来的 Prometheus. 本文就其设计和实现进行深入分析希望能为各位后续在系统研发中提供灵感.

memtable 可以看作是 log 文件的内存形式, 但是格式不同. 每个 log 文件在内存有一个对应的 memtable, 它和正在压实的 memtable(所以可能同时有两个 memtable 存在) 以及磁盘上的各个 level 包含的文件构成了数据全集. memtable 的本质就是一个 SkipList.

我们先简单回顾下 log 文件相关的基础知识点, 具体请见 Leveldb 源码详解系列之一: 接口与文件.

log 文件(*.log)保存着数据库最近一系列更新操作, 它相当于 leveldb 的 WAL(write-ahead logging). 当前在用的 log 文件内容同时也会被记录到一个内存数据结构中(即 memtable ). 每个更新操作都被追加到当前的 log 文件和 memtable 中. 当 log 文件大小达到一个预定义的大小时(默认大约 4MB), 这个 log 文件对应的 memtable 就会被转换为一个 sorted string table 文件落盘然后一个新的 log 文件就会被创建以保存未来的更新操作.

[toc]

最新的 Go Weekly 推送了这篇文章, eBPF 作为新时代的剖析工具正在如火如荼发展, 读完感觉用来入门很好, 就根据自己理解编译了这篇文章. 做实验过程遇到一些问题, 在最后加了一个番外章节可参考.

下面正式开始.