Live data from Hacker News

Distributed Databases Should Work More Like CDNs

cockroachlabs.com

41–50 of 86 posts

Re: Distributed Databases Should Work More Like CDNs

#41
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…

> they want something like CDNs, something fast and reliable, something that just works.

There are other DB systems with such properties "they" can use, e.g. Cassandra. But CockroachDB also gives ACID transactions, which may be important for others.

Re: Distributed Databases Should Work More Like CDNs

#42
Am I wrong, or does seems the article not really tell how CDB deals with the latency issue, especially with regards to writes?

If the write has to be consistent and available across multiple regions, it will need to synchronously replicate that write to all the regions, thus incurring the same performance penalty as RDS or any other consistent database.

Re: Distributed Databases Should Work More Like CDNs

#43
post #42

Am I wrong, or does seems the article not really tell how CDB deals with the latency issue, especially with regards to writes? If the write has to be consistent and available across multiple regions, it will need to synchronously replicate that write to all the regions, thus incurring the same performance penalty as RDS or any other consistent database.

I doubt this particular article was intended to address how CRDB handles writes cross-region, synchronous replication, etc. You'll find articles touching on varying aspects of what you're looking for if you dig through some of the earlier posts on their blog[1] or their FAQ[2].

[1]: https://www.cockroachlabs.com/blog

[2]: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

Re: Distributed Databases Should Work More Like CDNs

#45
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?

sort of

all CRDT will give you a deterministic outcome and provide enough information to allow a user to decide if this outcome is acceptable

Re: Distributed Databases Should Work More Like CDNs

#46
post #42

Am I wrong, or does seems the article not really tell how CDB deals with the latency issue, especially with regards to writes? If the write has to be consistent and available across multiple regions, it will need to synchronously replicate that write to all the regions, thus incurring the same performance penalty as RDS or any other consistent database.

I doubt this particular article was intended to address how CRDB handles writes cross-region, synchronous replication, etc. You'll find articles touching on varying aspects of what you're looking for if you dig through some of the earlier posts on their blog[1] or their FAQ[2]. [1]: https://www.cockroachlabs.com/blog [2]: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

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.

Re: Distributed Databases Should Work More Like CDNs

#47
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

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.

Re: Distributed Databases Should Work More Like CDNs

#48
post #46

Earlier quoted context omitted.

I doubt this particular article was intended to address how CRDB handles writes cross-region, synchronous replication, etc. You'll find articles touching on varying aspects of what you're looking for if you dig through some of the earlier posts on their blog[1] or their FAQ[2]. [1]: https://www.cockroachlabs.com/blog [2]: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

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 continue to split into new ranges, aiming to keep a relatively small and consistent range size. Each range is replicated 3-way (by default) as well, and is backed by a single Raft instance.

When your cluster spans multiple nodes (physical machines, virtual machines, or containers), newly split ranges (or more specifically, replicas of these ranges) are automatically rebalanced to nodes with more capacity. Writes addressed to a range are handled by the Raft leader for that range (which can hop around its various replicas as needed). Writes to different ranges (non-overlapping key spaces by definition) are processed independently, and very well may be processed across multiple machines.

Source: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

Re: Distributed Databases Should Work More Like CDNs

#49
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?

No, you can just have partitioned replicated topics like kafka has, just make sure that all the events for one user get put into the same partition, so that they get totally ordered.

Re: Distributed Databases Should Work More Like CDNs

#50
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…

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
Post reply on HN