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

81–86 of 86 posts

Re: Distributed Databases Should Work More Like CDNs

#81

Post by al2o3cr »

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've only tinkered with CRDTs, but one common theme in those applications is changing the data structure to accommodate the CRDT.

In your example, that might mean changing the single "phone number" field to many "phone numbers", so that merging the two writes results in a customer record with two phone numbers. This preserves the data, but pushes conflict resolution (which number should be used?) out into the consumers.

Re: Distributed Databases Should Work More Like CDNs

#82

Post by redwood »

irfansharif wrote: post #48
pdeva1 wrote: post #46

Earlier quoted context omitted.

well the comparison section to RDS specifically claims that RDS is inferiors because "this forces all writes to travel to the primary copy of your data". So it doesn't explain how CDB is superior to RDS, since writes will incur the same penalty in CDB too.

At the key-value level, CockroachDB starts off with a single, empty range (a set of sorted, contiguous data from your cluster). As you put data in, this single range eventually reaches a threshold size (64MB by default). When that happens, the data splits into two ranges, each again covering a contiguous segment of the entire key-value space. This process continues indefinitely; as new data flows in, existing ranges…

How are ranges with implicit leader-region association associated with appropriate writers near to respective region? Seems like you must range by location for this to work

Re: Distributed Databases Should Work More Like CDNs

#83

Post by Chickenosaurus »

ithkuil wrote: post #77
Chickenosaurus wrote: post #66

Earlier quoted context omitted.

According to a paper by Eric Brewer, the author of the original CAP theorem, Google Spanner technically is not a CA system [1]. It is advertised as such because partitons are supposed to be exceedingly rare as the infrastructure is outstanding and a lot of operating experience is present [1]. I believe at the end of the day the CAP theorem is too fuzzy for such discussions. [1] https://research.google.com/pubs/pub458…

The paper says: "Does this mean that Spanner is a CA system as defined by CAP? The short answer is “no” technically, but “yes” in effect and its users can and do assume CA. The purist answer is “no” because partitions can happen and in fact have happened at Google, and during (some) partitions, Spanner chooses C and forfeits A. It is technically a CP system." which I believe is another way to word what I say in my po…

I agree. I did not mean to refute your point, but to provide more context.

Re: Distributed Databases Should Work More Like CDNs

#84

Post by russell_h »

susegado wrote: post #80
russell_h wrote: post #28

I'm curious, what sort of read latency is achievable with CockroachDB? Does it support some notion of tunable read consistency in order to achieve lower read latency at the expense of consistency?

Reads from CockroachDB go through a lease holder for the piece of data being read without needing confirmation from any replicas about consistency, so there is no overhead from replication. But read latency can be affected by writes on the data (conflicts), because it is fundamentally a consistent system (serializable). This is not tunable.

Thanks, that makes sense (and provides good context for the article). So for a cluster spanning multiple regions, one region can support low-latency reads for a given range, but reads in any other region will have to go cross-region to the leaseholder. Being able to move the leaseholder around to optimize read latency makes a lot of sense.

It would also be useful to me, in some cases, to be able to perform a read-only query in an "inconsistent" mode to avoid that cross-region latency, at the expense of potentially receiving stale data.

Re: Distributed Databases Should Work More Like CDNs

#85

Post by ddorian43 »

vog wrote: post #11
ddorian43 wrote: post #3

CDN post with no performance talk (beside keyword). Never mention lower performance (even on single-node). Add to that aws-vps with pseudo-cores and spectre-upgrade and good luck with your tps-reports.

Would you mind to elaborate? Your criticism is so condensed that I'm unable to make a lot of sense of it.

Their performance is 0.1-0.03 of postgres. And spectre makes your aws-vps ~0.7x compared to previously. Meaning you can't use it for performance-sensitive stuff (the whole point of fancy sharding and (no/new)sql).

Re: Distributed Databases Should Work More Like CDNs

#86

Post by vog »

ddorian43 wrote: post #85
vog wrote: post #11

Earlier quoted context omitted.

Would you mind to elaborate? Your criticism is so condensed that I'm unable to make a lot of sense of it.

Their performance is 0.1-0.03 of postgres. And spectre makes your aws-vps ~0.7x compared to previously. Meaning you can't use it for performance-sensitive stuff (the whole point of fancy sharding and (no/new)sql).

Thanks! That's something I can make sense of.

And I agree that this is perhaps one of the many situations where people throw away the "C" of "ACID" for no reason beyond it is modern to do so. (At least most strive for "Eventual Consistency", but that's another can of worms.)

This is even less understandable once you notice that PostgreSQL offers a lot more features than most other databases (SQL or NoSQL) and is extremely flexible and extensible - even if you use it just as a fancy JSON or XML store.

Post reply on HN