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

CockroachDB 2.0 Performance Makes Significant Strides

cockroachlabs.com

Post reply on HN
Print view View original

121–130 of 187 posts

Re: CockroachDB 2.0 Performance Makes Significant Strides

#121

Post by thanatos_dem »

atombender wrote: post #103

Looks 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? Something definitely sounds misconfigured. I've been running a 1.1.x cluster for quite a while and I've never seen a single row transaction take that long. And even the slowest queries took at most ~500ms, and that was with:

  - Replication factor increased to 5x (rather than the 3x default)
  - 8 indexes on the table being modified which also needed to be updated
  - Nodes spread across North America, incurring higher RTT latency between nodes
  - Relatively high contention on the data triggering client-side retries
  - HDD's as the storage medium (RockDB is optimized for SSDs)

Re: CockroachDB 2.0 Performance Makes Significant Strides

#122

Post by joris »

etaioinshrdlu wrote: post #94

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.

That’s on their roadmap: https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

Re: CockroachDB 2.0 Performance Makes Significant Strides

#123

Post by ngsayjoe »

latenightcoding wrote: post #40
strict9 wrote: post #31

Before clicking the comments link, I always know what to expect in HN comment section for a CDB post announcing their latest milestone or feature: A lot of congrats and excitement, questions about who uses it in a production environment, very specific use-case questions, and of course the name. Weird how predictable the response to one company/tech always is.

People complaining about the name and how they are never going to be able to use it in production because of how gross cockroaches are is definitely the most recurring point. I think it worked well for them, since everyone remembers the name, specially with all the distributed stores coming out lately.

Sometimes i wonder the evolution of cockcroaches' grossness has something to do with its high survivability?

Re: CockroachDB 2.0 Performance Makes Significant Strides

#124

Post by thanatos_dem »

atombender wrote: post #117
jnordwick wrote: post #111

Earlier quoted context omitted.

> low-latency applications like web frontends ...

We have a collaborative, Google Docs-like application that currently issues a write every time someone types into a text field. Now, clearly it's suboptimal and something that should be optimized to batch the updates, but on the other hand, with Postgres we've had zero incentive to make such an optimization, because it's able to handle thousands of writes per node in real time with no queuing happening on the client.…

Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right.

Have you explored implementing a CRDT based solution like WOOT instead?

Re: CockroachDB 2.0 Performance Makes Significant Strides

#125

Post by [deleted] »

lacker wrote: post #115
jetrink wrote: post #110

Earlier quoted context omitted.

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?

I don't know about you, but it would take me a lot longer than 7 seconds to perform the raft consensus algorithm with paper and pencil.

[deleted]

Re: CockroachDB 2.0 Performance Makes Significant Strides

#126

Post by Groxx »

thanatos_dem wrote: post #124
atombender wrote: post #117

Earlier quoted context omitted.

We have a collaborative, Google Docs-like application that currently issues a write every time someone types into a text field. Now, clearly it's suboptimal and something that should be optimized to batch the updates, but on the other hand, with Postgres we've had zero incentive to make such an optimization, because it's able to handle thousands of writes per node in real time with no queuing happening on the client.…

Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right. Have you explored implementing a CRDT based solution like WOOT instead?

Why write conflicts? Contention, sure, but contention isn't an issue until you have literal tons of it.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#127

Post by thanatos_dem »

Groxx wrote: post #126
thanatos_dem wrote: post #124

Earlier quoted context omitted.

Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right. Have you explored implementing a CRDT based solution like WOOT instead?

Why write conflicts? Contention, sure, but contention isn't an issue until you have literal tons of it.

From OP's description

  > issues a write every time someone types into a text field
With more than a handful of people, this is getting into conflict territory pretty rapidly, especially if the document is structured as a single row (hopefully it's more granular than that). Time for some back of the envelope maths:

Assuming that an average person types at around 200 words per minute (number pulled from https://www.livechatinc.com/typing-speed-test/#/), that's a character every 300ms on average. With 10 people editing the document, that's a character every 30ms on average, which can easily lead to conflicts if they're all trying to update the same resource.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#128

Post by true_religion »

sheeeep86 wrote: post #61

I dont like when companies are not transparent about the pricing of their product. If you have a price page, show the price, so that Í can decide if this is relevant for me or not ...

It's not relevant to you.

Enterprise pricing generally basically scales with the size of your company/budget and how much trouble they think you'll be worth as a customer.

As a rule of thumb, it starts at just above 1000 USD per unit, and goes up from there.

Many contracts are bespoke orders especially when you're dealing with a small company, so you can't have transparency since there isn't a single product.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#129

Post by dang »

mlevental wrote: post #64
ardit33 wrote: post #58

And their fucking stupid name..... if they fail, they surely will be remembered as the company with the idiotic name. I can't see serious engineers working on a company named "Cockroach".

>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

Re: CockroachDB 2.0 Performance Makes Significant Strides

#130

Post by dang »

ardit33 wrote: post #58

And their fucking stupid name..... if they fail, they surely will be remembered as the company with the idiotic name. I can't see serious engineers working on a company named "Cockroach".

We detached this subthread from https://news.ycombinator.com/item?id=16710517 and marked it off-topic.
Post reply on HN