For DevelopersDo you need to:
- Scale your MySQL database to handle far larger numbers of users
- Scale your database to handle Big Data and future growth
- Have full ACID capabilities
- Add high-availability
- Avoid the pain of sharding and resharding your data
- Achieve all of the above without changing your database or your application code
Then ScaleDB is for you!
MySQL is inherently a single instance database. As a result, scaling-out has meant splitting your data into independent chunks or shards and then running each shard on a separate database. Sharding your application means that the application must take on the tasks of (a) routing the database calls to the appropriate database; (b) maintaining all of the relationships which were broken when splitting the data; (c) handling all traditional database functions that involve more than a single shard (e.g. joins, range scans, aggregates, etc.). In short, sharding shifts certain responsibilities from the database to the application. Then as your data or application grow, you are responsible for resharding your data to accommodate these changes.
ScaleDB provides a clustering infrastructure that extends MySQL, making multiple servers or cloud instances work like a single machine. Your application talks with ScaleDB as if it is a single database. This means you don‘t have to split your data, write routing code, or add code to your application to handle traditional database functions like joins.
Simply add ScaleDB and your application scales.
Scaling out your database by sharding involves partitioning your data to run on separate machines. In the process, you break the relationships between the data, forcing you to recreate these relationships in the application tier. The following images demonstrate the sharding process:
Figure 1: Sharding before and after
Figure 1 above shows how you split your database schema across multiple separate databases. In this case, the Customers are split into identical groups, or shards, of 10,000 customers per database. The slaves then provide fail-over and may also provide some read scaling.
Figure 2: Extending your application to handle sharding
Figure 2 above demonstrates that sharded databases operate independently of one another, as separate silos of data. This means that the application tier must be extended with additional code to handle routing of calls to specific databases, as well as logic to handle any functions that cross the partitions, such as joins.
All of this assumes that your data can be sharded. Many richly interlinked and complex databases simply cannot be sharded without a complete rewrite of the application.
Figure 3: ScaleDB - The schema remains intact and is virtualized across all database nodes
Figure 3 above demonstrates how ScaleDB runs a virtual instance of the same schema across multiple database nodes in a cluster. Since each node runs the same schema, and accesses the entire database, losing a node simply means that the remaining nodes share the load. ScaleDB in inherently highly-available.
Furthermore, since the database nodes are all identical and virtualized, adding another node is as simple as launching another instance and adding it to the cluster. No downtime, no resharding, none of that.
ScaleDB expands to handle your growth and your evolving needs seamlessly. If your database is compute bound, simply add one or more additional database nodes. If it is I/O bound simply add one or more pairs of storage nodes. The storage nodes operate as pairs, mirroring the data so that failure will not result in data loss.
If you need dynamic scalability, high-availability, and you don't want the additional work and pain of sharding and resharding your data, then ScaleDB is the right solution for you. ScaleDB works with your existing MySQL application and the MySQL tools you use today, making the transition a snap. ScaleDB runs in public or private clouds or your data center, giving you total flexibility on how you deploy your cluster.