Reviewing LevelDB: Part XV–MemTables gets compacted too
Join the DZone community and get the full member experience.
Join For Free
as mentioned before, every 4 mb or so, we will move the current memtable and switch to a new one, turning the current one into an immutable memtable, which will then be compacted to disk. this post is about that process. the work there is done by the surprisingly name: dbimpl::compactmemtable, which then calls to writelevel0table.
that method build the actual table, using the same approach i already covered. honestly, the code is pretty obvious now that i spent enough time reading this. the only thing of interest is deleteobsoletefiles() method, which looks interesting if only because it is one of the few places leveldb actually does real work with files. mostly, however, parsefilename is interesting:
it give me a good way to look at the actual files being used. this will be important when we will investigate how leveldb handles recovery.
leveldb will consider files obsolete if:
- they are log files and aren't of the current/previous log number.
- if it is a manifest file, keep the current one (or later if there are any).
- if it is a table file, keep it if it is in use. a table file may have been compacted away.
- if it is a lock file, info log or the current db file.
all of this is interesting, but on a minor level. i think that we are nearing the end of the codebase now. the only thing that i really want to go into is the recovery parts, and that would pretty much be it.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments