Memory That Collaborates
datahike.io
Memory That Collaborates
1–7 of 7 posts
Re: Memory That Collaborates
#2Immutability indeed gives a lot of features to a data store, because nothing ever can go invalid. Doing anything in parallel is trivial. Caching anything is totally safe. Distributed queries can be certain that the other side did not change during a distributed transaction.
The cost of it, AFAICT, is either unbounded growth, or garbage collection, if deletion is even supported.
There are use case for a DB like that, but, unfortunately, it cannot replace most OLTP use cases.
Re: Memory That Collaborates
#3"This is an idea Rich Hickey introduced with Datomic in 2012: "
I am pretty sure the difference between online transaction processing and online analysis processing goes back a bit further than 2012.
Re: Memory That Collaborates
#4[flagged]
Re: Memory That Collaborates
#5Immutability indeed gives a lot of features to a data store, because nothing ever can go invalid. Doing anything in parallel is trivial. Caching anything is totally safe. Distributed queries can be certain that the other side did not change during a distributed transaction. The cost of it, AFAICT, is either unbounded growth, or garbage collection, if deletion is even supported. There are use case for a DB like that,…
It’s also inapplicable for anything with sensitive data that has legally limited retention periods or the “right to erasure”.
Re: Memory That Collaborates
#6Immutability indeed gives a lot of features to a data store, because nothing ever can go invalid. Doing anything in parallel is trivial. Caching anything is totally safe. Distributed queries can be certain that the other side did not change during a distributed transaction. The cost of it, AFAICT, is either unbounded growth, or garbage collection, if deletion is even supported. There are use case for a DB like that,…
It’s also inapplicable for anything with sensitive data that has legally limited retention periods or the “right to erasure”.
Why, no, deletion is possible in immutable structures, as long as nothing else references the deleted nodes. This is literally how lists / trees / any complex structures work in Haskell (and apparently in Clojure): a mutation gives you a new immutable structure, but the old immutable structure (or parts thereof) can be forgotten and disposed of.
Re: Memory That Collaborates
#7Earlier quoted context omitted.
It’s also inapplicable for anything with sensitive data that has legally limited retention periods or the “right to erasure”.
Why, no, deletion is possible in immutable structures, as long as nothing else references the deleted nodes. This is literally how lists / trees / any complex structures work in Haskell (and apparently in Clojure): a mutation gives you a new immutable structure, but the old immutable structure (or parts thereof) can be forgotten and disposed of.
It’s very common, however, that data will reference the data to be deleted, or be derived from it in a way that will become invalid when it’s deleted. Parallel processing becomes less straightforward because you have to make sure that all parallel processes see a consistent state of the deletion. Depending on the nature of the data to be deleted, you may actually have potential mutation, if there are keys that are sensitive data.