91–100 of 213 posts
Earlier quoted context omitted.
I wonder how the clock skew bounds affect performance. Would a more accurate clock increase throughput?
The clock skew limit controls the maximum latency on reads--so yeah, if you're doing reads that contend with writes, improving clock resolution improves latency. Not entiiirely sure about the throughput impact though.
Earlier quoted context omitted.
What I found out the hard way is that there's a qualitative difference between 'can' and 'must' here that causes a lot of problems with the development cycle. When the project can no longer fit onto a developer's box it changes a bunch of dynamics and often not for the better. Lots of regressions slip in, because developers start to believe that the glitches they see are caused by other people touching things they sh…
Plus I found that people using MongoDB tend to not formalize their data schema because the tool doesn't enforce it. But they do have a data schema. Only: - it's implicit, and you have to inspect the db and the code to understand it. - there is no single source of truth, so any changes better be backed up by unit tests. And training is awkward. If some fields/values are rarely use, you can easily end up not knowing ab…
But I didn't want to turn the Cockroach scalability discussion into another roast of Mongo so I very purposefully only talked about the horizontal scaling vis a vis 'immediately have to scale' versus 'very capable of scaling' horizontally.
If you gave me a DB that always had to be clustered but I could run it as two or three processes on a single machine without exhausting memory, I would be fine with that as long as the tooling was pretty good. As a dev I need to simulate production environments, not model them exactly.
But if the whole thing only performs when it's effectively an in-memory DHT, there are other tools that already do that for me and don't bullshit me about their purpose.
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, the name is pretty off putting. Maybe they were trying to be funny? I don't know, but I would recommend changing it.
Earlier quoted context omitted.
But why scale something when you can just run one postgres instance and provide 10000x the performance?
My though exactly. It's already the case with faster DB. E.G: most projects my customers make me work on will never need scaling on multiple instances. They run really fast on a single postgres instance. One had some perf issues. First he just moved the DB to avoid having it on the same machine as the web server. Saved him a year. Then as the user base grew, he just bought a bigger server for the db. Right now it wor…
So by all means, scale up your single DB server. But if you ever get the happy issue of even more growth, and needing to scale beyond a single server, then you "should" be able to migrate your data to a cockroachDB cluster, and not have to change much, if anything, in your application.
Earlier quoted context omitted.
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…
I know that was rhetorical, but Couch is connotationally neutral AFAIK, and comes from "cluster of unreliable commodity hardware".[1] At least, it's miles ahead of Cockroach or Rust or even Mongo. [1] https://en.wikipedia.org/wiki/CouchDB#History
I'm not marketing guru, but maybe cockroach could have been more palatable by calling it "RCH, some call it roach, because it was named after its persistence" ?
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 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.
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…
Completely agree. I specialize in distributed databases and I have zero interest in even learning about CockroachDB. Could be the greatest technology ever and I will never know. Is that irrational? Sure. But I'm a busy man with plenty of tech to learn about and limited time. I detest roaches and do not want to think about them at all when I am working. Might as well have named it with an ethnic slur.
Earlier quoted context omitted.
Plus I found that people using MongoDB tend to not formalize their data schema because the tool doesn't enforce it. But they do have a data schema. Only: - it's implicit, and you have to inspect the db and the code to understand it. - there is no single source of truth, so any changes better be backed up by unit tests. And training is awkward. If some fields/values are rarely use, you can easily end up not knowing ab…
That last statement is a bit off. Almost every developer knows how to use an SQL database. For 95% of things you want to do it's a very simple piece of technology. The issue is that they are annoying to use. You have to create a schema, you have to manage the evolution of that schema (great another tool), you have to build out these complicated relational models and finally you have to duplicate that schema in code.…
It's been so long since I touched SQL that I'm forgetting how. Which means that my coworkers haven't touched it either, and some of them that were junior are probably calling themselves 'senior' now, having hardly ever touched SQL. It's no wonder noSQL can waltz into that landscape.
But what's the old rule? If your code doesn't internally reflect the business model it's designed for, then you'll constantly wrestle with impedence mismatches, inefficiencies, and eventually the project will grind to a halt.
So what I'd rather see is a database that is designed to work the way modern, 'good' persistence frameworks advertise them to work. That would represent progress to me.
Earlier quoted context omitted.
They need to be at least 1000x to 10,000x faster on the read side though
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'.
FWIW, you're also describing Cassandra and it seems to do fine in the marketplace.