Elastically Scale for Peak Traffic Periods
Because part of the promise of the cloud is to pay for just what you need
The promise of the cloud is to be able to spin-up or terminate resources as needed. 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.
Scaling out the relational database using sharding is very difficult
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. The complexity and overhead involved in sharding is why it is always a last resort.
All of the benefits of sharding, none of the work
Built from the ground up to be 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 does all the work for you—and better than you could do on your own—and will continue to distribute and rebalance 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, this also means you can scale-down your deployment.
Adding and deleting nodes is as easy as a few clicks
Through the UI or the command-line, ‘Flexing Up’ your deployment with new nodes is very easy. With a few clicks, the new node’s 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 as Flexing Up—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, and you to be a hero to the DevOps budget owners.