For CloudsWould you like to:
- Offer a business-class MySQL that provides elasticity and high-availability
- Avoid both the intervention and liability of promoting slaves when a master fails
- Enable scaling without painful sharding and without changing the application
- Offer superior performance
- Have a fully virtualized database
- Be able to move a database to a larger or smaller instance without downtime
- Be able to maintain quality of service (QoS) by moving a database away from a noisy neighbor
- Differentiate yourself from me-too clouds offering vanilla MySQL
Then ScaleDB is for you!
MySQL is the dominant cloud database because of its ease of use, performance, and cost advantages. However, MySQL was not designed for the cloud. ScaleDB changes all of that, making MySQL cloud-friendly, without modifying the MySQL source code or requiring any change to existing MySQL applications.
The core of ScaleDB‘s enhancement is database virtualization. Simply replace the InnoDB or MyISAM storage engine with ScaleDB and it turns MySQL into a virtualized, clustered and highly-available database. Each database node is identical to the others, so if you lose a database node, the cluster simply keeps running.
If you need to scale your compute, just add a new compute node to the cluster. If you lose a node, or you want to take it offline to elastically scale down, no problem, the ScaleDB cluster adjusts automatically. If you need to scale your I/O, simply add another pair of storage nodes to the cluster. This makes MySQL much more cloud-friendly.
One of the traditional ways of scaling MySQL is to scale-up to a larger instance. If you choose to scale-up your MySQL instance, it means:
- Taking down your application (in order to capture a consistent copy of the database)
- Copying your entire database to a larger instance of MySQL
- Modifying the routing code in the application, then
- Bringing up the application.
Because of the downtime involved, this is not something you do unless you really have to.
Moving ScaleDB to a larger instance is a snap and involves no downtime, enabling you to scale-up (or down) on the fly. The process is simple:
- Add the new larger or smaller instance to the cluster
- Terminate the old instance...done.
The other traditional, and non-cloud-friendly way to scale your database is to partition or shard your application. Partitioning or sharding simply means creating a collection of separate instances of the database. These instances each own a piece of the data. Then you create routing code in the application tier to make sure the database requests go to the correct databases. Then you further extend the application to handle traditional database functions that involve more than one partition or shard; examples include joins, range scans, reports, aggregates, etc.
ScaleDB handles scale-out far more simply. You just add another node to the cluster. If you are addressing a compute bottleneck, add a database node. If you are addressing an I/O bottleneck, add a pair of storage nodes. There is no downtime and no change to your application.
In the image above, virtual instances of the exact same schema operate logically, and independently of the underlying physical hardware.
One of the key selling points of cloud services is that experts are keeping them highly-available with multiple redundancies. However, everyone knows that server failure is a fact of life and that systems must be designed to handle server failure. ScaleDB is designed not to have any single point of failure; anticipating failure is inherent to the architecture. And yet none of these instances are idle, since ScaleDB load balances across the cluster, taking full advantage of every instance.
Database performance can be measured across various stress points: large numbers of concurrent users, large amounts of data, heavy write activity, and more. ScaleDB‘s clustered architecture enables it to deftly handle all of these stressors, while delivering superior performance. The following are some of the benchmark results we have recorded using ScaleDB.
Quality of Service (QoS)
When running a cloud, quality of service is tantamount to your success. In order to provide QoS, you need the ability to rapidly respond to noisy neighbor issues. Noisy neighbor is when a process on the same server or network segment is consuming too much server or network resources. This situation results in degradation of the quality for those nearby.
Virtualization solves the noisy neighbor problem at the application level, by allowing virtualized applications to move to quieter neighborhoods. The problem with virtualizing the SQL database, to take advantage of this same mobility, is the tight linkage between database processing and the data itself.
Because ScaleDB decouples the data from the database processing, the database instances are virtualized and are free to move in the pursuit of superior quality of service. For example, if you run into a noisy neighbor problem, you can add new nodes to the cluster in a quieter neighborhood and then simply remove those nodes that are experiencing the noisy neighbor problem. Simply put, if making your customers happy with their cloud experience is a priority to you, you need ScaleDB.
ScaleDB extends MySQL, making it far more cloud-friendly. Cloud‘s heavy reliance upon virtualization to handle instance mobility, high-availability, manageability and more, at the application tier, simply hasn‘t worked for SQL databases. Virtualization has, until now, been anathema to SQL databases. ScaleDB changes all of that by seamlessly virtualizing MySQL, enabling it to enjoy all of the same cloud benefits as the application tier.
The inability to virtualize SQL databases has led to the rise of NoSQL, where users were forced to accept several trade-offs, in order to get a database that can be virtualized. ScaleDB provides a no-compromise virtualization solution for MySQL, turning it into a cloud-friendly business-class MySQL.
Download ScaleDB today and see how we can significantly improve your cloud experience.