ScaleBase Rocks the TCP Test
Are you using MySQL for your relational data engine? Have you exhausted the amount of performance available on a single server? Are you thinking you have to find another implementation, and dreading the thought of modifying all your applications for a new engine?
Here is some fantastic news just for you! The latest release of ScaleBase produced astounding numbers in the traditional TPC test used to evaluate performance of relational database engines. Here are some key points:
- The test was performed in an Amazon EC2 Cloud Environment (not known for providing strong performance numbers with relational technology)
- The test returned outstanding results of 180k new order transactions per minute
How was this done? First, you need to understand a little about how ScaleBase works:
- ScaleBase looks exactly like a MySQL database engine to any client, or MySQL management tools
- ScaleBase transparently shards (divides and distributes) the data across multiple instances of MySQL
As a result, when you access a ScaleBase implementation, it looks just like MySQL to any program, while having what has been verified as Linear scaling for each additional instance added. Simply, for every instance you add to your ScaleBase MySQL Grid, you get 100% capacity of that new instance.
ScaleBase was able to hit this remarkable TCP result using 14 instances of MySQL operating as a single MySQL database through ScaleBase.
Now, it’s hard enough for me to maintain the databases I have operating today. So, you are going to increase the amount of management work I have by however many instances I have running. That hurts pretty badly.
ScaleBase has solutions for that as well. Just as you can do a logical backup from a single MySQL database, you can do a logical Backup through ScaleBase, backing up data from all instances, using tools already familiar to MySQL DBAs.
Of course, file level backups may be performed as well. Most companies performing this kind of backup already have software that works well with distributed data.
Another thing that was of interest to me was distributing schema changes throughout all instances. The answer was quite elegant…the same way you do anything to MySQL. Any DDL (Data Definition Language) queries you would execute to a single database are submitted to all databases through ScaleBase. Again, there is not additional work for the DBA when managing database schema changes either.
One feature that makes ScaleBase attractive is that it does not require everything to be the same for each MySQL Instance. MySQL may be running on different hardware, different operating systems, and perhaps even different versions of MySQL. In fact, it has been demonstrated that performance may increase by running multiple instances of MySQL on a single multi-processor machine due to process and threading restrictions.
If this sounds like a good fit for you, or you simply want more information, please contact Rob Levine, ScaleBase’s VP Sales, rob.levine@scalebase.com.
For those of you who are not using MySQL as yoiur data storage engine, ScaleBase has a future roadmap to integrate with other relational engines. In the mean time, I’m curious about those of you who have found the need to distribute your data, and if you have implemented your own sharding techinque? I know I have done the same in previous applications. Why not share your experience with us; drop me an Email at btaylor@sswug.org?
Cheers,
Ben
SSWUG TV
With Stephen Wynkoop
Did you catch the first "Field Reporter" interview with Kevin Cline and Kathi Lallenberger in our last SSWUG TV? If not, here’s a link to go Watch the Show.
$$SWYNK$$
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)