Or, every database is bitemporal, some just don’t know it yet
Every System is a Log: Avoiding coordination in distributed applications
131–140 of 157 posts
Re: Every System is a Log: Avoiding coordination in distributed applications
#132Earlier quoted context omitted.
if order does not matter how do you implement deletes?
You don’t do deletes. The log is append only. If you want to get rid of an entry, you create a new entry that negates the existing entry.
Yes, but if order doesn't matter, the delete might appear before the create.
Might be misunderstand something
Re: Every System is a Log: Avoiding coordination in distributed applications
#133Earlier quoted context omitted.
The lack of ordering is surprising. Without that you can’t stream without a buffer.
The idea is that all peers eventually have the same collection of log entries, with an agreed-upon sort method. Currently that sort method is time stamps. When it’s time to have identical replicas, a log entry must be appended that says the log is closed. Once all peers have this, the log is now immutable and can be treated as such. An example of this (for a payroll system) is a collection of entries for time clock i…
> a log entry must be appended that says the log is closed
Related concepts: 'epoch' (distributed consensus), 'watermark' (out-of-order stream processing)
Re: Every System is a Log: Avoiding coordination in distributed applications
#134Earlier quoted context omitted.
The table data in database is the canonical form. You can delete the transaction logs, and temporarily lose some reliability. It is very common to delete the transaction logs when not needed. When databases are backed up, they either dump the logical data or take snapshot of the data. Then can take stream of transaction logs for syncing or backup until the next checkpoint. I'm pretty sure journalled filesystem recycl…
Sorry, this is mistaking the operational for the fundamental. If a transaction log is replayed, then an identical set of relations will be obtained. Ergo, the log is the prime form of the database. It’s that simple.
At a very abstract level, maybe. But it's common not to log changes that can trivially be rolled back, like insertions into a table that was created or truncated within the transaction. Of course, such optimizations are incompatible with log-based replication. So the statement should probably be, “in a system with log-based replication, the log is authoritative, and the tables are just an optimization”. This framing also avoids ambiguities because a transaction log may not be fully serialized, and might not fully determine table contents.
Re: Every System is a Log: Avoiding coordination in distributed applications
#135This is a basic concept in accounting. The general ledger is an immutable log of transactions. Other accounting documents are constructed from the general ledger, and can, if necessary, be rebuilt from it. This is the accepted way to do money-related things. Synchronization is called "reconcilation" in accounting terminology. The computer concept is that we have a current state, and changes to it come in. The databas…
I’ve always concurred with the Helland/Kleppman observation mentioned viz. that the transaction log of a typical RDBMS is the canonical form and all the rows & tables merely projections. It’s curious that over those projections, we then build event stores for CQRS/ES systems, ledgers etc, with their own projections mediated by application code. But look underneath too. The journaled filesystem on which the database r…
we're a very short step away from a "hardware" database
Re: Every System is a Log: Avoiding coordination in distributed applications
#136This post makes a great case for how universal logs are in data systems. It was strange to me that there was no log-as-service with the qualities that make it suitable for building higher-level systems like durable execution: conditional appends (as called out by the post!), support very large numbers of logs, allow pushing high throughputs with strict ordering, and just generally provide a simple serverless experien…
What about journalctl?
Surprisingly and disgustingly so it did not actually use a proper log structure on disk. So much pointer walking...
Re: Every System is a Log: Avoiding coordination in distributed applications
#137Earlier quoted context omitted.
Right but it's not magic as you cannot predict networking delays. The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.
What if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clo...
Thanks for the link, not much familiar with CockroachDB but I worked on a similar system that wanted to provide strong consistency when reading from many databases, some of which where Spanner but not all of them.
Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads for writes.
What I missed the most from Spanner compared to the system above is that its tricky to do client-side transaction chaining where there are many clients and the order is important.
Re: Every System is a Log: Avoiding coordination in distributed applications
#138> Restate is open source and you can download it at...
https://github.com/restatedev/restate/blob/main/LICENSE#L1
> Business Source License 1.1
https://spdx.org/licenses/BUSL-1.1.html
> The Business Source License (this document, or the “License”) is not an Open Source license.
Suggest exploring e.g. https://github.com/dbos-inc/dbos-transact-py
Re: Every System is a Log: Avoiding coordination in distributed applications
#139Re: Every System is a Log: Avoiding coordination in distributed applications
#140Earlier quoted context omitted.
What if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clo...
Thanks for the link, not much familiar with CockroachDB but I worked on a similar system that wanted to provide strong consistency when reading from many databases, some of which where Spanner but not all of them. Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads…
If you put a atomic clock like OCP-TAP Time Card with GNSS receiver in every server and use precision time protocol to sync them you should be able to synchronize quite a few servers to less than 100 nanoseconds.