[HN Gopher] Trade-offs between Different CRDTs
___________________________________________________________________
Trade-offs between Different CRDTs
Author : iamwil
Score : 72 points
Date : 2024-01-08 19:13 UTC (3 hours ago)
(HTM) web link (interjectedfuture.com)
(TXT) w3m dump (interjectedfuture.com)
| zachmu wrote:
| Apparently he's going to write about Merkle CRDTs next, but if
| you can't wait:
|
| https://www.dolthub.com/blog/2022-06-27-prolly-chunker/
| iamwil wrote:
| And if you really can't wait, I made the mistake of thinking
| Prolly Trees weren't unicit, but figuring out that they were!
|
| https://interjectedfuture.com/lab-notes/lab-note-030-the-tri...
| aboodman wrote:
| Wow, I hadn't seen this follow-up post! Cool!
|
| (btw I really love your masthead graphics)
| foota wrote:
| Will those comment eventually update once the blog is appended?
| :-)
| quartz wrote:
| If you're just getting started with CRDTs I'd also recommend
| Seph's "5000x faster CRDTs" post[1] and also his "I was wrong.
| CRDTs are the future" post[2] for some nice captures of the
| practical challenges and opportunities in the space.
|
| [1] https://josephg.com/blog/crdts-go-brrr/
|
| [2] https://josephg.com/blog/crdts-are-the-future/
| lewisjoe wrote:
| This is a clear and crisp way of differentiating delta based vs
| state based CRDTs.
|
| But I don't think it's accurate enough. For example, the article
| claims delta based CRDTs don't use vector clocks. But even to
| decide if a set of events are concurrent it's necessary to attach
| vector stamps to every event. Maybe the author meant something
| else when he says vector clocks are not needed for op based
| CRDTs.
|
| Also as mentioned in article it's true evergrowing event log is
| not such a bad idea with compression techniques and cheaper
| disks. But the problem with evergrowing datastructures is not
| just disk space. This data has to be loaded onto main memory to
| do anything useful with it. This data has to be transmitted
| across network to power SaaS apps. So stating that disks are
| cheaper hence evergrowing datastructures are fine - is an
| oversimplification.
| wim wrote:
| Nice outline of the various techniques. We've built something in-
| between the operation-based and delta-based approaches for our
| offline-first multiplayer "IDE for notes/tasks" [1].
|
| In our case we have a central server which periodically creates
| snapshots. Although we don't do that right now, if needed, it
| could delete older operations from the log for space reasons.
| Except for the fact that replicas encrypt their ops before they
| send it to the server (e2ee), the server is pretty much like any
| other replica, so if there is no central server I guess any or
| multiple replicas could also create snapshots instead.
|
| "Normal" replicas which have been offline for a while can then
| get the last snapshot state S' with all operations since S'.
| Other than that, they simply broadcast operations and only keep
| their own latest version to which they apply incoming operations.
|
| [1] https://thymer.com
___________________________________________________________________
(page generated 2024-01-08 23:00 UTC)