331–340 of 366 posts
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?
RethinkDB and FoundationDB are great, but require a paradigm shift I think.
Earlier quoted context omitted.
We have a post on why we chose Go, from a year and a half ago: https://www.cockroachlabs.com/blog/why-go-was-the-right-choi... More technically, here's a somewhat random set of thoughts on the subject: The Go GC is performant and predictable, unlike the JVM GC. We do have some very memory-allocation-conscious code patterns to minimize the performance impact of working in a garbage-collected language runtime, but in t…
Why do you think the Go GC is better than any the JVM options? From what I've seen, while the Go GC is well tuned for low latency, by picking the right JVM GC parameters you can on balance get a better throughput latency tradeoff. I'm just wondering if you have any reliable benchmarks or evidence to support what your saying? I don't use either language for work, so I think you might have better information than I.
Much of Java's GC focus has been on correctly partitioning the heap so that long-lived objects can be less aggressively collected than short-lived ones. (An example of a challenging long-lived object is the entire set of classes used by a program, all of which need to available to the runtime for reflection. For many bigger apps, the class hierarchy alone takes up many megabytes of RAM!)
Go can make use of the stack to a much larger degree (structs and arrays can be passed by value), and so it can get by with a much less advanced GC. As a result, Go team's main focus has been on reducing pause times more than anything else.
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?
I'm excited to track this project!
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 working on an application that needs to be highly-available, and which uses Oracle right now. It seems like you can add all sorts of tools to the mix (RAC, DataGuard, etc), but there are always significant caveats around the capabilities of the resultant system. We're talking 1 to 2 TB of data total, tables of up to 100 million rows with 1 million rows added per day, distributed across three data centers (US, EU, Asia).
And regarding high availability in the context of application deployments, is there any documentation on the locking characteristics of DDL statements? I'm interested in the ability to modify the schema during an application deployment without having to bring down the system or implicitly locking users out. Apologies if I missed it somewhere on the website!
[1] https://www.cockroachlabs.com/docs/high-availability.html
Earlier quoted context omitted.
If you make technology stack decisions based on your feelings rather than what the product actually does, then you shouldn't be employed as a decision-maker.
Feelings become reality. People care about what things are called. You just don't care because it doesn't bother you. But if it was a topic you were sensitive about or something you feel is inappropriate, you would feel otherwise. Everyone has their limits of what is going too far. It's almost as if we live in a society with people from different backgrounds. What this really hits on is subjective relativism, and tha…
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…
haven't come across this idea before, interesting - will definitely have to give it some more thought. our 'distributed joins', so to speak, run through our distributed query execution model (distsql) setting up incremental 'stages' of computation with the results pipelined and plumbed through individual computes. viewing it through this model our implementation more closely resembles the Grace Hash Join[1] algorithm…
Curious why Mac is better supported than Windows. This is obviously something you'd run on a server. Do orgs run Mac servers? Is it just to support dev work for people too lazy to launch a VM? Sorry, Windows/Linux ops person here with very little awareness of Mac ecosystem.
This just comes down to the fact that Windows is a special snowflake that does everything differently. Sometimes for good reasons, but usually not for good reasons.
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…
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...
Pardon the nature of my question, but I'm really interested in what your experience has been so far building a database with Go? Has its runtime (the GC for example) posed any issues for you so far? Looking at other RDBMS's, languages with manual memory management like C or C++ seems to be the go-to choice, so what were the reasons you chose Go? I'm quite frankly amazed that Go's runtime is able to support a database…
We have a post on why we chose Go, from a year and a half ago: https://www.cockroachlabs.com/blog/why-go-was-the-right-choi... More technically, here's a somewhat random set of thoughts on the subject: The Go GC is performant and predictable, unlike the JVM GC. We do have some very memory-allocation-conscious code patterns to minimize the performance impact of working in a garbage-collected language runtime, but in t…