Could the name actually slow the project's momentum? 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 http://bbc.com/future/story/20140918-the-reality-about-roach... 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 bel…
I'm wondering if all the people who can't get over the name CockroachDB are also people who insist that professionals should dress the part. Can't take someone seriously if they don't have their shirt tucked in?
Could the name actually slow the project's momentum? 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 http://bbc.com/future/story/20140918-the-reality-about-roach... 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 bel…
to me it's not a deeply-seeded reason, it's just when I hear cutesy-sounding names I just don't take them seriously. They sound like the latest, hipster thing that's going to be in-bloom for a (figurative) week or two until the next cutesy thing steals everyone's attention. Even the language Pony has a mildly off-putting name (to me) despite hearing people rave about it. Couch DB ? What the hell does that mean ? I ad…
Ah yes, let's not forget the solid branding behind some of Adobe's work:
I agree completely. I love reading about databases, but apparently have been skipping reading about CockroachDB for that same reason subconsciously. I took a deep dive the other day and was amazed that I've seen the name dozens of times and have never bothered to ask what was special about it. It really is a fascinating database.
No, you have not been skipping it subconsciously or seeing it more often, than others, you just feel like you did. People actually have an availability bias [1] that clouds their judgement about unusual things. [1] https://en.wikipedia.org/wiki/Availability_heuristic
Interesting, perhaps so. I did have a moment of realization that I had a negative bias against the name though.
Could the name actually slow the project's momentum? 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 http://bbc.com/future/story/20140918-the-reality-about-roach... 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 bel…
I'm a little confused about how read speed is 2x slower than write speed. With respect to 'correctness', you're drifting into pyrrhic victory or 'not even wrong' territory at that point. When there are basic expectations of behavior that aren't being met, many of us would reject the idea that this code is 'correct'.
As I mentioned in the article's introductory paragraphs, where Spanner forces a minimum latency on writes to ensure consistency, CockroachDB pushes that latency to reads which contend with a write.
Latency is one thing throughput is a different animal 2 reads/second per m3.large node that really forces one to think there are some severe architectural issues.
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'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…
> I'm curious, do any of the cloud providers offer instances with high-precision clocks? Essentially that's what Google's doing by selling Spanner, but you don't get access to the clocks directly. I'd guess that as they get more experience selling Spanner, and they bring the price of the hardware down, they'll rent those directly too.
They're planning to offer direct access to the TrueTime API soon according to the post by Eric Brewer.
Could the name actually slow the project's momentum? 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 http://bbc.com/future/story/20140918-the-reality-about-roach... 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 bel…
Agree 100%, ditto for suggested alternate name. I'd been doing the same for Rust. It's not a rational reason, sure, but I have to sell adoption to a broader userbase that cares about more that the technical merits.
I don't want to have to make the case for why someone's system needs rust and cockroaches.
Could the name actually slow the project's momentum? 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 http://bbc.com/future/story/20140918-the-reality-about-roach... 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 bel…
"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)." Wow, that's...not fast.
Even if they manage to multiply this by 100 on the final release, it's still way weaker than a regular sql db. I hope they have another selling point than performance.
The test is testing the worst-case scenario of everything needing locking. CockroachDB uses an optimistic "locking" approach which makes this bad. But if you're use-case is strictly linearizable high-throughput reads good luck finding anything that is not a single-machine database.
> Should the clock offset between two nodes grow too large, transactions will no longer be consistent and all bets are off. 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.
You're correct--large clock anomalies (or VM pauses, message delays, etc) can cause serializability anomalies. I don't exactly know what will happen, because our tests explicitly focused on staying within clock skew bounds. To speculate: if clocks do go out of bounds, I don't... think... you can violate single-key serializability, because that goes through a single Raft cluster, but you can definitely see multi-key c…
(Cockroach Labs CTO) The major issue with clock offsets is stale reads due to the time-based read lease. Pretty much everything else is independent of the clocks. Stale reads are still enough to get you in trouble (some of the jepsen tests will show serializability violations if you disable the clock-offset suicide and mess with the clocks enough), but it's tricky to actually get bad data written into the database, as opposed to returning a stale-but-consistent view of the data.