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

Distributed Databases Should Work More Like CDNs

cockroachlabs.com

Post reply on HN
Print view View original

31–40 of 86 posts

Re: Distributed Databases Should Work More Like CDNs

#31

Post by merb »

imtringued wrote: post #30
zzzcpan wrote: post #26

> When partitions heal, you might have to make ugly decisions: which version of your customer’s data to you choose to discard? If two partitions received updates, it’s a lose-lose situation. When partitions heal you simply merge all versions through conflict-free replicated data types. No ugly decisions, no sacrificing neither latency nor consistency. We call it strong eventual consistency [1] nowadays. And it's exac…

My application is just plain old CRUD. What if two users want to change e.g. the telephone number of an existing record during a network partition. There just is no obvious way to merge a telephone number. One of them is correct, the other is incorrect. Can CRDTs solve my simple problem?

I think the issue is solved (while still complex) with an event sourcing system. The chances are really high that the users did not push / updated the number at the exact same time. (so they are at least 1ns apart, even when not it's not that bad). So you can actually restore to a sane state by reapplying the log from scratch.

i.e. this is solved with CQRS and Event Sourcing and it probably works in like all databases. It's quite complex but pretty reliable, I'm pretty sure that everybody already built at least a extremly simple append only event log.

Re: Distributed Databases Should Work More Like CDNs

#32

Post by astine »

AYBABTME wrote: post #29
astine wrote: post #23

Sooo, being able to distribute data globally is good for performance? Who knew? The thing about distributed systems, including distributed databases is that they need to navigate around the the CAP theorem(Consistency, Availability, Partition Tolerance, pick two, essentially,) and every solution is ultimately a trade off. This article would be a lot more interesting if it showed how CockroachDB made a better trade of…

The article they link at the end explains this: https://www.cockroachlabs.com/docs/stable/transactions.html

Thanks, I got the answer to questions I was asking from CDB FAQ, actually. I just wish this article in particular was less fluffy.

Re: Distributed Databases Should Work More Like CDNs

#33

Post by marknadal »

astine wrote: post #23

Sooo, being able to distribute data globally is good for performance? Who knew? The thing about distributed systems, including distributed databases is that they need to navigate around the the CAP theorem(Consistency, Availability, Partition Tolerance, pick two, essentially,) and every solution is ultimately a trade off. This article would be a lot more interesting if it showed how CockroachDB made a better trade of…

Also a distributed database engineer, and while I disagree with CockroachDB's CAP Theorem tradeoff decisions, they are definitely well reasoned and principled.

RethinkDB was Master-Slave (strongly consistent) with an amazing developer community and actually survived Aphyr's tests better than most systems.

CockroachDB is also in the Master-Slave (strongly consistent) camp, but more enterprise focused, and therefore will probably not fail, however their Aphyr report worked... but was unfortunately very slow. But hey, being strongly consistent is hard and correctness is a necessary tradeoff from performance.

Other systems, like Cassandra, us (https://github.com/amark/gun), Couch/Pouch, etc. are all in the Master-Master camp, and thus AP not CP. Our argument is that while P holds, realtime sync with Strong Eventual Consistency is good enough yet has all the performance benefits, for everything except for banking. Sure, use Rethink/Cockroach for banking (heck, better yet, Postgres!), but for fun-and-games you can do banking on top of AP systems if you use a CRDT or blockchain (although that kills performance, CRDTs don't) on top.

So yeah, I agree with you about CAP Theorem and stuff, disagree with Cockroach's particular choice - but they do have some pretty great detailed explainers/documentation on their view, and therefore should be treated seriously and not written off.

Re: Distributed Databases Should Work More Like CDNs

#34

Post by 0xCMP »

eip wrote: post #10
timkpaine wrote: post #5

Imagine a globally replicated and version controlled object store. You could use this for data, assets, source code, anything you like. Would be incredibly useful for both the development side of things, as well as production.

>Imagine a globally replicated and version controlled object store. S3?

You can replicate it to other regions, but it's not assumable that it's replicated by default. You can enable replication to other region's buckets though.

Re: Distributed Databases Should Work More Like CDNs

#35

Post by Chickenosaurus »

astine wrote: post #23

Sooo, being able to distribute data globally is good for performance? Who knew? The thing about distributed systems, including distributed databases is that they need to navigate around the the CAP theorem(Consistency, Availability, Partition Tolerance, pick two, essentially,) and every solution is ultimately a trade off. This article would be a lot more interesting if it showed how CockroachDB made a better trade of…

I think the PACELC theorem [1] should be preferred to the CAP theorem as it is more precise. It states in case of a partition (P), there is a trade-off between availability (A) and consistency (C). Else (E), there is a trade-off between latency (L) and consistency (C).

[1] https://en.m.wikipedia.org/wiki/PACELC_theorem

Re: Distributed Databases Should Work More Like CDNs

#36

Post by philip1209 »

astine wrote: post #23

Sooo, being able to distribute data globally is good for performance? Who knew? The thing about distributed systems, including distributed databases is that they need to navigate around the the CAP theorem(Consistency, Availability, Partition Tolerance, pick two, essentially,) and every solution is ultimately a trade off. This article would be a lot more interesting if it showed how CockroachDB made a better trade of…

When I think of distributed databases, I think of Bitcoin - and that's not fast :-)

Re: Distributed Databases Should Work More Like CDNs

#37

Post by elvinyung »

marknadal wrote: post #33
astine wrote: post #23

Sooo, being able to distribute data globally is good for performance? Who knew? The thing about distributed systems, including distributed databases is that they need to navigate around the the CAP theorem(Consistency, Availability, Partition Tolerance, pick two, essentially,) and every solution is ultimately a trade off. This article would be a lot more interesting if it showed how CockroachDB made a better trade of…

Also a distributed database engineer, and while I disagree with CockroachDB's CAP Theorem tradeoff decisions, they are definitely well reasoned and principled. RethinkDB was Master-Slave (strongly consistent) with an amazing developer community and actually survived Aphyr's tests better than most systems. CockroachDB is also in the Master-Slave (strongly consistent) camp, but more enterprise focused, and therefore wi…

Master-master doesn't automatically imply AP. e.g. EPaxos [1] is basically a master-master CP system.

[1] https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf

Re: Distributed Databases Should Work More Like CDNs

#38

Post by elvinyung »

merb wrote: post #31
imtringued wrote: post #30

Earlier quoted context omitted.

My application is just plain old CRUD. What if two users want to change e.g. the telephone number of an existing record during a network partition. There just is no obvious way to merge a telephone number. One of them is correct, the other is incorrect. Can CRDTs solve my simple problem?

I think the issue is solved (while still complex) with an event sourcing system. The chances are really high that the users did not push / updated the number at the exact same time. (so they are at least 1ns apart, even when not it's not that bad). So you can actually restore to a sane state by reapplying the log from scratch. i.e. this is solved with CQRS and Event Sourcing and it probably works in like all database…

Does this imply that there's a single place that log entries get ingested at? Doesn't that make it a single point of failure?

Re: Distributed Databases Should Work More Like CDNs

#39

Post by merb »

elvinyung wrote: post #38
merb wrote: post #31

Earlier quoted context omitted.

I think the issue is solved (while still complex) with an event sourcing system. The chances are really high that the users did not push / updated the number at the exact same time. (so they are at least 1ns apart, even when not it's not that bad). So you can actually restore to a sane state by reapplying the log from scratch. i.e. this is solved with CQRS and Event Sourcing and it probably works in like all database…

Does this imply that there's a single place that log entries get ingested at? Doesn't that make it a single point of failure?

well you can either use a single database for log entries, or cassandra or a mysql cluster or a pg cluster. that doesn't matter.. basially instead of having a table where you update/delete entries you basically append only to a table. so insert only. you can still have another table that will be aggregated from your log table.

where you store (i.e. which database system, cluster whatever) your stuff doesn't matter.

Post reply on HN