Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

321–330 of 366 posts

Re: CockroachDB 1.0

#321
Does the replication work cross-region, say US-East and US-West? or even cross continent? It sounds like the timing requires very short latency and might not work in these scenarios

Re: CockroachDB 1.0

#322
post #105
post #78

Earlier quoted context omitted.

Hey guys, I'm a fellow developer of distributed systems here. First of all I think what you are doing is great. My question is what's the point of clocks at all? The current time is a very subjective matter and I'm sure you know this, the only real time is at the point when the cluster receives the request to commit. Anything else should be considered hearsay. Specifically the time source of any client is totally mea…

My question is what's the point of clocks at all? I would highly recommend to read the link by irfansharif. It's probably the best primer ever written on the subject.

Yes, I really enjoyed it!

Re: CockroachDB 1.0

#324
post #268

Earlier quoted context omitted.

Cassandra user here in AWS. Clock drift is a big problem on VMs. NTP is not aggressive enough in these environments to keep clocks relatively in sync. We regularly had several hundred milli drifts between nodes. As cassandra is extremely clock sensitive, this is a big problem. We ended up using chrony with very aggressive settings to keep things in the sub-ms range for the most part. But it's still possible to get "h…

Interesting. I wonder if anyone has documented any best practices for timekeeping in VMs. VMware has this but it does not appear to have been updated in a while. https://kb.vmware.com/selfservice/microsites/search.do?langu...

Why does VM ware emulate the hardware clock rather than giving (possibly slightly debounced) access to the real system clock?

Re: CockroachDB 1.0

#325

Does the replication work cross-region, say US-East and US-West? or even cross continent? It sounds like the timing requires very short latency and might not work in these scenarios

Jepsen test results basically show that latency caused by replica distance won't screw your data. On the other hand, clock drift can stop your system, or even potentially corrupt your data, depending on how fast such incident can be detected/handled and what is your workload/what you are doing.

Re: CockroachDB 1.0

#327
post #168

Earlier quoted context omitted.

It's not bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Most people -- i.e. in procurement, management, finance, and others you need to appeal to -- don't want anything to do with cockroaches. The idea disgusts them at a gut level, not something you can talk away. HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame. As I say every…

Not to be an ass but... It so far appears not to be hurting them. In the slightest. This "warning" comes from the HN crowd every time something is posted about CockroachDB. I think it's time to LET IT GO. I for one, completely disagree with you but that's because I have a different understanding of the relationship between the business side and engineering. We are already looked at as eccentric and strange people, ra…

> I think it's time to LET IT GO.

It will never be let go, because each new person is a new interaction with the system that prompts the same point again.

It's like those '*porn' subreddits. You can explain and explain 'till you're blue in the face why the subs are so named, but there will always be some sniggering discussion when it is introduced to new users no matter how much you try and silence or control for it, because it's based on a natural response.

Capitalize all you like, but that's just how people work. :)

Re: CockroachDB 1.0

#328
post #168

Earlier quoted context omitted.

It's not bikeshedding when the bikeshed's color will actually have concrete effects on adoption. Most people -- i.e. in procurement, management, finance, and others you need to appeal to -- don't want anything to do with cockroaches. The idea disgusts them at a gut level, not something you can talk away. HN users are giving vital advice, for free. Those who ignore it will have only themselves to blame. As I say every…

> PubesDB Oh man, that's too much. lolol

"The DB system designed to handle crazy (sometimes even tangly!) growth. No matter how hairy your data is, Pubes can handle it!"

Re: CockroachDB 1.0

#329
post #116

Earlier quoted context omitted.

There's bad name, and then there's repulsive name. All the examples you mention fall under "bad name", and it's not even objectively bad, I actually think they're great names, so it's subjective. And NONE of them are repulsive. Then again, if you insist cockroaches are lovable creatures I have nothing more to say.

> All the examples you mention fall under "bad name", and it's not even objectively bad, I actually think they're great names, so it's subjective. And NONE of them are repulsive. My argument was not that they are good or bad, but rather that we've come to associate positive things with the companies in question, and then we post-hoc come up with explanations why they names are good etc. > Then again, if you insist co…

There's no post-hoc for some of those names. Some of them were picked because they actually were good. Even something as bland as 'Microsoft' fit right in with the culture that spawned it. And the rest were picked because they were simple, neutral, and had the potential to be iconic brands.

Cockroach is not something someone picks because it is good. That's a name you pick to make a statement that your name doesn't 'technically' matter beyond the fact that it is memorable and associative.

Re: CockroachDB 1.0

#330
I'm struggling to understand how this company has raised $50 million dollars when db companies with paying customers like RethinkDB and FoundationDB had to shut down.

They are gonna earn back $50 million by selling...a backups tool?

Post reply on HN