Open levy5307 opened 2 years ago
https://levy5307.github.io/blog/BitCask/
Bitcask的起源与Riak分布式数据库的历史密切相关。在Riak kv集群中，每一个节点使用可插拔式的本地存储引擎，几乎一切kv形式的存储引擎都可以被用来作为每一个主机的存储引擎。这种可插拔性允许Riak的处理并行化，以便存储引擎可以在不影响其它代码的情况下去做改进和测试。
目前有许多类似的本地KV存储引擎，包括但不限于Berkeley DB, Tokyo Cabinet以及Innostore。在评估此类存储引擎的时候，我们寻求了许多目标，包括：
每个item读或写低延迟 高吞吐量，尤其是随机写入 有处理比RAM大得多的dataset的能力，并且不会降级 崩溃友好，可以快速恢复并且数据零丢失 易于备份和恢复 一份相对简单、易于理解的代码结构和数据格式 在高访问负载或大容量的情况下的行为可预测 允许在Riak中轻松默认使用的许可证
实现部分上述目标很简单，但是实现所有目标则很难。
对于上述所有目标，没有一个可用的本地KV存储引擎是理想的。我们与Eric Brewer讨论这个问题的时候，他有一个关于hash table log merging的重要见解：那样做和LSM-树一样快，甚至更快。
这促使我们以一种新的方式探索在20世纪80年代和90年代首次开发的日志结构文件系统中使用的一些技术。这场探索导致了Bitcask的开发，这是一种能完美满足上述所有目标的存储系统。虽然Bitcask最初的开发目标是在Riak下使用，但是它是通用的，也可以作为其它应用程序的本地KV存储引擎。
我们最终采用的模型在概念上非常简单。Bitcask实例是一个目录，我们强制在给定时间只有一个操作系统进程会打开Bitcask进行写操作。您可以将该进程视为database server。在任何时候，该目录中的一个文件是active状态的，供服务器写入。当该文件大小达到阈值时，它将被关闭，并创建一个新的active文件。一旦一个文件被关闭，无论是有意的还是由于服务器退出，它都被认为是不可变的，并且永远不会再打开进行写入。
active文件只通过追加方式写入，这意味着顺序写入，从而不需要磁盘查找。每个kv entry的格式很简单：
每一次写入，一个新的entry会被添加到active文件中。需要注意的是，删除只是写了一个特殊的标记，其将在下一次合并的时候被移除掉。所以，Bitcask data file只不过是这些entry的线性序列。
https://levy5307.github.io/blog/BitCask/
Bitcask的起源与Riak分布式数据库的历史密切相关。在Riak kv集群中，每一个节点使用可插拔式的本地存储引擎，几乎一切kv形式的存储引擎都可以被用来作为每一个主机的存储引擎。这种可插拔性允许Riak的处理并行化，以便存储引擎可以在不影响其它代码的情况下去做改进和测试。
目前有许多类似的本地KV存储引擎，包括但不限于Berkeley DB, Tokyo Cabinet以及Innostore。在评估此类存储引擎的时候，我们寻求了许多目标，包括：
实现部分上述目标很简单，但是实现所有目标则很难。
对于上述所有目标，没有一个可用的本地KV存储引擎是理想的。我们与Eric Brewer讨论这个问题的时候，他有一个关于hash table log merging的重要见解：那样做和LSM-树一样快，甚至更快。
这促使我们以一种新的方式探索在20世纪80年代和90年代首次开发的日志结构文件系统中使用的一些技术。这场探索导致了Bitcask的开发，这是一种能完美满足上述所有目标的存储系统。虽然Bitcask最初的开发目标是在Riak下使用，但是它是通用的，也可以作为其它应用程序的本地KV存储引擎。
我们最终采用的模型在概念上非常简单。Bitcask实例是一个目录，我们强制在给定时间只有一个操作系统进程会打开Bitcask进行写操作。您可以将该进程视为database server。在任何时候，该目录中的一个文件是active状态的，供服务器写入。当该文件大小达到阈值时，它将被关闭，并创建一个新的active文件。一旦一个文件被关闭，无论是有意的还是由于服务器退出，它都被认为是不可变的，并且永远不会再打开进行写入。
active文件只通过追加方式写入，这意味着顺序写入，从而不需要磁盘查找。每个kv entry的格式很简单：
每一次写入，一个新的entry会被添加到active文件中。需要注意的是，删除只是写了一个特殊的标记，其将在下一次合并的时候被移除掉。所以，Bitcask data file只不过是这些entry的线性序列。