Reviewing LevelDB: Part XVIII - Summary

well, i am very happy at the conclusion of this blog post series. beside being one of the longest that i have done, this actually stretched my ability to count using roman numerals.

in summary, i am quite happy that i spent the time reading all of this code. the leveldb codebase is really simple, when you grok what it actually does. there is nothing there that would totally stun a person. what there is there, however, is a lot of accumulated experience in building those sort of things.

you see this all over the place, in the format of the sst, in the way compaction is working, in the ability to add filters, write merging, etc. the leveldb codebase is a really good codebase to read, and i am very happy to have done so. especially since doing this in c++ is way out of m comfort zone. it was also interesting to read what i believe is idiomatic c++ code.

another observation about leveldb is that it is a hard core c++ product. you can’t really take that and use the same approach in a managed environment. in particular, efforts to port leveldb to java ( https://github.com/dain/leveldb/ ) are going to run into hard issues with problems like managing the memory. java, like .net, has issues with allocating large byte arrays, and even from the brief look i took, working with leveldb on java using the codebase as it is would likely put a lot of pressure there.

initially, i wanted to use leveldb as a storage engine for ravendb. since i couldn’t get it compiling & working on windows (and yes, that is a hard requirement. and yes, it has to be compiling on my machine to apply), i thought about just porting it. that isn’t going to be possible. at least not in the trivial sense. too much work is require to make it work properly.

yes, i have an idea, no, you don’t get to hear it at this time .