Elastic Scale for Peak Traffic Periods
Elastic Scale: Fulfilling the Promise of the Cloud
Part of the promise of the cloud is to be able to spin up or terminate resources as needed, allowing the freedom of elastic scale so that you only pay for what you need and use. To date, true cloud-scale has been provided only by applications and web servers. If the application doesn’t need ACID transactions across structured data, then the third data tier of the app stack could leverage a non-relational data store, which can scale-out, like Redis or Hadoop. This works great for huge INSERT workloads, and single-table transactions. But as soon as you have dependencies across data, including structured data, then data stores come up short. That's when you need elastic scale.
MySQL Sharding Was Not Built for Elastic Scale
Relational databases typically rely on symmetric multiprocessing (SMP), leveraging a single write-master. Once the capacity of that write-master is exceeded, developers are usually forced into complex re-architecture projects such as sharding in order to create additional write-scale. While picking a shard-key and maintaining a PK:shard lookup table is reasonably easy, (re)creating ACID transactions across multiple shards isn’t, and that now becomes the responsibility of the application, creating a permanent workflow of architecture specific work for your developers. Maintaining the balance of data across the shards becomes a regular activity with fun complications like losing cross-shard consistent backups. And since scaling out for capacity is such a significant undertaking, scaling back is almost never feasible, so no elastic scale. The complexity and overhead involved in sharding is why it is always a last resort.
Elastic Scale Without Redesigning Your Application or Data Architecture
Built as a drop-in replacement for MySQL that scales out linearly in cloud environments, ClustrixDB’s default deployment is architected to replicate data automatically across three (3) nodes. Our patented Rebalancer distributes and rebalances data across the nodes to avoid hotspots for the life of your deployment. ClustrixDB provides both automatic query parallelization across nodes, as well as automatic continued availability in the case of instance downtime or outage. Most importantly, there are no application changes needed—ClustrixDB appears to the application as a single logical MySQL RDBMS, leveraging the MySQL protocol. Since the Rebalancer does all the work, and it is transparent to developers, you can scale down your deployment easily with Clustrix's elastic scale capabilities.
Flex Up and Flex Down with Elastic Scale
Either the ClustrixDB UI or the command line is how you control elastic scale. "Flexing up" your deployment with new nodes is very easy. With a few clicks, the new nodes' CPUs are instantly available to the cluster for query processing. And the data is automatically rebalanced in the background to take advantage of the new node. ClustrixDB also lets you control the rate of data rebalancing—you can set the rebalancing to occur slowly, to avoid performance penalties during peak hours, or done quickly, during off hours. "Flexing down" is just as easy—a few clicks is all you need to "soft fail" nodes, allowing the Rebalancer to ensure data copies are well-distributed across the remaining nodes. Once rebalancing is complete, a single click "shrinks" your cluster, allowing the unused instances to be terminated.
ClustrixDB's elastic scale makes you a hero to the DevOps budget owners.