If 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.
An 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).
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).
Only for some use cases. I don’t think the parent is arguing for forcing compaction. I’d personally use this with periodic compaction (cronjob), but I can see the utility either way.
If 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.
Was 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?
An 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).
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.
Only for some use cases. I don’t think the parent is arguing for forcing compaction. I’d personally use this with periodic compaction (cronjob), but I can see the utility either way.
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)
KV store in Rust, backed by a disaggregated, replicated journal https://github.com/s2-streamstore/s2-kv-demo