Traditional C based BerkeleyDB is not log structured. BerkeleyDB JE is log structured, but is in Java. I don't see cperciva coding Java and the drawback of Java's IO subsystem is that interaction with page cache can be unpredictable if you're doing something beyond key/value lookups.
BerkeleyDB JE is also designed for low latency operation: the recommended way to run is to keep a checkpoint interval, which is then periodically flushed to disk. The flip side of that is that the larger the checkpoint interval, the longer it takes to recover from a crash (longer segment of the log to validate). It is possible to run it in an "fsync after every txn" mode, however. There are also modes available that allow different levels of transaction isolation and serializability. Looks like Colin wants to support one.
While I'm generally happy with BerkeleyDB JE, I can see Colin's decision especially in the greater context of what he's doing.
Comments
Traditional C based BerkeleyDB is not log structured. BerkeleyDB JE is log structured, but is in Java. I don't see cperciva coding Java and the drawback of Java's IO subsystem is that interaction with page cache can be unpredictable if you're doing something beyond key/value lookups.
BerkeleyDB JE is also designed for low latency operation: the recommended way to run is to keep a checkpoint interval, which is then periodically flushed to disk. The flip side of that is that the larger the checkpoint interval, the longer it takes to recover from a crash (longer segment of the log to validate). It is possible to run it in an "fsync after every txn" mode, however. There are also modes available that allow different levels of transaction isolation and serializability. Looks like Colin wants to support one.
While I'm generally happy with BerkeleyDB JE, I can see Colin's decision especially in the greater context of what he's doing.