No; each data producer (customer/person/identity) has their own serialized (as in ordered) queue of events.
Since the system is fully immutable each update would also include the state of the system it is an update to (which can be outdated.)
Essentially you're modelling human communication with each event being equivalent to a human speech act.
For most cases that would offer sufficient conflict resolution and more expensive commit strategies could be used only where more needed; much like how lattice/CALM-based programming languages such as Bloom deal with distribution.
Yes immutable data makes the inserts O(1) but increases the query costs proportionally to the number of producers.
You need to traverse all possible systems states to do a complete lookup.
Encryption also makes server side pruning and garbage collection of old system state difficult unless you just clear everything greater than n days old.
I'm not at all arguing there's a free lunch here. It's a tough cookie to crack and requires a reimagining of half of computing. I also think it's the only possible way to go.
1) As for the query costs; yes they are there. For public data you could still create pre-computed indexes but for privately shared data the recipients/accessors of that data would need to create appropriate indexes.
In general this scheme indeed requires each producer (person/identity) to also maintain their own indexes.
2) I don't get what you mean by doing a complete lookup.
3) Since this would be a fully federated/decentralized system there would not really be such a thing as server side pruning since the 'server' would just be a peer that indexes public data.
Given that data is immutable clients would simply hold on to the data they need for their calculations and could choose to depend on the server to keep a copy for them.
If nobody (wants to pay to) hold onto a copy of some data anymore then it has been garbage collected.
P.S. Have you looked at the Datomic model? It works quite similar to this proposal with regards to things like storage, peering, computing indexes etc.
Comments
The net effect here is that each client must lock the database on insert.
A client can batch multiple inserts but the server cannot batch inserts from multiple clients.
No; each data producer (customer/person/identity) has their own serialized (as in ordered) queue of events.
Since the system is fully immutable each update would also include the state of the system it is an update to (which can be outdated.)
Essentially you're modelling human communication with each event being equivalent to a human speech act.
For most cases that would offer sufficient conflict resolution and more expensive commit strategies could be used only where more needed; much like how lattice/CALM-based programming languages such as Bloom deal with distribution.
I don't think there is a free lunch here.
Yes immutable data makes the inserts O(1) but increases the query costs proportionally to the number of producers.
You need to traverse all possible systems states to do a complete lookup.
Encryption also makes server side pruning and garbage collection of old system state difficult unless you just clear everything greater than n days old.
I'm not at all arguing there's a free lunch here. It's a tough cookie to crack and requires a reimagining of half of computing. I also think it's the only possible way to go.
1) As for the query costs; yes they are there. For public data you could still create pre-computed indexes but for privately shared data the recipients/accessors of that data would need to create appropriate indexes.
In general this scheme indeed requires each producer (person/identity) to also maintain their own indexes.
2) I don't get what you mean by doing a complete lookup.
3) Since this would be a fully federated/decentralized system there would not really be such a thing as server side pruning since the 'server' would just be a peer that indexes public data.
Given that data is immutable clients would simply hold on to the data they need for their calculations and could choose to depend on the server to keep a copy for them.
If nobody (wants to pay to) hold onto a copy of some data anymore then it has been garbage collected.
P.S. Have you looked at the Datomic model? It works quite similar to this proposal with regards to things like storage, peering, computing indexes etc.