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

51–60 of 86 posts

Re: Distributed Databases Should Work More Like CDNs

#51

Post by [deleted] »

Chickenosaurus wrote: post #35
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

[deleted]

Re: Distributed Databases Should Work More Like CDNs

#52

Post by irfansharif »

pdeva1 wrote: post #50
irfansharif wrote: post #48

Earlier quoted context omitted.

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…

what you described is the mechanism to deal with scalability, ie throughput. What is being disputed is the claim to latency. Every bit of data needs to be replicated across multiple regions consistently and that will incur the same latency as rds or any other consistent database

Given the flexibility of where the range raft leader could be, CRDB makes an active effort to colocate it near to where the requests originate from (which is some part of what the CDN parallel was alluding to with low RTT for multi-region deployments).

WRT to the writes here, if a majority of the replicas for that range are in the proximate regions, the requests would only travel that far before responding. I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin. The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability, alternatively you could trade this off to have the majority of your replicas specific to requests from a specific region, be located to that specific region.

Re: Distributed Databases Should Work More Like CDNs

#53

Post by ithkuil »

tormeh wrote: post #47
Chickenosaurus wrote: post #35

Earlier quoted context omitted.

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

Ah, much better, I have to say. Much more informative as well. The CAP theorem is a bit ungainly since the only way to have a CA database is to only have a single node.

> the only way to have a CA database is to only have a single node.

I know that this is meant to mean: in the real world you cannot just write off partition resilience and still call your system highly available, since partitions will happen sooner or later and when they do your CA system won't be available.

But in the other hand, having a system that is always available _except_ during a network partition is a useful thing: you can design a network where partitions happen much rarely that the rate at which individual machines die.

I.e. in practice a single node, while if you nitpick is the only true CA, will available for less time in average than a multi node CA system which if you nitpick is not CA (provided that the underlying network is partition resilient; it's not a boolean, it's a probability)

(See Google spanner)

Re: Distributed Databases Should Work More Like CDNs

#54

Post by skybrian »

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…

From a bit of reading, it looks like they do it with optimistic concurrency, probably at the expense of write throughput. When there is contention (writing the same keys) there may be a lot of retries.

It seems like a good solution for data that doesn't change too quickly?

Re: Distributed Databases Should Work More Like CDNs

#55

Post by joshribakoff »

zzzcpan wrote: post #27
dstroot wrote: post #19

CDN: no trade offs. Faster everywhere. More reliable overall Cockroach DB: trade some performance for geographic redundancy. The trade off may work in your favor - e.g. read heavy workloads (or not). I plugged in CDB I place of Postgres for some testing this week, was surprised it worked so well.

Unless you build your own DNS routed CDN, it actually reduces reliability. And to make it faster everywhere you trade immediate consistency for eventual consistency.

I think what you're trying to say is the CDN becomes another point of failure, that is, unless you have DNS failover which updates the DNS of cdn.example.com to point to your origin server's IP instead of the CDN in the event the CDN goes down. You should have monitoring & fail saves in place for your CDN, and if that's in place a CDN has higher redundancy vs just a single server is what the OP was trying to say, I bet.

Re: Distributed Databases Should Work More Like CDNs

#56

Post by zjaffee »

ithkuil wrote: post #53
tormeh wrote: post #47

Earlier quoted context omitted.

Ah, much better, I have to say. Much more informative as well. The CAP theorem is a bit ungainly since the only way to have a CA database is to only have a single node.

> the only way to have a CA database is to only have a single node. I know that this is meant to mean: in the real world you cannot just write off partition resilience and still call your system highly available, since partitions will happen sooner or later and when they do your CA system won't be available. But in the other hand, having a system that is always available _except_ during a network partition is a usefu…

It's my understanding that Google Spanner is leveraging hardware (direct lines between machines), so the degree at which there is a network partition is different than compared to other systems.

Re: Distributed Databases Should Work More Like CDNs

#58

Post by pdeva1 »

irfansharif wrote: post #52
pdeva1 wrote: post #50

Earlier quoted context omitted.

what you described is the mechanism to deal with scalability, ie throughput. What is being disputed is the claim to latency. Every bit of data needs to be replicated across multiple regions consistently and that will incur the same latency as rds or any other consistent database

Given the flexibility of where the range raft leader could be, CRDB makes an active effort to colocate it near to where the requests originate from (which is some part of what the CDN parallel was alluding to with low RTT for multi-region deployments). WRT to the writes here, if a majority of the replicas for that range are in the proximate regions, the requests would only travel that far before responding. I believe…

> The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability

So we are in agreement that CDB has same write latency as rds for multi region deployments. The article seems to imply that is not the case, but as you yourself agree it actually is.

Re: Distributed Databases Should Work More Like CDNs

#60

Post by irfansharif »

pdeva1 wrote: post #58
irfansharif wrote: post #52

Earlier quoted context omitted.

Given the flexibility of where the range raft leader could be, CRDB makes an active effort to colocate it near to where the requests originate from (which is some part of what the CDN parallel was alluding to with low RTT for multi-region deployments). WRT to the writes here, if a majority of the replicas for that range are in the proximate regions, the requests would only travel that far before responding. I believe…

> The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability So we are in agreement that CDB has same write latency as rds for multi region deployments. The article seems to imply that is not the case, but as you yourself agree it actually is.

No? Apologies if I'm not able to communicate as clearly. The RTT would be to the furthest replica within `n` replicas ordered by proximity to the query origin, where `n` is the number it would take to have a majority within the specified replication factor (so 2 for a replication factor of 3, 3 for 5, etc.). It would be different from the RTT observed with Amazon RDS as long as the furthest replica, as described above, is in a different zone/region/DC as compared to RDS's primary instance (assuming a similar topology). So with a replication factor of 3, if your DCs are in the UK, Australia and the US, if the RDS primary was in the US, all write requests from Australia would have to travel over to the US. But with a replica in each zone, write requests from Australia would hit the DC in Australia, and the DC in UK, avoiding the larger RTT to the US.

To reiterate: I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin.

Post reply on HN