Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

Post reply on HN
Print view View original

341–350 of 366 posts

Re: CockroachDB 1.0

#341

Post by mjibson »

dsparkman wrote: post #339
irfansharif wrote: post #31

Earlier quoted context omitted.

You might find our post[1] on atomic clocks, rather having to do without them, partially interesting. [1]: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

Why not simply have the cluster sync a time between themselves? First node in the cluster gets the time, and as the new nodes come online they set their own internal time via the cluster? So in a world where there is not NTP or atomic clocks the system could continue to operate.

This doesn't take into account when clocks on different systems run at different speeds, or when clocks jump, especially on VMs and cloud instances, which happens all the time.

Re: CockroachDB 1.0

#343

Post by gerdesj »

newman314 wrote: post #311
nvarsj wrote: 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...

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 with the local clock fudge as a fallback

* For Windows VMs in a domain, set the AD DC with PDC emulator role to sync its clock to the host via the VM guest tools, leave the rest alone

* On your monitoring system make sure that it has an independent list of five sources and use plugins like ntp-peer for ntpds and ntp-time for Windows (Nagios/Icinga etc)

With the above recipe, ntpq -p shows offsets less than 1 ms across the board for ntpds after stabilising.

Re: CockroachDB 1.0

#344

Post by radub »

gred wrote: post #335

Very interesting. I have to admit I've seen the product name a few times, but never took the time to have a look. I do have a few questions, though, if any of the engineering team are still around watching the discussion :-) From the high availability page [1] in the docs: > Cross-continent and other high-latency scenarios will be better supported in the future. Do you have a specific timeline in mind? I've been work…

I don't have a specific timeline but it is something we will be focusing on in the following releases.

Regarding DDL statements, this blog post [1] has details. In a nutshell, online schema changes are possible; the changes become visible to transactions atomically (a concurrent transaction either sees the old schema, or the fully functional new schema).

[1] https://www.cockroachlabs.com/blog/how-online-schema-changes...

Re: CockroachDB 1.0

#345

Post by irfansharif »

sixdimensional wrote: post #320
ww520 wrote: post #278

Earlier quoted context omitted.

15 years ago I was working on a similar distributed DB product. At the time, the idea was to send the query execution plan to each node to execute any filtering criteria to trim down the candidate row set. Then compute a Bloom Filter on the joining keys on the node with the largest candidate set (using some heuristic statistics), ship the Bloom Filter to other nodes with smaller data set to greatly reduce the non-mat…

I've heard of pushdown techniques including function, predicate and aggregate pushdown in distributed relational engines before. Another interesting idea I read about (I can't find it anywhere online) was called "join zippering". Basically you first request the cluster to solve a join by querying and streaming the key columns from a join predicate back into the cluster itself to identify which nodes have matches and…

> This is hard stuff but so cool too

I agree! we have some semblances of pushdown filtering across aggregations and some other interesting techniques as documented in the RFC[1] that first proposed the distributed execution model.

[1]: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

Re: CockroachDB 1.0

#346

Post by camus2 »

dkersten wrote: post #98
niceperson wrote: post #23

>Cockroach What were they thinking?

Cockroaches are highly resilient creatures. The name, I assume, is alluding to the goal of this database being a highly resilient system. Whats the problem?

Cockroaches are disgusting, the name hurts to the product. I'm confident they will acknowledge that fact sooner or later and change the name.

Re: CockroachDB 1.0

#347

Post by a-robinson »

nhumrich wrote: post #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

Yes, it works. Your latency will just be correspondingly higher (due to the speed of light). We are constantly testing a cross-region (i.e. US-East and US-West) cluster and have periodically run tests on cross-continent clusters (US to Asia-Pacific).

In these cases you can help the cluster out by following some of the advice on the "Recommended Production Settings" page (https://www.cockroachlabs.com/docs/recommended-production-se...) around specifying which `--locality` each node is in.

Re: CockroachDB 1.0

#348

Post by efsavage »

sillysaurus3 wrote: post #226
efsavage wrote: post #142

Earlier quoted context omitted.

It's a bad name because this topic will come up every time it's discussed, forever. It's a distraction from other relevant issues like new features or how it performs.

Strangely, it seems to be helping them. Usually whenever there's an excellent product/article featured on HN, there's not much to say, so there are very few comments. CockroachDB seems like an excellent product, yet the firestorm about their name is fueling discussion, which amusingly might be leading to more upvotes from people who dislike that they're being discriminated against based on their name. It's counterint…

I hope it is excellent and advances the state of the art, but it won't reach it's full potential until it has a name people can use when talking to users, customers, and board members.

"Well first we collect all of the data in the Epidemic schema, run it through the Apocalypse pipeline to transform it into something that our Extinction servers can handle, and finally store it in CockroachDB."

Re: CockroachDB 1.0

#349

Post by fortytw2 »

arjunnarayan wrote: post #150
rjammala wrote: post #133

Earlier quoted context omitted.

Thanks for the video. Can you please upload the slides somewhere?

We were told that the slides would be uploaded by Applicative (hence we didn't post a copy), but we can't seem to find it on the internet either, so here's a copy from our Google drive: https://drive.google.com/file/d/0ByQnrkOiRT_LMmZ6SXFmbk5wTDA...

Did y'all ever figure out a way to get goroutine leak detection working with parallel tests? (didn't expect to see that linked here)

Re: CockroachDB 1.0

#350

Post by pishpash »

therealmarv wrote: post #82

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

Distance aside, you don't even have a semblance of simultaneity with multiple reference frames, so not even theoretically possible.
Post reply on HN