51–60 of 75 posts
I don't really get all the whining about the name, I even kind of like it. It fits well with their narrative. Besides, they could've called it PoopDB and I still would use it if it survived a nuclear blast and had joins. I couldn't care less about the name. But apparently I'm in a minority...?
That would be Keith Richards and cockroaches (sorry had to). So two names are up for grabs for the competition.
I don't really get all the whining about the name, I even kind of like it. It fits well with their narrative. Besides, they could've called it PoopDB and I still would use it if it survived a nuclear blast and had joins. I couldn't care less about the name. But apparently I'm in a minority...?
I think it's more about the senior management and people like marketing, who aren't technical. That could go well: "Yeah so we're ditching MS SQL Server Pro and instead will go with Cockroach from now on"
Great news! I still don't understand why HyperDex (which has similarities in design and goals) has existed for years and nobody seems to know about it. Is this because it doesn't support SQL? http://hyperdex.org/
https://www.cockroachlabs.com/docs/secure-a-cluster.html
(Much thanks to Go's extensive standard library: https://github.com/cockroachdb/cockroach/blob/master/securit... )
I've lost count on the number of projects that leaves "securing the server" as an exercise to the reader (about as useful as those error prompts that helpfully ask you to "contact the server administrator" (I AM THE ADMINISTRATOR!)).
I understand why not using TLS doesn't give an error, although I'd prefer it if it was more work to set up an insecure instance (eg: --force-no-tls --force-no-auth) -- but what cockroach does here is pretty good, and AFAIK best-in-class from those which it is natural to compare to (in all fairness, projects like postgresql a) doesn't do too bad, and b) have a lot of legacy cruft -- the old (current) assumption is of course that if you want TLS, you'll use your secure in-house CA for everything. Which even when running Microsoft AD is in my experience way too complex for most to bother with).
Another (bad) example here is openssh, that has had decent support for certificates rather than keys for a long while now, and yet I've yet to see anyone that appear to use ssh certs in anger (Myself included, it's high up on the infinite todo-list).
One other great example of making the best of what awful tools are available for securing communications is the Caddy web server, that comes with built-in support for letsencrypt: https://caddyserver.com/
That said, while I think the docs are pretty good here, a note that leaving an unecrypted, ca-key lying around is a bad idea, might be worth a mention even in the quick-setup. At least as it stands, it's reasonably easy for someone with a working knowledge of TLS/certificates to guess which parts should be secret (all the keys) and which parts should be kept air-gapped (the ca-key).
Maybe a link to how cockroach parses/verifies certs would be nice too, for those that do have a working internal CA -- along with a little info on how/if certs integrate with authenticating nodes (eg: will my printer.example.com x509-cert allow my hacked printer to join the cluster, if it is signed by the same CA?).
Despite all the comments, I'm really liking what I see so far -- I'll be keeping an eye on this project!
Seriously, though, this looks like a very interesting project. Until now, I had not been aware it supports SQL. I think I have to give CockroachDB a try in my next toy project.
It sounds like they try do build something very ambitious. To my knowledge none of the commercial database vendors (except maybe Tandem back in the day?) have succeeded in building a distributed/replicated SQL-based database engine with strong consistency and high availability. I know MSSQL supports hot-standby/failover, but AFAIK that does not cover all the scenarios CockroachDB seems to want to address.
Also... why would you want to live WITHOUT ANY JOINS nowadays?! Unless the scale requirements actually prohibit it, and let's face it, 99% of what people are doing is not even close to "big data" on modern hardware, and no, your 1TB DB is not big data and you can handle it with Postgres or a powerful graph db just fine on a pretty cheap VDS if you stay way from AWS/Azure etc. that get nowhere near the performance/price of renting "dedicated metal" on mid-term deals. I'm getting closer tho thinking along the lines of: not even plain JOINs are enough, I want at least Postgress-like recursive joins if not full-fledged infinite-depth graph traversals! I know the budget/hardware allows is, so give it to me, stop the whole "scalability" bullshit!
Aside from everything else, it's nice to see what appears to be sane support for using TLS right there in the command line, and in the beta: https://www.cockroachlabs.com/docs/secure-a-cluster.html (Much thanks to Go's extensive standard library: https://github.com/cockroachdb/cockroach/blob/master/securit... ) I've lost count on the number of projects that leaves "securing the server" as an exercise to the reader (a…
TLS is ok if you need to secure something that speaks HTTP (or IMAP etc) -- but I wonder if ssh certs might not be the lesser evil for something like what cockroachdb needs. Perhaps esepcially now as self-signed/"home grown" x509 certs are being relegated to the background by modern browsers -- so you'd end up needing a "real" cert for the status-server to present securely to a web-client, which might not match the wish for every node to have its own keypair.
Earlier quoted context omitted.
Ahm it is a good choice, since the name implies its survivability. They say "cockroaches can survive a nuclear explosion".
Why not just RoachDB? Same meaning but rolls off the tongue a lot easier.
I still don't get it why people get so excited with every new even-more-scalable DB yet at the same time completely ignore what's happening with things like graph DBs or hybrid-document-graph DBs that seem so f cool! Also... why would you want to live WITHOUT ANY JOINS nowadays?! Unless the scale requirements actually prohibit it, and let's face it, 99% of what people are doing is not even close to "big data" on mode…