Everything You Need to Know About Scaling MySQL – Part 6: Aurora

In November of last year, Amazon announced a new MySQL-compatible scale up relational database engine called Aurora. The online retailer billed the new product as highly scalable, boasting its capability to automatically grow storage from 10GB to 64TB based on need.

Scalability is a vital feature in a database—especially for e-commerce sites that handle thousands of transactions every day. Successful e-commerce sites need to be able to easily add compute (CPU), storage, and memory to their database(s) every year, especially for seasonal peaks like Cyber Monday. And specifically, the ability to scale out is most important on the cloud: e-commerce merchants want to simply add more commodity servers to get both the read and write performance they need, instead of having to migrate their databases to bigger and (much) more costly server boxes…

Unfortunately, Aurora is only addressing ‘scale-out’ for their storage offerings (charging by the GB, and on shared-disks as well), and ‘scale-out’ for their ‘reads’, promising easy deployment of read-slaves. But they have no similar easy solution to scale writes. Aurora is built upon a single write master, read-slave architecture—latency and performance issues are inevitable as soon as the database hits maximum ‘write’ capacity on Amazon’s biggest available instance. At that point sharding—the separation of data into multiple databases— or replatforming become the only viable options, each with its own set of complexities and significant costs. Not to mention- when it’s time to outgrow Aurora, how difficult will it be to migrate your data off Amazon?

In other words, although Aurora attempts to address some of the challenges inherent to scaling MySQL, it is essentially continuing to institutionalize an outdated method: ‘scale-up’, shared-disk storage, and a-synchronous read-slaves.

Conversely, ClustrixDB was built on a shared-nothing architecture specifically designed to scale-out storage capacity. This horizontal method of scaling ensures overall performance remains consistent regardless of the volume of data, users or transactions a database is tasked with handling at any given time.

Leveraging a combination of query processing and intelligent data distribution, ClustrixDB simply adds nodes in the cloud as capacity needs expand, guaranteeing a seamless experience for the end user. All servers perform full writes and reads, and remain completely synchronized at all times. Not to mention, ACID Compliance is built-in.

The shared-nothing architecture of ClustrixDB promises several benefits over legacy read-slave architectures, including:

  • High availability:Provides the capability to lose one server and remain fully redundant while all servers are constantly in sync, providing full read and write access
  • Simplicity: Management from a simple point-and-click user interface; many ClustrixDB customers never need any technical support
  • E-commerce Optimized: Designed specifically for e-commerce sites

Our series isn’t over yet! Be sure not to miss Part 7, “Customer Issues Within MySQL.”