41–50 of 157 posts
Using one-log-only for an entire system does have its upsides, but it will kill performance. It would be like building a CRUD system with a single mutex for everyone to share.
> If everything’s in one log, there’s nothing to coordinate # On the contrary. Everything becomes coordinated. The entire "log" becomes a giant ass mutex lock. Good luck scaling it.
That has been proven to scale well - the way we implement that in Restate is classical shared nothing physical partitioning, with indexing on a key granularity.
So nothing like a shared mutex unless you want to access the same key, which otherwise your database synchronizes, if you want any reasonable level of consistency.
Using one-log-only for an entire system does have its upsides, but it will kill performance. It would be like building a CRUD system with a single mutex for everyone to share.
I believe you want "one log" in the logical sense. In theory, you could have "one log" per user or group of users, or whatever sharding technique makes sense for multi tenancy model. It can also be "one log" per bounded context - e.g. the entire payment pipeline in one log.
The way our open source project implements that is with a partitioned log and indexes at key-granularity, so it is like virtually a log per key.
I am a huge fan of append-only logs as a fundamental architectural principle. The Log [1] should be required reading for any CS undergraduate. [1]: https://engineering.linkedin.com/distributed-systems/log-wha...
I love them so much that I’ve noodled with building a programming language optimized for using them. Things like types that encode what events are legal in a log, first class support for data versions, fast file read and writes, etc
I’ve been doing a similar thing, although I called it “append only transaction ledgers”. Same idea as a log. A few principles: - The order of log entries does not matter. - Users of the log are peers. No client / server distinction. - When appending a log entry, you can send a copy of the append to all your peers. - You can ask your peers to refresh the latest log entries. - When creating a new entry, it is a very go…
Calling a WAL a ledger, why? Ledger sounds fancier but why would it be a ledger in this case?
> Having a single place (the one log) that forces a linear history of events as the ground truth and owns the decision of who can add to that ground truth, means we don’t have to coordinate much any more. Well, yes, but then you've backed into CAP again because you only have one log.
The application state is defined by the log here, and the log drives retries/recovery, so it doesn't much matter if the process that executes the app code splits off. The log would hydrate another one.
Also the one log is at the granularity of a single key or handler execution. More of a logical log, than a physical log or even partition.
In Restate, we implement a logical log-per-key, backed by a partitioned physical log.
Using one-log-only for an entire system does have its upsides, but it will kill performance. It would be like building a CRUD system with a single mutex for everyone to share.
I believe you want "one log" in the logical sense. In theory, you could have "one log" per user or group of users, or whatever sharding technique makes sense for multi tenancy model. It can also be "one log" per bounded context - e.g. the entire payment pipeline in one log.
If everything’s in one log, there’s nothing to coordinate
Separate logical logs with no need for coordination can only work if they are truly independent systems - no causality between them.
> If everything’s in one log, there’s nothing to coordinate # On the contrary. Everything becomes coordinated. The entire "log" becomes a giant ass mutex lock. Good luck scaling it.
Literally one log - which does indeed reduce your coordination headache, but is susceptible to your "giant ass mutex" comment, and
One log per ... - which brings the coordination problems right back into existence.