Joedb, the Journal-Only Embedded Database
1–10 of 14 posts
Re: Joedb, the Journal-Only Embedded Database
#2An approach very close to one I've been thinking about lately.
My three cents: compact the journal when its size exceeds the actual data size. With thresholds or other knobs; with the point being the initial load time should be directly proportional to the amount of actual data. Everything else/older is a backup.
Re: Joedb, the Journal-Only Embedded Database
#3An approach very close to one I've been thinking about lately. My three cents: compact the journal when its size exceeds the actual data size. With thresholds or other knobs; with the point being the initial load time should be directly proportional to the amount of actual data. Everything else/older is a backup.
The value of the journal having history (with comments and timestamps) is huge. I think what I'd prefer to see is having a start sequence of replay journal, build in-memory structure, optionally move old journal to backup name and write out minimal/compressed/comment-and-timestamp-stripped journal to new file. Optionally could be based on size delta; e.g. write if it's less than half the size of the old journal. This keeps journals as append only, while still giving access to full history. It does require some external management to avoid file usage growth even faster than a single journal; but it reduces startup time, and allows a management strategy like just deleting backup files older than a given date (once they're in cold backup, if needed).
Re: Joedb, the Journal-Only Embedded Database
#4Was going to say that I hope Joe doesn't end up going to prison for an unspeakable crime, but then I saw it was an acronym.
Re: Joedb, the Journal-Only Embedded Database
#5An approach very close to one I've been thinking about lately. My three cents: compact the journal when its size exceeds the actual data size. With thresholds or other knobs; with the point being the initial load time should be directly proportional to the amount of actual data. Everything else/older is a backup.
The value of the journal having history (with comments and timestamps) is huge. I think what I'd prefer to see is having a start sequence of replay journal, build in-memory structure, optionally move old journal to backup name and write out minimal/compressed/comment-and-timestamp-stripped journal to new file. Optionally could be based on size delta; e.g. write if it's less than half the size of the old journal. This…
It is very valuable but compaction enables a number of use cases where events are generated in significant quantity or you need to save space, like if you’re implementing event sourcing at thw GUI layer (the event store is basically a journal).
Re: Joedb, the Journal-Only Embedded Database
#6Was going to say that I hope Joe doesn't end up going to prison for an unspeakable crime, but then I saw it was an acronym.
Is that a Reiser reference or am I missing something?
Re: Joedb, the Journal-Only Embedded Database
#7Earlier quoted context omitted.
The value of the journal having history (with comments and timestamps) is huge. I think what I'd prefer to see is having a start sequence of replay journal, build in-memory structure, optionally move old journal to backup name and write out minimal/compressed/comment-and-timestamp-stripped journal to new file. Optionally could be based on size delta; e.g. write if it's less than half the size of the old journal. This…
It is very valuable but compaction enables a number of use cases where events are generated in significant quantity or you need to save space, like if you’re implementing event sourcing at thw GUI layer (the event store is basically a journal).
But the event store is also your undo stack, then. Keeping it infinite (or deliberately trimming it at application launch) improves user experience.
Re: Joedb, the Journal-Only Embedded Database
#8Earlier quoted context omitted.
It is very valuable but compaction enables a number of use cases where events are generated in significant quantity or you need to save space, like if you’re implementing event sourcing at thw GUI layer (the event store is basically a journal).
But the event store is also your undo stack, then. Keeping it infinite (or deliberately trimming it at application launch) improves user experience.
You can selectively compact the journal to only compact the numerous GUI events leaving domain events uncompacted (I do this for a CAD app I develop)
Re: Joedb, the Journal-Only Embedded Database
#9KV store in Rust, backed by a disaggregated, replicated journal https://github.com/s2-streamstore/s2-kv-demo
Re: Joedb, the Journal-Only Embedded Database
#10If you have reliable file locking you can implement a journal-only with multiple users without needing a server. You have to take care of write errors and deal with partial writes, which can be tricky with a binary format. A long time ago, I implemented one based on XML. Some non-Windows file-severs (citrix?) did not have reliable file locking, causing corrupted files.