I feel a sense of pride when I think that I was involved in the development and maintenance of what was probably the first piece of software accepted into Debian which then had and still has direct up-stream support from Microsoft. The world is a better place for having Microsoft in it. The first operating system I ever ran on an 08086-based CPU was MS-DOS 2.x. I remember how thrilled I was when we got to see how my friend’s 80286 system ran BBS software that would cause a modem to dial a local system and display the application as if it were running on a local machine. Totally sweet.

When we were living at 6162 NE Middle in the nine-eight 292, we got an 80386 which ran Doom. Yeah, the original one, not the fancy new one with the double barrel shotgun, but it would probably run that one, too.

Whatever Google intended to do with the latest update, I personally think there was some collateral damage done to sites like mysqljoin.com . Since this is only a site I created to show people how joins can be used within MySQL (for free), I never spent money to a SEO agency or something. All I did was installing a SEO Plugin for WordPress. Am I guilty of “over optimizing” now?

The site is approx. 1,5 years old and it grew slowly. The first few month nothing really happened, then people somehow started to link to us , people on stackoverflow.com started to reference us and things like that. To me, this looks really organic. However, the traffic dropped overnight from approx. 1500 unique visitors per day to approx. 300 unique visitors.

If this update works to fight again spammy sites in the organic results,

This site will be under construction for the next time.

Again, I have moved to a new hosting provider after my free-tier with Amazon EC2 expired.  As usual I was looking for a good VPS provider with a decent price, providing good support and in particular a provider supporting FreeBSD, my favorite OS for server (for desktop I still prefer GNU/Linux.)

This time I have carefully reviewed many options and have finally settled with RootBSD, one of the reputed VPS hosting providers if you are choosing FreeBSD as your server OS.  One of the prime reasons for choosing FreeBSD is its performance, stability and the

There is a huge amount of buzz around NOSQL, and we at ScaleBase are happy to see companies making the move to NOSQL. Despite what some people might think, we consider it a blessed change. It is time for applications to stop having a single data store – namely a relational database (probably Oracle) – and start using the best tool for the job.

In the last couple of years, since NOSQL technologies broke into our world, a lot of experience has been gathered on how to use them. Mainly, we see NoSQL technologies used for one of the following scenarios:

• Queries that require a very short response time
• Storing data without a well-defined schema, or storing data with a frequently modified schema

Now, I’m not in any way saying that NOSQL solutions are not used for other scenarios as well; I’m only saying that from our experience here at ScaleBase ,

ScaleBase Releases Database DBT2 Performance Results

Technology achieves unprecedented transaction speed for a MySQL database at a low cost

Boston, Mass., December 12, 2011 – ScaleBase, Inc. today announced the results of its MySQL database benchmark, based on the industry-standard DBT-2 test. ScaleBase has achieved an unmatched 180,000 Transactions per Minute – the highest result for a MySQL database – while running on an Amazon RDS environment. Cost per Transaction was reported to be 50 cents, which demonstrates the cost-effectiveness of the ScaleBase solution on the Amazon EC2 cloud. Full details of the benchmark

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

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

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,

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

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

In the first post of the series I tried to explain why you would like your web platform to run on a MySQL database, and not on an Oracle database. In this post, I’ll try to focus on the changes that you need to plan for when migrating from an Oracle environment.

Code

Probably the most obvious change is in code. There is no way around it – you’ll have to change your code.

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)

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.

In the previous post of this series (which can be found here) I discussed how to migrate your data once you have decided how to shard your schema.

Once your data is sharded, it’s time to modify your application code. I will not dive into the many open source platforms that provide partial sharding support (Hibernate Shards, Gizzard, and the like), and will take Java (sorry, old habits are hard to overcome) as an example – however, the same holds true for any programming language.

Without Using ORM

If you wrote your code without an Object/Relational Mapping tool, kudos to you. Sharding will be easier, as you control the SQL statements.

Upgrading Connection Pool

Your first task is to write a connection pool that is “sharding” aware.  The class should

In the previous post of this series (which can be found here) I discussed how to identify tables that can serve as good candidates for sharding.

Once you have decided which tables should be sharded (all the rest should be global tables), the choice of sharding keys is rather straightforward, as most will use the table primary key as the shard key. Of course, if multiple tables are sharded, and there is a foreign key relationship between these tables, then the foreign key will serve as the shard key for some tables.

Many people attempt to shard based on customer_id or a resource id, but I have seen how this usually fails in production environments. It is very hard to know in advance which customers belong together in the same database, and since customers can suddenly increase their traffic,

This is the first in a three part series of blogs in which I’ll try to explain how to take an existing application and shard it.

Database Sharding has proven itself a very successful strategy for scaling relational databases. Almost every large web-site/SaaS solution uses sharding when writing to its relational database. The reason is pretty simple – relational database technology is showing its age and just can’t meet today’s requirements: a massive number of operations/second, a lot of open connections (since there are many application servers talking to the database), huge amounts of data, and a very high write ratio (anything over 10% is high when it comes to relational databases).

Many sites and blogs posts explain what sharding is, for example here and

Backing up data is critical for production databases – and there are a lot of well-known solutions for backing up databases.

When the database is sharded, backing up data becomes problematic. If the backup is not synchronized across all shards, data inconsistency might occur. In this blog post I’ll try to detail the possible backup scenarios for sharded databases when using ScaleBase.

Backup Types

Let’s start by understanding the different backup types that are out there. You can read all about it here.

A physical backup involves copying all database files to a different location. Copying can take several hours for a decent database if it’s done to a disk or a tape. It might take only seconds if the database files reside on SAN/NAS storage hardware that supports snapshot

Wow. Our launch was picked up by many news sites. Here’s just a partial list. Thanks guys.

• BusinessWire
• CWCS
• Diversity
• DowJones (Subscription required)
• DZone
• Finanznachrichten

Boston, Mass., August 15, 2011 – ScaleBase, Inc. today announced the general availability of ScaleBase 1.0 for unlimited scalability of MySQL databases. ScaleBase 1.0 delivers MySQL performance and high availability, without the need to change a single line of application code. Users of MySQL can download and easily deploy the software by visiting http://www.scalebase.com/solution/download/.

ScaleBase utilizes two techniques for scaling: read-write splitting and transparent sharding (a technique for massively scaling-out relational database). The software enables MySQL to scale

I recently came across an interesting blog post on RedMonk (not surprising, as I read most of their posts). It’s called It’s Beginning to Look a Lot Like SQL and basically it talks about query language for NoSQL databases. It seems that as NoSQL becomes more popular, users want to do more with it – a good level of querying, for example, is needed.

Now of course, since NoSQL is a family of products that work in radically different ways, it’s not certain that this is possible (or even desirable – read Alex Popescu’s post on the subject).

But my question is – why do you even need a query language for NoSQL data stores? After all, running queries on distributed data might be complex to

Why MySQL Quicksand? Well, that’s easy enough: from experience I’ve learned that the margin between a fully functional MySQL database server and one that’s going into a grinding halt can be a very thin hairline. Getting it back to work may be a hell but it will, most of the time, be very possible to save your server.

Quicksand has the same trouble: it may appear to be quite sold, but a very small disturbance can cause a sudden decrease in viscosity and change it from solid to a liquid like substance. You will sink into it but, generally, not drown.

What will be posted here? Well not everything will be exclusively MySQL but mostly be related to it. You can expect warstories, brainstorms, reposts, links, etc.

My main goal is that whatever I post here will be