Project idea: globally hosted / managed CockroachDB that lets developers quickly start building small apps cheaply or free using this database. This database has the potential to dethrone Spanner in a major way.
[deleted]
CockroachDB 2.0 Performance Makes Significant Strides
101–110 of 187 posts
Re: CockroachDB 2.0 Performance Makes Significant Strides
#102Earlier quoted context omitted.
you do realize it's ancient hardware thats $300-400 USD on ebay now.
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=11... Yeah, but 1700 cores worth. That's still a lot of $300 boxes. Like qty 53 Sparc T3-2's for example. Which seem to be $1200 to $2k on eBay. And unsupported, end of life, etc. I'd compare CockroachDB's number to some more recent result with a similar number of cores. (If you can find one)
I meant dell boxes Sparc based boxes retain some value
Re: CockroachDB 2.0 Performance Makes Significant Strides
#103Looks 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 seconds, where Postgres would take just a few milliseconds.
The documentation recommends that you batch as many updates as possible, but obviously that doesn't work for low-latency applications like web frontends that need to be able to do small, fine-grained modifications.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#104Since you only have 3 nodes, doesn't that mean every range is replicated to every node? Doesn't that make joins trivial (i.e. no different from non-distributed joins)?
Yeah, though from what I understand this benchmark is measuring both transactional read and write performance rather than just join performance.
Transactional writes are likely the slowest thing since they need to talk to all replicas.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#105The 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.
Re: CockroachDB 2.0 Performance Makes Significant Strides
#106Since you only have 3 nodes, doesn't that mean every range is replicated to every node? Doesn't that make joins trivial (i.e. no different from non-distributed joins)?
Yeah, though from what I understand this benchmark is measuring both transactional read and write performance rather than just join performance. Transactional writes are likely the slowest thing since they need to talk to all replicas.
[deleted]
Re: CockroachDB 2.0 Performance Makes Significant Strides
#107Looks 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…
" small transactions modifying a single row could take as much as 7-8 seconds"
That's surprising. I wasn't expecting CockroachDB to be really fast, given the constraints they work within. But that sounds more like a bug or config error. Unless perhaps you mean a really high number of processes trying to update the same row at the same time? Like a global counter or something?
Re: CockroachDB 2.0 Performance Makes Significant Strides
#108Since you only have 3 nodes, doesn't that mean every range is replicated to every node? Doesn't that make joins trivial (i.e. no different from non-distributed joins)?
Yeah, though from what I understand this benchmark is measuring both transactional read and write performance rather than just join performance. Transactional writes are likely the slowest thing since they need to talk to all replicas.
Actually hmm, do reads need to talk to all replicas in this case (serializable isolation)?
Re: CockroachDB 2.0 Performance Makes Significant Strides
#109Re: CockroachDB 2.0 Performance Makes Significant Strides
#110Looks 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…
7-8 seconds seems extremely long. Human beings performing the raft consensus algorithm using paper and pencil over Skype wouldn't be much slower than that. Are you sure everything was working correctly?