But partitions are rare. And when partitions happen, generally you can't access the partitioned area so a lot of problems disappear.
Availability isn't an on/off switch, there is a wide range of how "available" you can be and what you can do. For example you can allow reads but disallow rights.
Last but not least, the most important is what happens after the partition is over and what level of guarantees you offer regarding coherence.
Also, while you can't access the partitioned area, you might have nodes outside that area. The question is whether the non-partitioned nodes become useless to you or not.
http://kellabyte.com/2013/11/04/the-network-partitions-are-r...
https://webcache.googleusercontent.com/search?q=cache:D3htez...
If you have one partition per day (which is very often) but do 100,000 request per seconds: partitions are rare.
10 seconds is hardly a partition as it is below the default TCP timeout (one minute).
Also, while you can't access the partitioned area, you might have nodes outside that area.
So these nodes can't access the partition and you don't have any conflict.
But I've seen plenty of systems that handle single node failure, but really get fucked when you have a network split where 50% of the nodes can talk to each other but not the other 50%. CAP theorem doesn't help you build a system that doesn't do very bad things when this happens.
As for YCSB, it's commonly references and is easily available on github. It hasn't changed much lately, and now with tools like jepsen that focus on correctness as well as performance, YCSB is no longer the preferred testing tool.
CAP was highly successful because it fits in with an existing meme - 3 things, you can only get 2 of them. It's simple, and easy to apply in a trivial fashion.
But CAP theorem doesn't have enough "meat" as an engineering analysis, and doesn't guide your system design. Yes there's a proof, but it doesn't tell you how to balance the 3 concepts and how to directly compare system designs.
The thing is that as a descriptive model of how an entire distributed database works, CAP just aint enough. That's why blog posts like https://aphyr.com/posts/313-strong-consistency-models and concepts of 'linearizability' are very useful.
Imagine a small database with a million copies on a million machines. when I write something, i'm going to have to wait a bit while all million machines acknowledge the write is complete. If i have a lower threshold, say 1, the write completes real fast but the million machines aren't consistent.
Real systems balance consistency and availability.
What happens in the case of a (logical) network partition? - an AP system continues taking requests and provides eventual consistency, while a CP system waits for the partition to go away, or says come back later.
