hesela.devBitcask
Bitcask is a log-structured key-value store that locates appended records through an in-memory hash index called the keydir.
Layout: Writes append records and update the keydir. The complete keydir must fit in RAM even when values do not. Merging copies live records from older files. [1]
Startup: The original design can share an existing keydir within one Erlang VM. Otherwise it reconstructs the index from data files, using smaller hint files where available. Hints accelerate reconstruction but do not replace stored values. [1]
Synchronization: At revision d84c8d9, sync_strategy defaults to none. The {seconds, N} setting requires the caller to schedule sync calls. The default Erlang I/O backend warns that o_sync is unsupported, so selecting that option alone does not establish synchronized writes. Its explicit file_sync path calls file:sync. [2] [3] [4]
Relations
Limitations
- The hash index is not an ordered LSM-tree index; the two layouts should not be treated as interchangeable for range-query planning. [1, 5]
Citations
- Sheehy and Smith. Bitcask: A Log-Structured Hash Table for Fast Key/Value Data. 27 April 2010, pp. 2-6.
- Bitcask configuration at d84c8d9: default strategy and caller-owned periodic synchronization.
- Bitcask I/O dispatch at d84c8d9: default Erlang backend selection.
- Bitcask Erlang file backend at d84c8d9: unsupported o_sync option and explicit file synchronization.
- Lu et al. WiscKey. USENIX FAST 2016, sections 3.2-3.3: ordered index and separate value log.
Sources & caveats
- The 2010 design paper and implementation revision d84c8d913713da8f02403431217405f84ee1ba22 describe different historical snapshots.
- Source review only: no Bitcask execution, power-loss experiment or performance reproduction. Backend behavior is revision-specific.