So I assume this means cockroachDB currently (probably) meets its promised consistency levels. How does it compare to the usual default settings of PostgreSQL for example? - I think you get SERIALIZABLE, so the behaviour should be very reasonable.<p>I understand the txn/s numbers are in a pathological scenario, but will these transactions block the whole db from moving faster or have unrelated transactions still normal throughput?<p>I'm just glad we get linearizable single keys, I had to switch to HBase because it was the only choice at the time. Cassandra did not even give me read-your-own-writes. HBase also had issues while testing on the same host, delete+write lead to deletes being reordered after the writes because they had the same timestamp.<p>I'm a bit disappointed from HN in this post, everyone only talks about the name. But 90% probably did not even read the article.
Aaanyway, heres my 2cents: <a href="https://cr.yp.to/cdb.html" rel="nofollow">https://cr.yp.to/cdb.html</a> is CDB for me :P - so better choose another acronym!
"For instance, on a cluster of five m3.large nodes, an even mixture of processes performing single-row inserts and selects over a few hundred rows pushed ~40 inserts and ~20 reads per second (steady-state)."<p>Wow, that's...not fast.
<i>Like Spanner, Cockroach’s correctness depends on the strength of its clocks... Unlike Spanner, CockroachDB users are likely deploying on commodity hardware or the cloud, without GPS and atomic clocks for reference.</i><p>I'm curious, do any of the cloud providers offer instances with high-precision clocks? Maybe this is something one of the smaller cloud providers might want to offer to differentiate themselves - instances with GSP clocks.
Wow. Probably fundraising and getting out front of googles new consumer spanner service. I just started experimenting w/ cockroachdb and it sounds/seems great. They def are campaigning hard, landing a Jepsen test and a lot of posts/articles last couple.<p>I am pulling for them over G on principle. I infer they know people at Stripe where the Rethink team & Aphyr are so hopefully they can learn from them and build an awesome product. G has lost a lot of battles on UX, Docs, attitude and just general product. They have won a lot of battles on sheer size & resources. Be nice to have this stick around.
I'd be interested in any comparisons of CockroachDB vs TIDB[1], especially when it comes to speed.<p>1 - <a href="https://github.com/pingcap/tidb" rel="nofollow">https://github.com/pingcap/tidb</a>
CDB is a really cool db for the time I've been playing with it (just a few months I think).<p>That said, I'd really appreciate if they'd launch a hosted DBaaS. By that I mean, more in line with dynamodb or documentdb instead of say MySQL on AWS for example.<p>I know it's on their timeline, but dbs generally get selected during the start of the projects and unless absolutely necessary, companies don't want to change dbs.
> Should the clock offset between two nodes grow too large, transactions will no longer be consistent and all bets are off.<p>A concern I have is that there could be datacorruption in this context, no? It sounds like on a per cluster basis, i.e. Same Raft cluster, there is a strict serializability guarantee. But without linearalizability system wide, you could end up with data corruption on multi-keyspace writes.
Could the name actually slow the project's momentum?<p>I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like <a href="http://bbc.com/future/story/20140918-the-reality-about-roaches" rel="nofollow">http://bbc.com/future/story/20140918-the-reality-about-roach...</a><p>Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info below will help put some people one less click away. How about SurvivalDB? :)<p><i>CDB is a distributed SQL database built on a transactional and strongly-consistent key-value store. Scales horizontally; survives disk, machine, rack, and datacenter failures with low latency disruption and no intervention; strongly-consistent ACID transactions; SQL API for querying data. Inspired by Google’s Spanner and F1. Completely open source.</i><p><a href="https://cockroachlabs.com/docs/frequently-asked-questions.html" rel="nofollow">https://cockroachlabs.com/docs/frequently-asked-questions.ht...</a>
I wish everyone would stop bikeshedding the damn name.<p>From my perspective I'm glad something that's trying to do this is coming into existence. a couple years ago I was given the arduous task of ensuring that we never lost data. One of the requirements was that: At any time, any server can (and will) fail.. if you acknowledge that you have data then you MUST never lose it.<p>You cannot imagine how many database solutions that ruled out. Including basically _all_ noSQL data stores.<p>We settled on postgresql, because, despite going into toast tables and having to implement sharding on top- it was not only the most sane it could be wrangled into basically doing the right thing in regards to fsyncing and ensuring data wasn't in VFS.<p>So, Kudos to these guys, who, in a world of people who don't give a shit about consistency (except eventual consistency) are actually trying to further it.
I'm disappointed with the commentary here, I for one would think the discussions around building a distributed system with the consistency guarantees claimed here would be far more interesting than the name of said system.
CockroachDB might be the worst product name I've come across. I get it; cockroaches are extremely hardy, but they're also much more strongly associated with uncleanliness and disease.<p>EDIT: Also, cockroaches are BUGS! Bugs cause problems in computer systems.
May I suggest renaming the thing already? 90% of the business world can't touch it with a name like that.<p>How about Duradero ... Spanish for durable. The name doesn't seem to be taken by any other database type software