3 ms·
[Cockroach Labs engineer here.] Yes, if very low-latency (i.e., P99 latency sub-5ms) reads and writes are critical to your application, CockroachDB should not
by benesch 9y ago
[Cockroach Labs engineer here.]
Yes, if very low-latency (i.e., P99 latency sub-5ms) reads and writes are critical to your application, CockroachDB should not be your first choice. That said, one of the primary motivations for CockroachDB is that most existing systems don't handle eventual consistency well. In our experience, most developers will eventually write code that assumes a consistent database, either accidentally or intentionally, because it works most of the time. Dealing with eventual consistency is hard.
Rather than "if you can work with eventual consistency, you should look elsewhere," the sentiment we're trying to cultivate is "if and only if your performance requirements can't work with strong consistency, then you should look elsewhere."
- trimbo 9y ago> P99 latency sub-5ms Has the team cooked up any latency benchmarks for different configurations? E.g. same-rack, same-zone, multi-zone, multi-region?
- arjunnarayan 9y agoNot in a rigorous fashion yet, but we will talk about that soon. I've got a couple other comments on this post talking about performance benchmarking: https://news.ycombinator.com/item?id=14308770 https://news.ycombinator.com/item?id=14308770 and https://news.ycombinator.com/item?id=14308903 https://news.ycombinator.com/item?id=14308903
- nickpsecurity 9y agoI support the default on consistence the way you posed it. Main reason is safe-by-default construction has proven more effective for average programmer over decades. The other approach caused many disasters.
- zzzcpan 9y agoMeh, this is just pr, nothing is safe-by-default. It's not actually true that people eventually assume strong consistency, because eventual consistency forces certain stricter way of thinking about the state and time, kind of functional, you just can't escape it. It's strong consistency that lets you get sloppy, while making you forget how not simple it is. It only exists inside the system and if you have clients from the outside of the system, like web browsers, you don't have two phase commit protocol on a button click there, so you have to resort to that same functional way of thinking to at least try not to confuse anyone on retry, but it's clearly not the case in the wild. It's just too complex. I don't think anyone goes back from eventual consistency. It's more appropriate for this asynchronous world, easier and more reliable.
- nickpsecurity 9y agoGoogle disagreed on that last part. Their bright engineers kept screwing up with eventual consistency. It's why they built Spanner in the first place followed by F1. So did customers of FoundationDB and Cochroach despite free solutions available for eventual consistency. So, Im not seeing it so clear cut in favor of eventual consistency.
- zzzcpan 9y agoGoogle never did or bothered to do much work on eventual consistency, they cannot possibly have any experience with it. CRDTs didn't came from them. And you know very well that customers do not care about any of this.
- nickpsecurity 9y agoTheir cloud storage said eventually consistent for apps needing a lot of performance when I looked into it. A quick Google on the offerings show pages describing what tradeoffs are available for customers with each option. So, they not only know about it: they implemented it as a product feature. Their internal stores were strongly-consistent with high performance except AdWords on MySQL. That got moved to F1 for strongly-consistent high-performance. Spanner, which F1 uses, then got offered to cloud customers. After re-reading the F1 paper, my mistake seems to be thinking they relied on eventually-consistent stuff internally. It appears that was just an option for 3rd party developers in their cloud products. Thanks for the peer review as I found some more stuff double checking. :)