Hi Kenton! No worries at all. I tend to be quieter than Jeff anyway (less public speaking etc.) and I am happy to not have a dedicated website. :-). -Sanjay
Not your fault. We just plain forgot to update the documentation, so the freshest available document is a few years out of date.
About [1] Sorry about that: the document you linked to is amazingly stale. tcmalloc has been releasing memory to the system for many years. See for example the IncrementalScavenge routine in a version of page_heap.cc…
We have no such plans. The library is designed so that concurrency control is outside its scope. If I needed it for an application, I might consider using some application level code that looks like: bool CAS(db, key,…
The use of c++0x should be limited to the small AtomicPointer class in port_posix.h. The class uses <cstdatomic> for its implementation. If you can provide a different implementation of "acquire store" and…
Merely an incomplete one. Leveldb never writes in place: it always appends to a log file, or merges existing files together to produce new ones. So an OS crash will cause a partially written log record (or a few…
leveldb is a persistent ordered map; bitcask is a persistent hash table (no ordered iteration). bitcask stores a fixed size record in memory for every key. So for databases with large number of keys, it may use too much…
One of the leveldb authors here. TokyoCabinet is something we seriously considered using instead of writing leveldb. TokyoCabinet has great performance usually. I haven't done a careful head-to-head comparison, but it…
It is durable from an OS perspective. I started typing in a long explanation, but I think the comment for the "sync" field in the options.h file captures things well: struct WriteOptions { // If true, the write will be…
Hi Kenton! No worries at all. I tend to be quieter than Jeff anyway (less public speaking etc.) and I am happy to not have a dedicated website. :-). -Sanjay
Not your fault. We just plain forgot to update the documentation, so the freshest available document is a few years out of date.
About [1] Sorry about that: the document you linked to is amazingly stale. tcmalloc has been releasing memory to the system for many years. See for example the IncrementalScavenge routine in a version of page_heap.cc…
We have no such plans. The library is designed so that concurrency control is outside its scope. If I needed it for an application, I might consider using some application level code that looks like: bool CAS(db, key,…
The use of c++0x should be limited to the small AtomicPointer class in port_posix.h. The class uses <cstdatomic> for its implementation. If you can provide a different implementation of "acquire store" and…
Merely an incomplete one. Leveldb never writes in place: it always appends to a log file, or merges existing files together to produce new ones. So an OS crash will cause a partially written log record (or a few…
leveldb is a persistent ordered map; bitcask is a persistent hash table (no ordered iteration). bitcask stores a fixed size record in memory for every key. So for databases with large number of keys, it may use too much…
One of the leveldb authors here. TokyoCabinet is something we seriously considered using instead of writing leveldb. TokyoCabinet has great performance usually. I haven't done a careful head-to-head comparison, but it…
It is durable from an OS perspective. I started typing in a long explanation, but I think the comment for the "sync" field in the options.h file captures things well: struct WriteOptions { // If true, the write will be…