Nice to see that temporal or even bitempiral database systems get developed lately more and more (but most of the time just as extensions to an existing system), thus I enjoyed reading about your native approach.
Do you store all revisions in one huge LSM- tree indexed by the transactional start- and end-times?
I'm developing one myself (already started around 2005 or 2006 by a Ph.D. student) and I'm still eager to put forth the ideas of a versioned data store :-)
2 comments
[ 5.5 ms ] story [ 17.6 ms ] threadDo you store all revisions in one huge LSM- tree indexed by the transactional start- and end-times?
I'm developing one myself (already started around 2005 or 2006 by a Ph.D. student) and I'm still eager to put forth the ideas of a versioned data store :-)
Specifically, RocksDB uses an LSM tree whilst LMDB uses a B+ tree. You can get a feel for how Crux maintains its indexes here: https://github.com/juxt/crux/blob/master/src/crux/codec.clj#...
Crux doesn't natively track valid-to (end) times, but you can transact a Delete into the future to achieve the same logical result.