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 <i>how</i> CockroachDB made a better trade off than the other solutions listed.
I love CockroachDB, but feel like this article was a bit misleading in it's claims. I started out writing a comment response, but it got so long that it turned into a blog post: <a href="https://danielcompton.net/2018/02/08/add-context-cockroachdb-databases-acting-like-cdns" rel="nofollow">https://danielcompton.net/2018/02/08/add-context-cockroachdb...</a>.
this is true, and why fastly is kindof like a globally distributed nearly-cache-coherent key value store that people <i>use</i> as a CDN.<p>there's a great talk on how its done with a custom gossip protocol implementation: <a href="https://www.youtube.com/watch?v=HfO_6bKsy_g" rel="nofollow">https://www.youtube.com/watch?v=HfO_6bKsy_g</a>
CDN: no trade offs. Faster everywhere. More reliable overall<p>Cockroach DB: trade some performance for geographic redundancy. The trade off may work in your favor - e.g. read heavy workloads (or not).<p>I plugged in CDB I place of Postgres for some testing this week, was surprised it worked so well.
> 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.<p>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 exactly like CDNs, except more reliable.<p>I'm wondering, since CockroachDB keeps lying about and attacking eventual consistency in these PR posts, the whole "consistency is worth sacrificing latency" mantra might not work in practice after all. People just don't buy it, they want low latency, they want something like CDNs, something fast and reliable, something that just works. Something that CockroachDB can never deliver.<p>[1] <a href="https://en.wikipedia.org/wiki/Eventual_consistency#Strong_eventual_consistency" rel="nofollow">https://en.wikipedia.org/wiki/Eventual_consistency#Strong_ev...</a>
Am I wrong, or does seems the article not really tell how CDB deals with the latency issue, especially with regards to writes?<p>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 used CockroachDB for a university project, and while I think it looks very promising, I found the tooling and documentation to be a bit lacking. I wouldn't use it in production yet. However, when CockroachDB matures a bit I can really see it take off.
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.
what a dumb article about nothing. hey, a database replicates stuff but so does a CDN! what a brilliant insight. let's make an article with this title but fill it with marketing text.
If this interests you, you'll probably enjoy reading Google's paper on Spanner. Cockroachdb was heavily influenced by it.<p><a href="https://research.google.com/archive/spanner.html" rel="nofollow">https://research.google.com/archive/spanner.html</a>
As long as we're advertising, consider:
<a href="https://cloud.google.com/spanner/" rel="nofollow">https://cloud.google.com/spanner/</a>
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?
so immutable, like datomic? <a href="https://www.infoq.com/articles/Datomic-Information-Model" rel="nofollow">https://www.infoq.com/articles/Datomic-Information-Model</a><p>Or more like federated SPARQL on RDF? <a href="https://www.w3.org/TR/sparql11-federated-query/" rel="nofollow">https://www.w3.org/TR/sparql11-federated-query/</a>
CDN post with no performance talk (beside keyword).<p>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.