4 ms·

Horizontally scaling TPC-C with sharding is nontrivial, as the TPC-C specification requires cross-shard transactions. This is the intent of the TPC-C benchmark:

Horizontally scaling TPC-C with sharding is nontrivial, as the TPC-C specification requires cross-shard transactions. This is the intent of the TPC-C benchmark: real world use cases seldom shard perfectly. CockroachDB scales to 30 nodes in this benchmark while hiding all this complexity under the hood. As far as beating Aurora, CockroachDB's 3 node deployment has fewer vCPUs (48 vs 64) than an active-passive replicated Aurora RDS instance, and matches it in performance. CockroachDB also scales horizontally, as we show, from 3 nodes to 30 nodes, linearly increasing its throughput. I don't believe that 10 shards of Active-Passive pairs of Aurora would scale linearly to 10,000 TPC-C warehouses, and as far as I'm aware, Amazon has not made that claim.

wgjordan 8y ago
Aurora's horizontal scaling doesn't depend on sharding at all- read-scaling uses read-replicas, and multi-master write-scaling uses a hierarchical conflict-resolution strategy [1]. On 'beating Aurora', my point was that comparing a 30-node CockroachDB cluster against a single-node Aurora benchmark and concluding that Cockroach is 'more scalable' is disingenuous, considering Cockroach 2.0 just reached GA, and Aurora multi-master has been available in preview since November and will likely also reach GA in coming months. Once Aurora multi-master reaches GA, I'll look forward to a more direct comparison of an Aurora multi-master cluster against a similarly-sized CockroachDB cluster. [1]: https://www.slideshare.net/AmazonWebServices/deep-dive-on-the-amazon-aurora-mysqlcompatible-edition-dat301-reinvent-2017/36 https://www.slideshare.net/AmazonWebServices/deep-dive-on-th...