Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Antidote: CRDT-based distributed database

syncfree.github.io

Post reply on HN
Print view View original

51–60 of 89 posts

Re: Antidote: CRDT-based distributed database

#51

Post by shalabhc »

Related ideas exist in David Reed's 'Atomic Actions' which use pseudotime: http://www.cs.sfu.ca/~vaughan/teaching/431/papers/reed83.pdf:

"thinking about objects as sequences of unchangeable versions, object histories"

"the correct construction and execution of a new atomic action can be accomplished without knowledge of all other atomic actions in the system that might execute concurrently"

Is anyone aware of comparisons between these two streams of ideas (pseudo time based action and CRDT based)?

Re: Antidote: CRDT-based distributed database

#52

Post by teleclimber »

KirinDave wrote: post #39
teleclimber wrote: post #27

Earlier quoted context omitted.

> Making CRDTs consequence-free is ongoing research. What do you mean by that? I found possibly related language on this page the other day [0]: CRDTs are "[t]ypically not suited for editing application with consequent UI." Can you point me in the right direction? My googling got me nowhere. Thanks. [0] https://irisate.com/collaborative-editing-solutions-round-up...

I dunno about that quote, Treedoc works pretty well. In general there are tradeoffs to CRDTs and not everyone loves those tradeoffs. As time goes on we find CRDTs that make better tradeoffs. For example, the earliest examples of CRDT sets grew linearly with the values added to the set, without regard for deletion. For all time. That's a pretty steep cost.

I get it, thank-you.

Re: Antidote: CRDT-based distributed database

#53

Post by readams »

nine_k wrote: post #47
KirinDave wrote: post #37

Earlier quoted context omitted.

Gonna repeat, it is DEFINITELY possible to spend the same money multiple times with one ATM card, using old ATM machines with other payment methods. No, I will not further detail how here.

Interesting! A bit or research in this area may literally pay :)

you can do this but the bank will know and the police will show up.

Re: Antidote: CRDT-based distributed database

#54

Post by spooneybarger »

KirinDave wrote: post #37
nine_k wrote: post #25

Earlier quoted context omitted.

With ATMs and debit cards, I thinks it's generally not true, they seem to use the online mode and update the balance of a checking account within seconds. With credit cards, you can indeed start more transactions against the same balance, and you're never sure in which order they will complete.

Gonna repeat, it is DEFINITELY possible to spend the same money multiple times with one ATM card, using old ATM machines with other payment methods. No, I will not further detail how here.

I can verify this is possible.

Re: Antidote: CRDT-based distributed database

#56

Post by KirinDave »

readams wrote: post #53
nine_k wrote: post #47

Earlier quoted context omitted.

Interesting! A bit or research in this area may literally pay :)

you can do this but the bank will know and the police will show up.

I don't mean to endorse such behavior, but the folks who used a loophole after stealing my ATM card details from a data breach never got caught using a variety of ApplePay based variants of this attack (now fixed, btw).

In general folks who get serious about it never get caught. Which is why folks who give a damn about the world don't talk about specifics on public forums.

Re: Antidote: CRDT-based distributed database

#57

Post by OhDagny »

elvinyung wrote: post #9
Cieplak wrote: post #3

Looking forward to Kyle Kingsbury’s Jepsen review.

Jepsen goes into detail about general CRDTs here: https://aphyr.com/posts/285-jepsen-riak

yeah, this appears to be Riak, after Riak went kaboom, possibly with anti-customer CRDTs turned on by default rather than the other marketing-friendly modes.

Until we get John Galt to release his all-knowing database that can authoritatively resolve all conflicts and avoid the evil socialist resolution of AP read conflicts from his hidden valley of 1000 men and 1 woman, this will continue to be a hard problem.

Re: Antidote: CRDT-based distributed database

#58

Post by ramchip »

OhDagny wrote: post #57
elvinyung wrote: post #9

Earlier quoted context omitted.

Jepsen goes into detail about general CRDTs here: https://aphyr.com/posts/285-jepsen-riak

yeah, this appears to be Riak, after Riak went kaboom, possibly with anti-customer CRDTs turned on by default rather than the other marketing-friendly modes. Until we get John Galt to release his all-knowing database that can authoritatively resolve all conflicts and avoid the evil socialist resolution of AP read conflicts from his hidden valley of 1000 men and 1 woman, this will continue to be a hard problem.

I don’t think it’s Riak. It just uses riak_core, which is a kind of distribution / sharding framework. Riak itself has new owners and is not going away.

Re: Antidote: CRDT-based distributed database

#59

Post by cmeiklejohn »

OhDagny wrote: post #57
elvinyung wrote: post #9

Earlier quoted context omitted.

Jepsen goes into detail about general CRDTs here: https://aphyr.com/posts/285-jepsen-riak

yeah, this appears to be Riak, after Riak went kaboom, possibly with anti-customer CRDTs turned on by default rather than the other marketing-friendly modes. Until we get John Galt to release his all-knowing database that can authoritatively resolve all conflicts and avoid the evil socialist resolution of AP read conflicts from his hidden valley of 1000 men and 1 woman, this will continue to be a hard problem.

(former Basho engineer and committer on Riak and Antidote)

No, it's not Riak.

[Full disclosure: work was started in 2013/2014, with Basho, as an alternative to Riak and shares Riak Core as a base. At the time, Basho was a member of SyncFree.]

It's built on Riak Core, but it's a lot different from Riak in many ways: no replication in the DC, transactions, more data-types, operation-based CRDTs and not state-based CRDTs, log vs. in-place replacement in the storage backend.

I mean, the analogy is poor: it's even less close than saying that Riak is Cassandra and vice-versa.

Re: Antidote: CRDT-based distributed database

#60

Post by devit »

xinsight wrote: post #4

The video lists pros/cons for strongly consistent and eventually consistent databases, but only has pros for a "just right consistency" database. What are the cons?

Correct database implementations must be strongly consistent, unless your updates all commute with each other, in which case eventual consistency works.

E.g. db[key] += value and db[key].insert(value) commute with themselves, but db[key] = value obviously doesn't.

This just seems to be an attempt to implement a correct eventually consistent database, and the CRDTs are simply datatypes with commutative update operations.

Unfortunately, it seems to allow transactions that examine objects and then (conditionally) update them, which obviously are not guaranteed to be commutative even if the objects are commutative, so maybe it doesn't succeed at implementing a correct database.

Post reply on HN