Understanding the “NoSQL movement”

I’m currently employed by Sun Microsystems as a senior instructor, teaching topics related to MySQL – database administration, performance tuning and the like. That makes me, in theory at least, something of an expert on MySQL, which is now the world’s largest open-source relational database management system.

However, I also keep an eye on whatever else is happening in the database world, and recently an interesting trend has started to emerge, driven by the needs of large websites such as Facebook.

This trend has come to be known as the “NoSQL movement”, and it attempts to address those problems that arise when the attempt to massively scale up a relational database management system (RDBMS) starts to break down.

Here’s the problem in a nutshell: it’s very difficult to continue scaling up an RDBMS once you pass a certain size, especially if you’re trying to distribute your datacenters geographically at the same time. The largest players such as Google and Amazon were all forced to face up to this problem some time ago, while websites such as Facebook, Digg and others are only now hitting the same barrier.

To understand why it’s such a problem, it’s worth taking a look at some relatively simple scaling strategies to see why they fail.

When scaling up a traditional RDBMS you’ll typically start off with a single database server (I’ll use MySQL as my example here, but the principles are similar, if not identical, whichever RDBMS you prefer). This works well for a while, but as your website becomes more and more popular, the loading on this server increases to a point where it starts to perform unacceptably slowly.

Your next step is normally to hang one or more slave servers off the master database server as shown in the diagram to the right.

All data on the master server is automatically replicated down onto these slaves, so that any application that wants to read some data can connect to any one of the slaves that’s available to do so. However, all writes must go to the master, because the data flow is one-way from master to slaves, and writing to a slave makes no sense.

This one-way traffic starts to become a problem if the dataset needs to be frequently updated: think of Facebook as an example, where people need to update their status and profile, upload pictures, comment on others’ pages and so on. Reading is no longer a problem since you can just hang more and more slaves off the master, but as the write traffic increases it will start to swamp the master server all over again.

At this point, you might want to introduce extra master servers, with master-master replication in addition to master-slave replication, and perhaps hang some slaves off each of these masters as shown in the diagram to the right.

This kind of architecture can help to handle the loads, although it turns out it isn’t nearly as perfect as it looks. You might think that once you have two masters in place you can do twice the writes per second, but sadly, that isn’t the case thanks to various problems (to do with file locking and parallel updates) that I don’t have the space to cover in adequate detail here. Such a multimaster scenario may help to some extent, but you’ll soon pass the point of steeply diminishing returns.

Horizontal and vertical partitioning

The next strategy to try is horizontal scaling – or “sharding” – the data. The idea is to keep certain subsets of your data on one server and some on a different one. For instance, perhaps you could store the data for all those people whose surnames begin with the letters A-M on one server and those beginning N-Z on another.