Why the 'Ex-Googlers' in the title. Is it like a seal of approval or something?
It is a pretty strange title. Some might interpret it as they started this project after being fired from Google.
That's kind of how I read it.
Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
31–40 of 70 posts
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#32Many things that I don't agree with: https://github.com/cockroachdb/cockroach/ MySQL: Weak consistency Cassandra: No availability or weak consistency with datacenter failure
[deleted]
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#33Here in the Southeast, we call them "Palmetto Bugs". Maybe a rename to PalmettoDB? :)
Palmetto bugs are generally the larger, flying "American Cockroach." "German Cockroaches" are smaller, don't fly but are generally the ones that cause infestations. I grew up in the Northeast and German Cockroaches are all I ever saw up there. I've been down in Atlanta for years now and I only see Palmetto bugs here.
Unless this database can fly, I'd say they've chosen the right name. ;)
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#34Are there distributed data stores like this that are also resilient to intentional sabotage? I've been looking recently at long-term digital preservation systems -- tools designed to archive large amounts of data for decades. This is the Library of Alexandria problem -- how do we preserve all this data we're generating against once-in-a-century disasters? So this 2005 paper lists thirteen different threats to long-te…
Maybe Camlistore? https://github.com/bradfitz/camlistore
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#35So I cannot tell if this is aiming to be CA or AP. Having beaten my head against the CAP wall for a while, how does it deal with partitions?
From what I understand, in real world distributed systems, you will always have P (despite what the name suggests, it's pretty much failures not just network partitions). The question is whether they'll choose A over C when a partial P happens (say you have 3 nodes and 2 go down, you have quorum loss, will you still keep the replica available and replicate lazily or will you make it unavailable until a 2nd replica comes up?). I'm guessing it'll be tunable/configurable in this case.
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#36Happy to see it's written in Golang.
As a Go developer I was happy as well.
On the other hand this question immediately popped into my mind: What kind of overhead does the GC incur, and how does it affect processes like a database where low latency is desired?
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#37Awful name!!! Why Cockroach..??
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#38awful awful name... folks didnt get anything than cockroach..
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#39So I cannot tell if this is aiming to be CA or AP. Having beaten my head against the CAP wall for a while, how does it deal with partitions?
The design doc https://docs.google.com/document/d/11k2EmhLGSbViBvi6_zFEiKzu... says, "TBD: how to avoid partitions? Need to work out a simulation of the protocol to tune the behavior and see empirically how well it works" .. so they've gone for CA and forgotten about P.
Usually when building a distributed database, "TBD: how to avoid partitions?" is not what you want to see except on the initial whiteboard discussion before a single line of code is written. But what do I know, I am not an Ex-Googler.
Re: Ex-Googlers CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
#40So I cannot tell if this is aiming to be CA or AP. Having beaten my head against the CAP wall for a while, how does it deal with partitions?
The design doc https://docs.google.com/document/d/11k2EmhLGSbViBvi6_zFEiKzu... says, "TBD: how to avoid partitions? Need to work out a simulation of the protocol to tune the behavior and see empirically how well it works" .. so they've gone for CA and forgotten about P.
You're taking a sentence out of context and giving it the most uncharitable possible interpretation. They certainly haven't "forgotten" about network partitions because if you actually read the design document, instead of ctrl-F'ing for the word "partition", they talk about the mechanisms they use to ensure sequential consistency. The software is not yet at the point of being testable AFAIK, but clearly the intent is to build a CP system.
The section you're quoting is discussing a separate gossip protocol that is used to lazily propagate node state information. It does not affect the consistency of actual data replicas.