Great stuff but this name really doesn’t work. Make it a name with positive connotations.
I think it's a great name once you get the.. uh.. pun behind it.
What is the pun?
CockroachDB 2.0 Performance Makes Significant Strides
161–170 of 187 posts
Re: CockroachDB 2.0 Performance Makes Significant Strides
#162Hadn't heard of Cockroach but based on the article, this thread and the rest of their site it sounds at least worth installing on a few hobby nodes if only to get familiar with the behavior and configuration should a need arise - like Cassandra was years ago when I had already on my own learned the gist of it, sort of a road not taken relative to my then-firm's usual prescriptions (MySQL and Mongo), it turned out to be perfect for my team's needs (paperwork to get permission to use it notwithstanding). Thanks for posting and good luck!
Re: CockroachDB 2.0 Performance Makes Significant Strides
#163Looks very promising! We've looked at Cockroach for a particular project, and we've been concerned that performance wasn't good enough. Cockroach performance seems to scale linearly, but single-connection performance, especially for small transactions, seems rather dismal. Some casual stress testing against a 3-node cluster on Kubernetes showed that small transactions modifying a single row could take as much as 7-8…
[cockroach employee here] Have you hit us up on Gitter or Stack Overflow to help debug and tune? We'd also love to learn more about how you're using K8s, what your setup looks like, surprises you're running into with it, etc.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#164Earlier quoted context omitted.
>I can't see serious engineers working on a company named "Cockroach". You used to work at a company called Yammer . God forbid they're not called tech.ai.io-ify. I think it's really funny that this comes up almost every time there's a post about CockroachDB. There were also a lot of people commenting on https://news.ycombinator.com/item?id=16693253 about foul language and such. I also remember being at a big confere…
Please don't bring in someone's personal details or history as ammunition in an argument. That breaks HN's rules. https://news.ycombinator.com/newsguidelines.html
On that note how would I go about deleting all my comments without associating them with an email? (not keen on sending you an email). If you can, please delete all my comments
Re: CockroachDB 2.0 Performance Makes Significant Strides
#165Re: CockroachDB 2.0 Performance Makes Significant Strides
#166Earlier quoted context omitted.
At the bottom of the article it says that information is coming: "Note: We have not filed for official certification of our TPC-C results. However, we will post full reproduction steps in a forthcoming whitepaper."
I guess will have to wait. The progress they made is obviously impressive but would really help if one could understand the overhead vs conventional RDBMS 5X might be OK 20X not so much.
The minimum latency will still be at least ~5ms (worse if nodes are very far apart) and especially bad for contended reads (because of the way they use clocks for serializable operations).
A traditional RDBMS does not have to worry about split brain decisions, but it can hardly do multi-master in the intuitive way.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#167The thing I really don't get is why CockroachDB is avoid benchmarking with it's rival tidb ( https://github.com/cockroachdb/docs/issues/1412 ). tidb already pretty mature, used in many big companies (Let's say, Didi, which on the similar scale data with Uber, and banks). Even if I like CockroachDB's pg sql more, it would be helpful to have the comparison/benchmark to show something more.
TiDB looks promising, but it doesn't have serializable transactions at all, which makes it something of an apples-to-oranges comparison at the moment when it comes to OLTP. TiDB has a weird kind of variation on "read committed" where you get phantom reads (though they're not called that in the documentation, which is actually ambiguous on this point). This is a problem for apps that expect consistency.
Siddon Tang from TiDB here. Thanks for your interest in TiDB!
TiDB uses Snapshot Isolation (https://en.wikipedia.org/wiki/Snapshot_isolation), which is similar to Repeated Read in MySQL. It doesn’t allow Read Phantom but can’t avoid Write Skew. IMO, this can work well for OLTP in most of the cases. If you really care about serializability, you can use `select for update` to promote the Read as Write explicitly like other databases do.
TiDB supports READ COMMITTED isolation which is not the same as MySQL, but it is just designed for some special cases for TiDB itself and it is not recommended for external users.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#168The thing I really don't get is why CockroachDB is avoid benchmarking with it's rival tidb ( https://github.com/cockroachdb/docs/issues/1412 ). tidb already pretty mature, used in many big companies (Let's say, Didi, which on the similar scale data with Uber, and banks). Even if I like CockroachDB's pg sql more, it would be helpful to have the comparison/benchmark to show something more.
CockroachDB's SQL implementation is still heavily unoptimized for actual business queries (subqueries, unnest, (recursive) CTE, schema changes). Features like this either take way too long or are not even implemented yet. Some of them are in the 2.1 milestone though. Let's hope. I'd really love some kind of distributed-for-performance database using the exact optimizer and query planner of SQLite plus std plugins (FT…
"I'd really love some kind of distributed-for-performance database using the exact optimizer and query planner of SQLite plus std plugins..."
Why do you think the identical optimizer and query planner would work in a distributed environment, with no changes from the single server implementations?
Re: CockroachDB 2.0 Performance Makes Significant Strides
#169The thing I really don't get is why CockroachDB is avoid benchmarking with it's rival tidb ( https://github.com/cockroachdb/docs/issues/1412 ). tidb already pretty mature, used in many big companies (Let's say, Didi, which on the similar scale data with Uber, and banks). Even if I like CockroachDB's pg sql more, it would be helpful to have the comparison/benchmark to show something more.
TiDB is much more complicated to run with several moving pieces. Also missing a lot of standard relational features as you can see from the roadmap: https://github.com/pingcap/docs/blob/master/ROADMAP.md
As a distributed database system, the highly-layered architecture of TiDB is not a disadvantage because it makes TiDB easier to debug and diagnose when issues occur. The complicity resulted from the separated modules can be easily tackled by automatic deployment tools and microservice framework.
For example, TiDB can be easily deployed either using Ansible: https://pingcap.com/docs/op-guide/ansible-deployment/
or Docker Compose:
https://pingcap.com/docs/op-guide/docker-compose/
TiDB has been widely adopted by many users (https://github.com/pingcap/docs/blob/master/adopters.md) in production because it support the best features of both RDBMS and NoSQL. It is quickly evolving and iterating based on users’ requirements which are prioritized and listed on the Roadmap.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#170Earlier quoted context omitted.
TiDB is much more complicated to run with several moving pieces. Also missing a lot of standard relational features as you can see from the roadmap: https://github.com/pingcap/docs/blob/master/ROADMAP.md
As a distributed database system, the highly-layered architecture of TiDB is not a disadvantage because it makes TiDB easier to debug and diagnose when issues occur. The complicity resulted from the separated modules can be easily tackled by automatic deployment tools and microservice framework. For example, TiDB can be easily deployed either using Ansible: https://pingcap.com/docs/op-guide/ansible-deployment/ or Doc…
Sure, I get the advantages of layers in architecture, especially the growing trend of separating compute and storage.
However there's a difference between architecture and deployment, and having everything in a single package makes operations much easier. CockroachDB also uses a KV storage layer (using RocksDB) with SQL on top.