Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

351–360 of 366 posts

Re: CockroachDB 1.0

#351

Does this work theoretically interplanetary (just asking because for science) ?

No. Once your latency goes beyond single digit seconds, performance will probably collapse. Too many subsystems would time out. in theory it could be made to work (with terrible performance, and extremely long commit-waits due to having to wait until the remote planets get back to you), but I wouldn't architect a planetary spanning distributed database this way. We probably would have to go back to the drawing board…

You'd need to give up on consistency, because there is no such thing when the time of communication is long compared to interval of events. In the long run, ACID is dead.

Re: CockroachDB 1.0

#352

Earlier quoted context omitted.

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?

I suppose for vMotion purposes. A VM is not tied to a physical machine.

Re: CockroachDB 1.0

#353

Earlier quoted context omitted.

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...

I run a lot of VMware: * Set the esxis to have five external sources * Search fwenable-ntpd ( https://www.v-front.de/2012/01/howto-use-esxi-5-as-ntp-serve... ) and download the .vib (do a security audit on it - its a zip file I think - to ensure it is what you think it is). Install the .vib which simple adds a ntp daemon option to the firewall ports. This works on v6.5 * Run ntpd on Linux VMs, pointed at the hosts wi…

Hijacking my own thread:

I don't suppose anyone knows how to make a Windows NTP server permit queries? Googling does not seem to reveal anything insightful. I know how to do this for ntpd but am stuck with dealing with a Windows NTP server right now.

Re: CockroachDB 1.0

#354
Say you scaled up to 100 nodes for the holiday season, is there any way to tell how many/much storage/nodes you have to keep running in order to keep 3 backups and maintain your new post holiday load?

Re: CockroachDB 1.0

#355
Since CockroachDB is Eventually Consistent Reads then how would that affect my SaaS multiuser application? How long on average would I have to wait for them to become Consistent?

Re: CockroachDB 1.0

#356
post #229

I've been following CockroachDB for quite a while. Great job on 1.0. I've had a question for quite some time though (and I think there is an RFC for it on GitHub): do we still need to have a "seed node" that is run without the --join parameter, or can we run all the nodes with the same command line, with the cluster waiting for quorum to reconcile on its own?

Currently, you need to run one node without --join for the initial bootstrapping (as soon as this bootstrapping is complete, you can and should restart it with --join to get everything into a homogenous configuration). I was hoping to make some changes here so you could start every node with --join from the beginning, but it was trickier than anticipated so it didn't make the cut for 1.0. Watch for improvements here…

Thank you for your answer.

That's okay, for now, I run a simple StatefulSet where each pod checks whether the Service is reachable on port 26257 to determine if it should join or init the cluster.

It's not as nice as if it was handled by Cockroach itself, but it does the job.

Re: CockroachDB 1.0

#357

Since CockroachDB is Eventually Consistent Reads then how would that affect my SaaS multiuser application? How long on average would I have to wait for them to become Consistent?

CockroachDB reads are strongly consistent, not eventually consistent. You don't have to wait at all.

Re: CockroachDB 1.0

#358
post #293
post #253

Earlier quoted context omitted.

On second thought I’m not sure. Everyone will call it RoachDB for short anyway, but the full name has more impact. It shocks, which is a good thing. I was so focused on aesthetics that I didn’t even consider strategy. They can always spin off “RoachDB” as an enterprise option, if they have any problems with selling it due to name.

Roach is the remnants of a joint for many of a certain age. https://en.m.wikipedia.org/wiki/Roach_(smoking)

Okay, CockDB then :)

Re: CockroachDB 1.0

#359
post #282

On a three node cluster will it survive two nodes going down?

short answer: nope. cockroachdb replicates data for availability and in order to guarantee consistency across the replicas, it uses Raft[1] internally. Raft necessitates a majority of the replicas remain available in order to operate. it ensures that a new 'leader' for each group of replicas is elected if the former leader fails, so that transactions can continue and affected replicas can rejoin their group once they…

What are the recommended configurations then? If I want to survive multiple node failures could I have 9 replicas?

Re: CockroachDB 1.0

#360
post #267
post #25

Earlier quoted context omitted.

> CockroachDB is a distributed, scale-out SQL database which relies on hybrid logical clocks I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description: http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock... Apparently Google used GPS/atomic clocks to keep time synced: >> To alleviate the problems of large ε, Google's TrueTime (TT) emp…

I don't really get why you would build a distributed database with dependency on wall time (unless you're Google and can stick atomic clock HW on every node). Why not use vector clocks? Am I missing something?

It may be a nitpick, but Google don't stick atomic clocks or even just GPS clocks into every node. Just into every data center. The difference means that it's actually perfectly feasible to do that for very many other companies running DCs or just in colos. The big news was how they used the fact (that times are synchronised with an upper limit to how far the clocks in two nodes will diverge) as a very significant optimization in Spanner, one of their distributed databases.

Building a distributed database that can optionally benefit from the same optimization actually makes a great deal of sense. Your average hobbyist won't care, but spending some extra few kilo bucks on hardware in a dc and get big throughput improvements out of your database system is a steal.

Post reply on HN