There are several ways to implement sharding in your application. The first and by far the most popular, is to implement it inside your application. It can be implemented as part of your own Data Access Layer, database driver, or an ORM extension. However, there are many limitations with such implementation, which drove us, at ScaleBase, to look for an alternative architecture.

As the above diagram shows, ScaleBase is implemented as a standalone proxy. There are several benefits to using such an architecture.

First and foremost, since the sharding logic is not embedded inside the application, third party applications can be used, be it MySQL Workbench, MySQL command line interface or any other third party product. This translates to a huge saving in the day-to-day costs of both developers and system administrators.

Backup can be executed via the proxy, and so allows users to consistently backup a sharded environment – not …

The ScaleBase Analysis tool gives a schema a grade between 1 and 100 for being “sharding compatible”. It’s a neat feature, but many ask me how the grade is calculated. Well – here goes.

First of all, a good schema is one that is easy to shard. Database Normalization is usually a good thing when sharding. It means that finding the sharding key is easy, relationships between tables are clear, and the queries themselves are usually much simpler. So we try to give a grade on how well the schema is normalized.

After the sharding configuration is determined (see here on how this should be done), we review your MySQL General Log, to understand the value you can expect from the sharding configuration:

• Statements that run on sharded tables, and hit a …

We at ScaleBase talk about sharding so much, it’s difficult for us to see why someone wouldn’t want to shard. But just because we’re so enthusiastic about our transparent sharding mechanism, it doesn’t mean we can’t understand the very basic question, “When do I shard?”
Well, it’s not the most difficult question to answer. I’ll keep it short: if your database exceeds the memory you have on a single machine, you should shard. If you hit I/O, your performance suffers, and sharding will assist.
Why? That’s easy to explain.
Databases in general (and MySQL is no exception) try to cache data. Because accessing memory is so much faster than accessing disk (even with SSDs), database providers have developed rather sophisticated caching algorithms. For instance, running a query caches the query and its results. Indexes are stored in memory so that, when running a query, the database doesn’t have to hit the disk …

This is the third blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL. You can read the previous post here.

I went over some of the difficult topics you’ll face when migrating from Oracle to MySQL. However, I left out the topic of database scalability (after all – this is a ScaleBase blog).

Oracle users are used to having a very clear scalability path. You start with an Oracle Standard edition, and if your budget allows, you increase hardware (memory, CPU), improve your storage speed, buy Oracle Enterprise edition and use portioning. If all that fails, you move to a distributed RAC environment. If you’re really on the high end, you buy ExaData2. This is where your journey ends. There is nothing “better”.

That’s great for enterprise …

This is the first blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL.

During the World War II “Battle of the Bulge”, General McAuliffe said to the German forces who asked for his surrender: “Nuts!” The rest is history – he won the battle, and the allied forces won the war.

Some things are like that. So absurd that “Nuts” is the only possible reaction. And frankly – running your web infrastructure on an Oracle database is one of those things.

Now, the pricing issue is very well covered. Just see here. And for most people, this should be enough. We had a customer migrating from a 7M USD environment to a 200K yearly environment (licensing and support) – definitely worth the migration hassle!

But it’s not …

ScaleBase is happy to sponsor the Percona Live London MySQL Conference. If you plan to attend, you can catch our booth on the expo floor or attend Liran’s session – “The Benefits of Database Sharding” at 2PM, October 25th at the Bishopsgate Suite.

Yeah, we know it’s 6 month from now – but we’ll give a lecture titled “Database Sharding on MySQL” at the Boston MySQL Meetup. Register here.