Percona Evaluates Clustrix and MySQL

Percona ran a Percona-written TPCC benchmark against Percona’s MySQL Server on an Intel- SSD based machine, Percona MySQL Server on a FusionIO based machine, and a variety of different sizes of Clustrix’s database clusters running Clustrix’s Sierra relational database.

The results show that Clustrix:

  • Scales linearly from 3 to 9 nodes.
  • 431% faster than the tested FusionIO system.
  • Tested system configured with 2x redundancy for Fault Tolerance.

There are a few conclusions that can be drawn from these results.

Scalability

First is that the Clustrix database really is scalable. If you look at the median throughput graph on page 7, the six-node results are two times the three- node results and the nine- node results are three times the three-node performance at concurrency. This is exactly the behavior you need to see as a website or similar application scales. As a website gets more and more users, concurrency goes up and aggregate performance requirements continue to grow. This is in stark contrast to the MySQL-based systems tested, which followed the traditional performance curve up to their peak, and then down toward unresponsiveness as the concurrency increased.

Performance

The second conclusion we draw from this report is that performance exhibited by Clustrix is also more consistent than the MySQL systems. If you look at Appendix A, you can see graphs representing the instantaneous performance throughout the test. Clustrix maintains more consistent performance and lower response times even at high concurrency — exactly when your website needs it most.

Redundancy and Fault Tolerance

A critical thing to note about this comparison is that the MySQL based systems have no redundancy. They either have a single FusionIO card or SSD drives in a RAID 0 configuration. If any component in the system fails (drive, motherboard, memory, etc.), the entire database will fail. In the Clustrix systems, fault tolerance is built in — all data in stored redundantly and online casino there is no single point of failure. The only way with MySQL to get a similar level of fault tolerance (but still not as seamless as Clustrix) is to have two servers with replication. Generating a replication feed would further slow down the MySQL systems, so we left them unencumbered by replication to get the best possible numbers.

Complex Workload that Scales

The most interesting conclusion, perhaps, is the more general statement that transactional, relational, full-featured SQL can scale and Clustrix has proved it in this testing and at multiple production customer deployments around the world. The TPCC test is a relatively complicated workload. There are multi-statement transactions, joins, aggregates, foreign key constraints, and a large percentage of writes.

These are exactly the things the NoSQL movement has proclaimed as too difficult to scale. They couldn’t make true transactions scale so they introduced eventual consistency. They couldn’t make relational calculus scale so they forced denormalization and complicated logic onto the app developers. NoSQL “solutions” have thrown all this out and the one bone they throw the app developers is the concept of a “flexible data model.”

That’s not a revolution, that is a feature and a simple one at that (See our co-founder’s post on how this can easily be done in a SQL database and how Clustrix has implemented it). You don’t have to give up transactions or ACID properties, relational semantics, or any of the rich SQL features in the name of performance or scale. SQL will perform and scale just fine.